Re: Occasional NoClassDefFoundError, but disappears after couple of restarts
To anyone who may stumble upon this thread looking for solutions - this bug has been investigated and fixed by Konstantin Kolinko (https://issues.apache.org/bugzilla/show_bug.cgi?id=48097). The fix should be available in Tomcat 6.0.21 and later. mailto:knst.koli...@gmail.com A. Rothman wrote: I've opened https://issues.apache.org/bugzilla/show_bug.cgi?id=48097 with a sample jsp that recreates the error. Mark Thomas wrote: A. Rothman wrote: A couple months ago I had a slightly different setting but with the same strange result - NoClassDefFoundErrors which occurred on a particular jsp page in my app, but only if it was the first jsp accessed following a restart (and remained in the error state until the next restart). If it was not the first jsp accessed, then everything came up fine (with nothing in the configuration or app changing in between). I also figured it's some classloader bug in Tomcat, not entirely a race condition (since it did happen consistently), but something that manifests itself depending on the order of class loading. If you can provide a cut-down copy of that JSP that reproduces the problem on a clean Tomcat install, I'd be happy to take a look. Just create a new bugzilla entry and provide the JSP as an attachment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bizarre NoClassDefFoundError
To anyone who may stumble upon this thread looking for solutions - this
bug has been recreated in 6.0.20 with a consistent recipe, and
investigated and fixed by Konstantin Kolinko
(https://issues.apache.org/bugzilla/show_bug.cgi?id=48097). The fix
should be available in Tomcat 6.0.21 and later.
It also uncovered another blank-page bug, which is yet to be solved
(anyone who can help, pls read the bug report for details)... but that's
another story.
Thanks to everyone for the help, especially to Konstantin for his
fruitful efforts :-)
Amichai
A. Rothman wrote:
Thanks Bill - I think we've got progress!
I missed the policy file, thinking about file permissions... when I
add grant { permission java.security.AllPermission; } to the policy
file, the error goes away!
So - what's going on? It makes sense that the compiler and app runtime
would have different classloaders, one which can see the bean class
and one which can't. But what's the explanation for different behavior
depending on the order in which the jsps load? Note that the other
jsps that work ok also reference the same bean class...
Here's another clue I found: In the offending jsp, there is a creation
of a URI instance before the useBean tag. It looks like if I rearrange
a couple of lines in the jsp, moving the URI creation after the
useBean tag, the problem is solved as well (regardless of the policy
file). Unfortunately, when trying to then insert these lines in a
working jsp to try to break it, it did not break. I'm lost for an
explanation.
I tried searching for some reference stating that a useBean tag must
be the first on the jsp page (before any other variables/classes are
instantiated), but couldn't find one - is this true? (best practices
aside...)
Changing the line order is a good workaround which solves the problem
(without having to change permissions), but I'd still like to
understand what's going on - both to learn, and since there still may
be a bug somewhere to be fixed...
Finally, I added the FINEST log level and ran it in the error
scenario, and these are the lines that look relevant:
...
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Loading class from parent
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(web.SessionBean, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Searching local repositories
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: findClass(web.SessionBean)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Delegating to parent classloader at end:
org.apache.catalina.loader.standardclassloa...@6aa6aeed
...
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(web.SessionBean, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Searching local repositories
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: findClass(web.SessionBean)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(java.lang.Object, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: Returning class class web.SessionBean
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: Loaded by WebappClassLoader
delegate: false
repositories:
-- Parent Classloader:
org.apache.catalina.loader.standardclassloa...@6aa6aeed
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Loading class from local repository
...
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
...
Thanks again,
Amichai
Bill Barker wrote:
A. Rothman amich...@amichais.net wrote in message
news:965599.49.1245887723160.javamail.sys...@endor...
Yes, I've compared both the generated java files and corresponding
compiled class files from when it works and when it doesn't work - they
are identical. I think the problem is not with the bean sources, jsps,
configuration
Re: Occasional NoClassDefFoundError, but disappears after couple of restarts
I've opened https://issues.apache.org/bugzilla/show_bug.cgi?id=48097 with a sample jsp that recreates the error. Mark Thomas wrote: A. Rothman wrote: A couple months ago I had a slightly different setting but with the same strange result - NoClassDefFoundErrors which occurred on a particular jsp page in my app, but only if it was the first jsp accessed following a restart (and remained in the error state until the next restart). If it was not the first jsp accessed, then everything came up fine (with nothing in the configuration or app changing in between). I also figured it's some classloader bug in Tomcat, not entirely a race condition (since it did happen consistently), but something that manifests itself depending on the order of class loading. If you can provide a cut-down copy of that JSP that reproduces the problem on a clean Tomcat install, I'd be happy to take a look. Just create a new bugzilla entry and provide the JSP as an attachment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Occasional NoClassDefFoundError, but disappears after couple of restarts
A couple months ago I had a slightly different setting but with the same strange result - NoClassDefFoundErrors which occurred on a particular jsp page in my app, but only if it was the first jsp accessed following a restart (and remained in the error state until the next restart). If it was not the first jsp accessed, then everything came up fine (with nothing in the configuration or app changing in between). I also figured it's some classloader bug in Tomcat, not entirely a race condition (since it did happen consistently), but something that manifests itself depending on the order of class loading. I never did find out for sure what the problem was (maybe it's the sync issue Mark refers to below), but I stumbled upon a workaround, which I do not quite understand, which fixed this for good: I changed the order of the first two statements in the jsp, the first was one that accessed java.net.URI (a system class) and the second the session bean declaration (a custom app-specific class). Although the two statements were unrelated to each other and their order should not have made any difference, this solved the problem (switching them back did reintroduce the error, consistently). I still suspect the problem was with the order of classloading. So, not sure if this will help, but in the off chance that your issue is related to the one I was experiencing, you might want to try fiddling with the order in which classes are accessed/loaded by Tomcat (either via their xml reference, or their actual content's first statements) and hopefully something will work. Yes, it sounds strange, but it worked for me in a reproducible manner. Good luck :-) Amichai Mark Thomas wrote: M4N - Arjan Tijms wrote: I removed the obvious suspect, a duplicate postgresql driver that appeared in both WEB-INF/lib and [tomcat install dir]/lib. Unfortunately this did not seem to help. Last night I needed to restart the production server for a configuration change and I needed 22(!) restarts for Tomcat to start up correctly. It really seems that there's a race condition going on somehow. I mean, if it was a structural problem then Tomcat would simply never start up, wouldn't it? A reasonable conclusion. The Jboss libraries are the Jboss client libraries and are needed to consume EJBs from a remote Jboss AS instance. Maybe there are some classes somewhere that conflict with those of Tomcat, but if that would be true it's still hard to understand why starting up fails in production but never on a local workstation. Does the production box have more cores than the dev box? If there was a race condition you would be more likely to see it with more cores. Anyone has any idea? There was a sync issue in the webappclassloader fixed in 6.0.19. Although the symptoms were different, it might be worth trying 6.0.20. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bizarre NoClassDefFoundError
Thanks Bill - I think we've got progress!
I missed the policy file, thinking about file permissions... when I add
grant { permission java.security.AllPermission; } to the policy file,
the error goes away!
So - what's going on? It makes sense that the compiler and app runtime
would have different classloaders, one which can see the bean class and
one which can't. But what's the explanation for different behavior
depending on the order in which the jsps load? Note that the other jsps
that work ok also reference the same bean class...
Here's another clue I found: In the offending jsp, there is a creation
of a URI instance before the useBean tag. It looks like if I rearrange a
couple of lines in the jsp, moving the URI creation after the useBean
tag, the problem is solved as well (regardless of the policy file).
Unfortunately, when trying to then insert these lines in a working jsp
to try to break it, it did not break. I'm lost for an explanation.
I tried searching for some reference stating that a useBean tag must be
the first on the jsp page (before any other variables/classes are
instantiated), but couldn't find one - is this true? (best practices
aside...)
Changing the line order is a good workaround which solves the problem
(without having to change permissions), but I'd still like to understand
what's going on - both to learn, and since there still may be a bug
somewhere to be fixed...
Finally, I added the FINEST log level and ran it in the error scenario,
and these are the lines that look relevant:
...
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Loading class from parent
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(web.SessionBean, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Searching local repositories
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: findClass(web.SessionBean)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Delegating to parent classloader at end:
org.apache.catalina.loader.standardclassloa...@6aa6aeed
...
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(web.SessionBean, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Searching local repositories
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: findClass(web.SessionBean)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: loadClass(java.lang.Object, false)
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: Returning class class web.SessionBean
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
findClass
FINE: Loaded by WebappClassLoader
delegate: false
repositories:
-- Parent Classloader:
org.apache.catalina.loader.standardclassloa...@6aa6aeed
Jun 25, 2009 1:09:46 PM org.apache.catalina.loader.WebappClassLoader
loadClass
FINE: Loading class from local repository
...
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:48 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: Failed tracking modifications of '/WEB-INF/lib'
Jun 25, 2009 1:40:58 PM org.apache.catalina.loader.WebappClassLoader
modified
FINE: modified()
...
Thanks again,
Amichai
Bill Barker wrote:
A. Rothman amich...@amichais.net wrote in message
news:965599.49.1245887723160.javamail.sys...@endor...
Yes, I've compared both the generated java files and corresponding
compiled class files from when it works and when it doesn't work - they
are identical. I think the problem is not with the bean sources, jsps,
configuration, permissions, file locations, classpaths, etc. - because
all of these remain constant, and as such do not explain why it would
work ok in the cases where it does. You're right about having to set up
tomcat from scratch from the official sources to be certain it's not the
distro's fault - but here too the chances of a distro's repackaging of
tomcat causing a bizarre edge case in classloading during initialization
seem slim.
I'm inclined to think this may actually be a tomcat bug - since the
errors are influenced by which jsp is the first one loaded by tomcat (a
user-generated race
Bizarre NoClassDefFoundError
Hi everyone! I'm running a stock tomcat 6 (6.0.18-0ubuntu6.1) on kubuntu Jaunty amd64 and Sun JDK (1.6.0_13-b03) , with a website consisting of several jsps, some of which make use of a POJO session bean, placed in a jar file under WEB-INF/lib. I'm encountering a very strange error, in the form of a NoClassDefFoundError (pasted fully below). Related scenario: 1. It happens only on one of the pages, which happens to be the main index.jsp. 2. It happens only when this page is the first to be accessed after a restart. If any other page is accessed before it, everything is ok. 3. After the first error shows up, hitting refresh causes the error to repeat, however the stack trace is slightly different: the Caused by section disappears (and the top part remains the same). 4. After the error shows up, if the index_jsp.class file under tomcat's work directory is deleted and the page refreshed - everything is ok. 5. It happens consistently after every restart (either reboot, or /etc/init.d/tomcat6 restart). 6. It happens consistently also after deleting the entire tomcat work folder for this hostname. 7. Nothing else changes between the tests afaik - jsps, configuration etc. remain untouched. Any ideas? The full stacktrace: java.lang.NoClassDefFoundError: web/SessionBean at org.apache.jsp.index_jsp._jspService(index_jsp.java:69) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassNotFoundException: web.SessionBean at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:66) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) ... 32 more - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bizarre NoClassDefFoundError
You can assume it's placed in a jar file under WEB-INF/lib :-) The thing is, I have a feeling it has nothing to do with the actual class not being found. Because it finds it when another page loads first, or when the jsp's generated class file is deleted and recreated, and nothing in the class/jar/jsp locations changes in the meanwhile. If it really couldn't find it, it wouldn't find it in any of the scenarios where it does work, no? Further, if tomcat follows the javadocs for NoClassDefFoundError, it means The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found. So I think it finds it with no problem, compiles the jsp class (the index_jsp.class file is indeed created), but then, and only sometimes, it goes missing again moments later during runtime. Unfortunately I don't know enough about the tomcat compiling and classloading mechanisms to understand what's really going on here... Amichai Martin Gainty wrote: where is the code web.SessionBean.java compiled to? can we assume you compiled it to /WEB-INF/classes/web/SessionBean.class ? Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Wed, 24 Jun 2009 22:03:13 +0300 From: amich...@amichais.net To: users@tomcat.apache.org Subject: Bizarre NoClassDefFoundError Hi everyone! I'm running a stock tomcat 6 (6.0.18-0ubuntu6.1) on kubuntu Jaunty amd64 and Sun JDK (1.6.0_13-b03) , with a website consisting of several jsps, some of which make use of a POJO session bean, placed in a jar file under WEB-INF/lib. I'm encountering a very strange error, in the form of a NoClassDefFoundError (pasted fully below). Related scenario: 1. It happens only on one of the pages, which happens to be the main index.jsp. 2. It happens only when this page is the first to be accessed after a restart. If any other page is accessed before it, everything is ok. 3. After the first error shows up, hitting refresh causes the error to repeat, however the stack trace is slightly different: the Caused by section disappears (and the top part remains the same). 4. After the error shows up, if the index_jsp.class file under tomcat's work directory is deleted and the page refreshed - everything is ok. 5. It happens consistently after every restart (either reboot, or /etc/init.d/tomcat6 restart). 6. It happens consistently also after deleting the entire tomcat work folder for this hostname. 7. Nothing else changes between the tests afaik - jsps, configuration etc. remain untouched. Any ideas? The full stacktrace: java.lang.NoClassDefFoundError: web/SessionBean at org.apache.jsp.index_jsp._jspService(index_jsp.java:69) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at
Re: Bizarre NoClassDefFoundError
(Martin - I hope it's ok with u that I'm replying back to the list - u seem to be sending me personal replies) The bean class is in a jar under WEB-INF/lib. At no point is anything being changed there, and it has no external dependencies. When I was talking about compiling, deleting, etc. I was referring only to the jsp's - index.jsp being generated into index_jsp.java and compiled to index_jsp.class under work/Catalina/Host. The latter is the one that gets compiled ok (i.e. it finds the bean), sometimes works and sometimes not at runtime (as described in the original post), and when it doesn't work, if index_jsp.class is deleted and the browser refreshed (without tomcat restart!) - it recompiles into a new index_jsp.class and this time it does work during runtime and the page displays properly. I'm not sure if I understand u correctly - r u implying that a session bean must be a separate class under WEB-INF/classes and not in a jar under WEB-INF/lib? Amichai Martin Gainty wrote: the class needs to be compiled into one of 2 places: webapp specific WEB-INF/lib/*.jar or WEB-INF/classes system $CATALINA_HOME/common/lib jsp's are compiled to $CATALINA_HOME/work/Container/Host the jsp is jasper-compiled when first referenced e.g. http://localhost:8080/webapp/index.jsp beans should be compiled to /WEB-INF/classes.. here is an example -- in jsp form -- %@ taglib prefix=s uri=/struts-tags % s:bean name=org.apache.struts2.example.counter.SimpleCounter var=counter s:param name=foo value=BAR / The value of foot is : s:property value=foo/, when inside the bean tag br / /s:bean HTH Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Wed, 24 Jun 2009 22:47:28 +0300 From: amich...@amichais.net To: users@tomcat.apache.org Subject: Re: Bizarre NoClassDefFoundError You can assume it's placed in a jar file under WEB-INF/lib :-) The thing is, I have a feeling it has nothing to do with the actual class not being found. Because it finds it when another page loads first, or when the jsp's generated class file is deleted and recreated, and nothing in the class/jar/jsp locations changes in the meanwhile. If it really couldn't find it, it wouldn't find it in any of the scenarios where it does work, no? Further, if tomcat follows the javadocs for NoClassDefFoundError, it means The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found. So I think it finds it with no problem, compiles the jsp class (the index_jsp.class file is indeed created), but then, and only sometimes, it goes missing again moments later during runtime. Unfortunately I don't know enough about the tomcat compiling and classloading mechanisms to understand what's really going on here... Amichai Martin Gainty wrote: where is the code web.SessionBean.java compiled to? can we assume you compiled it to /WEB-INF/classes/web/SessionBean.class ? Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à
Re: Bizarre NoClassDefFoundError
You're absolutely right :-) I meant 'stock' as in I used the distro package manager's stock binary and didn't mess with it. I'm trying to find the diff/changelog of how the ubuntu package differs from the original. I thought they only change around distro-related things like paths and split configurations, but it's possible they actually change something meaningful. Amichai Caldarale, Charles R wrote: From: A. Rothman [mailto:amich...@amichais.net] Subject: Bizarre NoClassDefFoundError I'm running a stock tomcat 6 (6.0.18-0ubuntu6.1) Well, that's *not* a stock Tomcat - it's one that's been repackaged by someone at Ubuntu. It would be interesting to try this on a truly stock Tomcat - one downloaded from tomcat.apache.org. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Bizarre NoClassDefFoundError
Well I went over the changelog, and there's nothing there that sounds related... it is mostly distro details, plus a few security patches (which look related to request handling and not classloading/compiling)... Any other thoughts? A. Rothman wrote: You're absolutely right :-) I meant 'stock' as in I used the distro package manager's stock binary and didn't mess with it. I'm trying to find the diff/changelog of how the ubuntu package differs from the original. I thought they only change around distro-related things like paths and split configurations, but it's possible they actually change something meaningful. Amichai Caldarale, Charles R wrote: From: A. Rothman [mailto:amich...@amichais.net] Subject: Bizarre NoClassDefFoundError I'm running a stock tomcat 6 (6.0.18-0ubuntu6.1) Well, that's *not* a stock Tomcat - it's one that's been repackaged by someone at Ubuntu. It would be interesting to try this on a truly stock Tomcat - one downloaded from tomcat.apache.org. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bizarre NoClassDefFoundError
Yes, I've compared both the generated java files and corresponding compiled class files from when it works and when it doesn't work - they are identical. I think the problem is not with the bean sources, jsps, configuration, permissions, file locations, classpaths, etc. - because all of these remain constant, and as such do not explain why it would work ok in the cases where it does. You're right about having to set up tomcat from scratch from the official sources to be certain it's not the distro's fault - but here too the chances of a distro's repackaging of tomcat causing a bizarre edge case in classloading during initialization seem slim. I'm inclined to think this may actually be a tomcat bug - since the errors are influenced by which jsp is the first one loaded by tomcat (a user-generated race condition of sorts), and not by their content or configuration. To be certain, I'd have to set it up for a debug, which I'll do (along with running it from the original sources first, of course) if there is no other choice, as it can be very time consuming. I just thought I'd run it by the experts here to see if there's some known issue, or something about the tomcat internals which I'm unaware of, or just something obvious and silly I've missed. I appreciate the help and suggestions from everyone here - thanks :-) Amichai Caldarale, Charles R wrote: From: A. Rothman [mailto:amich...@amichais.net] Subject: Re: Bizarre NoClassDefFoundError Any other thoughts? You could actually try a real Tomcat, rather than just browsing someone's likely incomplete list of what has been changes. Have you compared the failing generated .java file with the one that works? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
