Bug 10933 - '/' forced binaryOp conversion
Summary: '/' forced binaryOp conversion
Status: RESOLVED INVALID
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.0
Hardware: Other All
: P3 minor (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-07-18 02:40 UTC by Serge Knystautas
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Serge Knystautas 2002-07-18 02:40:13 UTC
I'm trying to use the c:set tag to append a series of directories together, and
I'm finding that the '/' character in EL is being forced to a binary op and
won't get treated as a String.  You can see what I mean by doing the following:
<c:set var="foo" value="${'/' + '/'}" />.  I get the following exception:
javax.servlet.jsp.JspException: An error occurred while evaluating custom
action attribute "value" with value "${'/' + '/'}": An exception occured
trying to convert String "/" to type "java.lang.Long"
	at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:140)
	at
org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate(ExpressionEvaluatorManager.java:109)
	at
org.apache.taglibs.standard.tag.el.core.ExpressionUtil.evalNotNull(ExpressionUtil.java:85)
	at
org.apache.taglibs.standard.tag.el.core.SetTag.evaluateExpressions(SetTag.java:147)
	at org.apache.taglibs.standard.tag.el.core.SetTag.doStartTag(SetTag.java:95)

I don't see any way to escape this character in the spec, but this seems like
the implementation is aggressively trying to convert back to a binaryOp.  Not
sure how you would resolve this.
Comment 1 Shawn Bayern 2002-07-18 02:47:14 UTC
This is not a bug; the behavior is as specified.  The JSTL expression language 
does not support "+" as a string-concatenation operator.  Instead, use 
something like this:

attName="/${foo}/${bar}"

That is, an attribute value can contain multiple expressions, so we 
intentionally did not provide a string-concatenation operator -- and thus 
avoided many of the confusions surrounding it that plague ECMAScript.