Jesper de Jong wrote:I wouldn't expect massive performance gains from this. Maybe webapps will start up a little bit faster when you start Tomcat, but probably it will be so little that you won't even notice it.
Kerry Baer wrote:
To meet the stated specification, before moving on to String conversion and upon the fail of Long.valueOf(char), Tomcat could attempt Long.valueOf(String.valueOf(char)). Tomcat should say "Hey, this is a character. I know characters can't be directly converted to a Long, but Strings can be. So I should convert the character to a String and then parse it as a long." But obviously it doesn't. It just moves on to the next check, leaving the character as a Long and converting the in-line character to a String before executing the comparison.
I wonder if it is just that my interpretation of the specification is different than that of the Tomcat developers or if it is a bug in Tomcat 7. Likely it is the former.
Paul Clapham wrote:
Kerry Baer wrote:In particular I notice the following line of logic:
■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to
Long and apply operator
This sort of explains what is going on.
Yes, that was what I had concluded too. But if you read the spec more, you'll see that "coercing String to Long" consists of (in your case) calling Long.valueOf("N") which will throw a NumberFormatException. Remember that char literals don't exist in EL, so Long.valueOf(String) gets called rather than Long.valueOf(char).
In other words... if you didn't have to do a workaround before, then that was a bug which has been fixed now.
A {<,>,<=,>=,lt,gt,le,ge} B
■ If A==B, if operator is <=, le, >=, or ge return true.
■ If A is null or B is null, return false
■ If A or B is BigDecimal, coerce both A and B to BigDecimal and use the return
value of A.compareTo(B).
■ If A or B is Float or Double coerce both A and B to Double apply operator
■ If A or B is BigInteger, coerce both A and B to BigInteger and use the return
value of A.compareTo(B).
Chapter 1 Language Syntax and Semantics 13
■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to
Long and apply operator
■ If A or B is String coerce both A and B to String, compare lexically
■ If A is Comparable, then:
■ If A.compareTo(B) throws exception, error.
■ Otherwise use result of A.compareTo(B)
■ If B is Comparable, then:
■ If B.compareTo(A) throws exception, error.
■ Otherwise use result of B.compareTo(A)
■ Otherwise, error
■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to
Long and apply operator
Paul Clapham wrote:Yes, using char properties is a pain as far as the EL is concerned. The char values are internally coerced to long values, but there is no way to express a char constant in EL. Both the single-quote and double-quote character delimit strings, unlike in Java where 'N' and "N" are different things. Your fn:contains workaround is at least more understandable than our workaround where we replaced 'N' by 78 (the Unicode value of the character 'N') -- along with a comment explaining why 78.
Bear Bibeault wrote:Indeed, if you are using a char of N or Y to express a boolean, why aren't you using a boolean?
Bear Bibeault wrote:You're confusing the JSTL with the EL. The comparison is an EL operation -- it has little to do with the JSTL.
It doesn't help that you are using really poor non-stadard naming (underscores? really?) rather than following javabean standards. While it might or might not be confusing the property access code, it certainly makes it hard to look at the code and understand what's going on. Conventions and standards are set into place for a reason. You should be following them.
That said, you claim you are having problems with the property program.is_general_public_yn, but then say that program.is_general_public is "printing" as expected. So what? Those aren't the same properties, so the fact that the second one "prints" has nothing to do with the property you are using in the comparison expression.
Rob Spoor wrote:And you've also set the right domainController? You can ping that? It's running an active directory on port 389?
Rob Spoor wrote:Well, how did you try to specify the domain? Did you include it in the Java runtime properties like my example? Or in the web.xml file?