|
Hello,
We got two Redhat 5.6 Server which are set up idential in the area of tomcat and java. But we have the problem that on the productive machine compilation of JSP files fails with the error 'return type incompatible with JspSourceDependent.getDependants'. The exact same application compiles just fine on the test machine. It fails to compile a simple index.jsp on the productive server because the generated index_jsp.java files differs. Version information: Server version: Apache Tomcat/5.5.23 Server built: Dec 9 2010 03:51:37 Server number: 5.5.23.0 OS Name: Linux OS Version: 2.6.18-238.el5 Architecture: amd64 JVM Version: 1.6.0_22-b04 JVM Vendor: Sun Microsystems Inc. --- index.jsp (on both server) --- <% response.sendRedirect("login.jsp"); %> ----------------- the automatically generated index_jsp.java diffiers in the following lines: ------------------------------------------------------------------------------ --- index_jsp.java_not-compiling 2011-01-27 08:38:46.000000000 +0100 +++ index_jsp.java_compiling-fine 2011-01-27 08:38:41.000000000 +0100 @@ -7,9 +7,9 @@ public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent { - private static java.util.Vector _jspx_dependants; + private static java.util.List _jspx_dependants; - public java.util.List getDependants() { + public Object getDependants() { return _jspx_dependants; } ------------------------------------------------------------------------------ Java-wise it's clear why it won't compile. What we don't understand is why the automatically generated *.java file differs. We made sure both server are idential: - both RHEL5 installation are at the exact same update level - the same tomcat, java & jasper version (stock RHEL5.6 packages) are installed - identical tomcat configuration files (verified by creating md5 sums of 'em in /etc/tomcat5) - identical environment settings for the tomcat user on both servers - tomcat is called idential (check /proc/<tomcat pid>/{cmdline,environ}) - the same user and file permission - the web app is identical (copied from one system to the other) - all the *.jar files are idential (verified by creating md5 sums of 'em) Does anyone have an idea what else we could check? Is it possible to 'simulate' a jasper build, e.g. with a custom build.xml, manually to be able to see what causes the error? I asked the oracle of Google for help for almost a day but couldn't find matching solution. One possible cause could be different versions of jasper installed. But I couldn't find anything suspicious. Thanks and have a good day, Thomas Kupper Siemens Schweiz AG Siemens IT Solutions and Services SIS GO SD AO Freilagerstrasse 28, CH-8047 Zürich Wichtiger Hinweis: Diese E-Mail und allfällige Anlagen können firmenvertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen Sie uns bitte durch Antwort-Mail und löschen Sie diese E-Mail nebst Anlagen von Ihrem System. Vielen Dank. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Thomas, On 1/27/2011 3:09 AM, Kupper ext-FA, Thomas wrote: > It fails to compile a simple index.jsp on the productive server > because the generated index_jsp.java files differs. > > Version information: > > Server version: Apache Tomcat/5.5.23 [snip] > the automatically generated index_jsp.java diffiers in the following lines: > > ------------------------------------------------------------------------------ > --- index_jsp.java_not-compiling 2011-01-27 08:38:46.000000000 +0100 > +++ index_jsp.java_compiling-fine 2011-01-27 08:38:41.000000000 +0100 > @@ -7,9 +7,9 @@ > public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase > implements org.apache.jasper.runtime.JspSourceDependent { > > - private static java.util.Vector _jspx_dependants; > + private static java.util.List _jspx_dependants; > > - public java.util.List getDependants() { > + public Object getDependants() { > return _jspx_dependants; > } > ------------------------------------------------------------------------------ Did you upgrade recently? This is an internal API that is subject to change, and might have changed during an upgrade that left files in your "work" directory. Try stopping Tomcat, removing Tomcat's "work" directory, and then re-starting. Your JSPs should re-compile and work fine after that. If you are precompiling your JSPs, you'll need to re-precompile your JSPs with your current Tomcat version. Also, your version of Tomcat is very old. If you are using a package-managed version of Tomcat, you may be stuck with an ancient version. Consider using the canonical Apache version to stay up-to-date. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1B7h0ACgkQ9CaO5/Lv0PCQZACfdbSR9T5SmUa9Q4Sw70EBPdHF AwAAoLq3eEVWR1D1U21cdHEz6Ws3PsOX =o/Sz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Hi Chris,
Thanks for your help, I had some days off - that's why my answer is a bit late. > Did you upgrade recently? This is an internal API that is subject to > change, and might have changed during an upgrade that left files in your > "work" directory. Compiling isn't working since the server was setup (by someone else). I'll try cleaning the 'work' directories. Since it's a (very) productive server I don't have too many service windows. That's why I tried to reproduce the problem on the test server but did not succeed yet. And on both servers are at least two applications and both won't compile on the productive machine. And yes, we did upgrade from RHEL5.5 to RHEL5.6 and the tomcat packages were upgrade. But since compiling did'nt work before I'm not sure what the impact of this update is. Getting rid of the 'work' directory is probably my best bet right now. > Try stopping Tomcat, removing Tomcat's "work" directory, and then > re-starting. Your JSPs should re-compile and work fine after that. I'll give that a go as soon as I got a service window and let you know. > If you are precompiling your JSPs, you'll need to re-precompile your > JSPs with your current Tomcat version. Well, I haven't done any precompilation yet. I was just wondering if that might help pin-down the problem. Unfortunately I'm not a developer but a server admin and have no clue how a build.xml should look like that ca 'simulate' a Tomcat/Jasper precompiling. > Also, your version of Tomcat is very old. If you are using a > package-managed version of Tomcat, you may be stuck with an ancient > version. Consider using the canonical Apache version to stay up-to-date. The version we use is the stock Tomcat for RHEL5. For now I'm stuck with that version. Thanks for your help and have a nice day, Thomas -----Original Message----- From: Christopher Schultz [mailto:[hidden email]] Sent: Donnerstag, 27. Januar 2011 23:14 To: Tomcat Users List Subject: Re: Jasper Compiling Error -> return type incompatible with JspSourceDependent.getDependants -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas, On 1/27/2011 3:09 AM, Kupper ext-FA, Thomas wrote: > It fails to compile a simple index.jsp on the productive server > because the generated index_jsp.java files differs. > > Version information: > > Server version: Apache Tomcat/5.5.23 [snip] > the automatically generated index_jsp.java diffiers in the following lines: > > ------------------------------------------------------------------------------ > --- index_jsp.java_not-compiling 2011-01-27 08:38:46.000000000 +0100 > +++ index_jsp.java_compiling-fine 2011-01-27 08:38:41.000000000 +0100 > @@ -7,9 +7,9 @@ > public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase > implements org.apache.jasper.runtime.JspSourceDependent { > > - private static java.util.Vector _jspx_dependants; > + private static java.util.List _jspx_dependants; > > - public java.util.List getDependants() { > + public Object getDependants() { > return _jspx_dependants; > } > ------------------------------------------------------------------------------ Did you upgrade recently? This is an internal API that is subject to change, and might have changed during an upgrade that left files in your "work" directory. Try stopping Tomcat, removing Tomcat's "work" directory, and then re-starting. Your JSPs should re-compile and work fine after that. If you are precompiling your JSPs, you'll need to re-precompile your JSPs with your current Tomcat version. Also, your version of Tomcat is very old. If you are using a package-managed version of Tomcat, you may be stuck with an ancient version. Consider using the canonical Apache version to stay up-to-date. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1B7h0ACgkQ9CaO5/Lv0PCQZACfdbSR9T5SmUa9Q4Sw70EBPdHF AwAAoLq3eEVWR1D1U21cdHEz6Ws3PsOX =o/Sz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Thomas, On 2/1/2011 7:59 AM, Kupper ext-FA, Thomas wrote: > And yes, we did upgrade from RHEL5.5 to RHEL5.6 and the tomcat > packages were upgrade. But since compiling did'nt work before I'm not > sure what the impact of this update is. Getting rid of the 'work' > directory is probably my best bet right now. I don't think Tomcat likes being upgraded while a webapp is deployed. It's best to undeploy the app (which is essentially deleting the work directory), then upgrade Tomcat, then re-deploy the webapp. Tomcat (of course) compiles your JSP files on the fly and might not try to re-compile them if it doesn't think they need to be re-compiled (it just checks file dates). I don't believe Tomcat keeps any version information in the generated .java/.class files so it will blindly run old versions that reference internal APIs that may have changed. That's the most likely reason you are encountering this problem. > I'll give that a go as soon as I got a service window and let you know. If your pages are failing every time, I think that's grounds for an emergency service window to suddenly open :) > Well, I haven't done any precompilation yet. I was just wondering if that might help pin-down the problem. Unfortunately I'm not a developer but a server admin and have no clue how a build.xml should look like that ca 'simulate' a Tomcat/Jasper precompiling. You can simulate the JSP compilation using the JSP precompiler, but I suspect that things will work properly and you won't get any useful information from the exercise. You could demonstrate that the new version of Tomcat you have in production /is capable/ of compiling those files properly... that might be a nice thing to show management. >> Also, your version of Tomcat is very old. If you are using a >> package-managed version of Tomcat, you may be stuck with an ancient >> version. Consider using the canonical Apache version to stay up-to-date. > > The version we use is the stock Tomcat for RHEL5. For now I'm stuck with that version. :( You should complain to RH, especially if you are an enterprise customer. You need to tell them that they are seriously out of date. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1IknUACgkQ9CaO5/Lv0PB/3ACgnsuxp+q5Z2zADNLcwUSy5Gx3 kYkAni4U5dw2M0AmBuOLeDlV2nXxsWGn =iZMQ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
| Powered by Nabble | Edit this page |
