I've found something that appears to be a bug in TC 5.5.16 . After a small check, it however, also occured in TC 5.5.15, so it might even be older. Tomcat 4.0.6 (using JDK 1.4), however, did *not* have this problem. I've got the following class/package structure: 1: nl.hhv.merlin.gui.editor.EditButtons 2: nl.hhv.merlin.gui.Editor 3: nl.hhv.merlin.gui.editor2.EditButtons Note that packagename of the first class is equal to the fully qualified name of the second class (except for caps/nocaps). This should be no problem right?!? At least it never was until now. Now I have a JSP that simply does: <% nl.hhv.merlin.gui.editor.EditButtons buttons = null; %> Eclipse has no problems with this JSP, and happily accepts it, why shouldn't it? Looks fine to me to :-) But Tomcat 5.5.16 gives me the following error: Generated servlet error: nl.hhv.merlin.gui.editor cannot be resolved to a type When I change my JSP to: <% nl.hhv.merlin.gui.editor2.EditButtons buttons = null; %> Tomcat compiles the JSP without any problems. Note that the 2nd EditButtons class is an EXACT copy of the first. I've tried to reproduce the same issue with different class and package-names, but then it seems to work!?!? Anyway, I've attached a small ZIP which can be unpacked into the TC webapps dir, to try this out yourselves. It also contains the Java sources. Check out the remarks in index.jsp for more weirdness :-) The provided class files have been compiled using Eclipse 3.1.2 (so not the JDK compiler). I'm running TC on Java 1.5.0_06. Kind regards, Paul Hamer
Created attachment 17966 [details] TC webapp to test this yourselves
Thanks for the test case. It makes looking at bugs like this so much quicker. My environment: Windows Home SP2 + all patches Java 1.5.0_04 Tomcat 5.5.HEAD and 5.5.15 I can't reproduce this. I confirmed the suspect code was present in the JSP by reviewing the source code generated in the work directory. The JSP was compilied with the Eclipse 3.1.2 compilier. This looks like a problem with your environment.
I've finally been able to narrow down this problem. It appears that it occurs ONLY when the classes are in the Java classpath, and NOT (as in most cases) in the WEB-INF/classes directory. I'll attach a new ZIP in a minute. Meanwhile, I've also migrated to Tomcat 5.5.17, but the problem remains. Just unpack the zip (mytest2.zip) into your tomcat/webapps directory. The index.jsp will now compile fine, just to prove it actually works :-) Now, here we go: - Stop Tomcat - Rename the mytest/WEB-INF/classes dir to mytest/WEB-INF/klasses . This will prevent Tomcat from picking it up. - Now add the mytest/WEB-INF/klasses dir to the Java classpath. My new classpath then is: C:\Program Files\Tomcat5.5\bin\bootstrap.jar;C:\Program Files\Tomcat5.5 \webapps\mytest\WEB-INF\klasses - Restart Tomcat - Make sure you "touch" index.jsp to force re-compilation. - Visit index.jsp et voila... there you have it: > gui.editor cannot be resolved to a type When I then (keep Tomcat running) delete the WEB-INF/klasses/gui/Editor.class file, and re-visit the index.jsp, it suddenly compiles! Go figure :-) My environment: Windows XP Pro SP2 + all patches Java 1.5.0_04 Tomcat 5.5.16 + 5.5.17 Hope this helps to finally locate this bug. Would help me a lot. I've already got many applications out in the field using these classes, so renaming them is not really an option :-( Thanx! Paul Hamer
Created attachment 18378 [details] New test-it-yourself TC webapp Goes with my reply above
Created attachment 18379 [details] sorry, previous zip did not contain the sources
If you mess with the classpath like this you are asking for trouble and are on your own. See http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html for an explanation of why it isn't as simple as justing adding stuff to your classpath. Also, be aware that the Tomcat startup scripts may over-write your classpath anyway.
In Tomcat 6.0.20, I cannot reproduce this issue as is (by deploying the web application from attachment 18379 [details]), but I can if I move the class files from WEB-INF/classes into ${catalina.home}/lib Thus, the issue does exist, but is not observed with web applications, because different class loaders behave differently. My environment: - Windows XP Prof. SP3 - JRE 1.6.0_13-b03 - Tomcat 6.0.20 A workaround is to pack the classes into a jar file. *** This bug has been marked as a duplicate of bug 47323 ***