Re: Tomcat 5.5.9, endorsed jars and classloader
Yoav Shapira wrote: With older tomcats this has been works fine for years now, but with 5.5.9 an IllegalAccessException is thrown. Which older Tomcats? Specifically, does it work in 5.0.28 or 5.5.7? 4.x and 5.x tell a bit of a different story when it comes to classloading implementation. The "older" is 4.1.31. The server with Tomcat 4.1.31 runs Sun's JDK 1.5.0-b64, the one with Tomcat 5.5.9 runs Sun's JDK 1.5.0_04-b05. It is possible for me to upgrade the other if you think this may be an issue. The classloaders toString() output is actually different, come to think of it... It would be good to make them use the same JVM version, if only to rule out that variable. But better yet, please test 5.0.28 and 5.5.7. Tomcat 5.0.16 and Sun's JDK 1.4.2_02: valid classloader for A, null for B. Sorry, for now I try to use the Tomcat's that I already have installed... But this seems to rule out the JVM version, and pinpoint the change to have happened between 4.x and 5.0.x. -- Antti Rauramo Index Information Technologies Oy [EMAIL PROTECTED] +358-40-5190209 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.9, endorsed jars and classloader
Hello all, I ran into problems with Tomcat 5.5.9. We have xercesImpl.jar in common/endorsed, and another jar (X-Hive's XML database's xhive.jar) in common/lib, that includes a class that is put in the xerces package (org.apache.xerces.dom) in order to access xerceses package protected class ObjectFactory. This works as long as the classloader is the same for both xerces and xhive. With older tomcats this has been works fine for years now, but with 5.5.9 an IllegalAccessException is thrown. I wrote a test case that seems to prove the case, or at least some difference. Basically there are two classes, testing.A and testing.B. A creates an instance of B and accesses a method that returns the instances classloader. When A is in common/lib/a.jar and B in common/lib/b.jar, both Tomcats displays the same classloaders for A and B. When A is in common/lib/a.jar and B in common/endorsed/b.jar, Tomcat 4.1.31 displays the same classloaders for both A and B, but Tomcat 5.5.9 displays a classloader for A but null for B. The server with Tomcat 4.1.31 runs Sun's JDK 1.5.0-b64, the one with Tomcat 5.5.9 runs Sun's JDK 1.5.0_04-b05. It is possible for me to upgrade the other if you think this may be an issue. The classloaders toString() output is actually different, come to think of it... The test files are at http://www.index.fi/indox/download/tomcat-classloader-test.tar so you can easily see for yourselves. -- Antti Rauramo Index Information Technologies Oy [EMAIL PROTECTED] +358-40-5190209 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cookie values
Hi! I had a problem with accented characters Cookie values, and also just a little longer Strings. Tomcat threw an IllegalArgumentException in maybeQuote like this: java.lang.IllegalArgumentException: =?ISO-8859-1?Q? (keinotekoinen_AND_=E4lykkyys)?= =?ISO-8859-1?Q?_AND_NOT_nodetype:ALL=5FCONTENT?= at org.apache.tomcat.util.http.ServerCookie.maybeQuote (ServerCookie.java:315) at org.apache.tomcat.util.http.ServerCookie.appendCookieValue (ServerCookie.java:248) at org.apache.coyote.tomcat4.CoyoteResponse.addCookie (CoyoteResponse.java:853) at org.apache.coyote.tomcat4.CoyoteResponseFacade.addCookie (CoyoteResponseFacade.java:278) [...etc] I searched the web and found a couple of other people asking the same question, but no answers. So, Sun's javax.servlet.http.Cookie and Tomcat's javadocs say that the Cookie's value can be anything, but also that "If you use a binary value, you may want to use BASE64 encoding." and that "With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons." That's a contradiction, isn't it? BASE64 results in data that may have white space (newlines). But the Netscape's cookie definition says "This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required." And so with URLEncoding this thing finally works! But I'd say that BASE64 is a bug in Sun's and Tomcat's javadocs. And maybe also Tomcat should be able to handle such values without throwing an exception... Tell me I'm wrong, or go fix the javadocs! References: http://java.sun.com/j2ee/sdk_ 1.3/techdocs/api/javax/servlet/http/Cookie.html#setValue(java.lang.String) http://jakarta.apache.org/tomcat/tomcat-4.0- doc/servletapi/javax/servlet/http/Cookie.html#setValue(java.lang.String) http://wp.netscape.com/newsref/std/cookie_spec.html -- Antti Rauramo Index Information Technologies [EMAIL PROTECTED] +358-40-5190209 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
