|
»
Bizarre NoClassDefFoundError
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
Bizarre NoClassDefFoundError
by A. Rothman
::
Rate this Message:
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-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
|
|
RE: Bizarre NoClassDefFoundError
by Caldarale, Charles R
::
Rate this Message:
> From: A. Rothman [mailto:amichai2@...]
> 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
by A. Rothman
::
Rate this Message:
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:amichai2@...] >> 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
by A. Rothman
::
Rate this Message:
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:amichai2@...] >>> 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-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: Bizarre NoClassDefFoundError
by Caldarale, Charles R
::
Rate this Message:
> From: A. Rothman [mailto:amichai2@...]
> 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. |
|
|
Re: Bizarre NoClassDefFoundError
by A. Rothman
::
Rate this Message:
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:amichai2@...] >> 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. > > |
|
|
Re: Bizarre NoClassDefFoundError
by Bill Barker-2
::
Rate this Message:
"A. Rothman" <amichai2@...> wrote in message news:965599.49.1245887723160.JavaMail.SYSTEM@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 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. > It actually looks a lot like a permissions issue, since the Bean class will be loaded in trusted (Tomcat) code when the page recompiles and will then be available for everyone else to use. You could try setting up a copy of your Tomcat (on, say a developement box) that doesn't use a SecurityManager and see if you can reproduce the problem there. You might also get some more information by setting: org.apache.catalina.loader.level=FINEST in your conf/logging.properties file on a system using a SecurityManager (very much not recommended for an active production system). > I appreciate the help and suggestions from everyone here - thanks :-) > > Amichai > > > Caldarale, Charles R wrote: >>> From: A. Rothman [mailto:amichai2@...] >>> 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. >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Bizarre NoClassDefFoundError
by A. Rothman
::
Rate this Message:
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.StandardClassLoader@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.StandardClassLoader@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" <amichai2@...> wrote in message > news:965599.49.1245887723160.JavaMail.SYSTEM@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 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. >> >> > > It actually looks a lot like a permissions issue, since the Bean class will > be loaded in trusted (Tomcat) code when the page recompiles and will then be > available for everyone else to use. You could try setting up a copy of your > Tomcat (on, say a developement box) that doesn't use a SecurityManager and > see if you can reproduce the problem there. > > You might also get some more information by setting: > org.apache.catalina.loader.level=FINEST > in your conf/logging.properties file on a system using a SecurityManager > (very much not recommended for an active production system). > > > > >> I appreciate the help and suggestions from everyone here - thanks :-) >> >> Amichai >> >> >> Caldarale, Charles R wrote: >> >>>> From: A. Rothman [mailto:amichai2@...] >>>> 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. >>> >>> >>> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > > |
|
|
Re: Bizarre NoClassDefFoundError
by A. Rothman
::
Rate this Message:
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.StandardClassLoader@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.StandardClassLoader@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" <amichai2@...> wrote in message >> news:965599.49.1245887723160.JavaMail.SYSTEM@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 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. >>> >>> >> >> It actually looks a lot like a permissions issue, since the Bean >> class will be loaded in trusted (Tomcat) code when the page >> recompiles and will then be available for everyone else to use. You >> could try setting up a copy of your Tomcat (on, say a developement >> box) that doesn't use a SecurityManager and see if you can reproduce >> the problem there. >> >> You might also get some more information by setting: >> org.apache.catalina.loader.level=FINEST >> in your conf/logging.properties file on a system using a >> SecurityManager (very much not recommended for an active production >> system). >> >> >> >> >>> I appreciate the help and suggestions from everyone here - thanks :-) >>> >>> Amichai >>> >>> >>> Caldarale, Charles R wrote: >>> >>>>> From: A. Rothman [mailto:amichai2@...] >>>>> 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. >>>> >>>> >>>> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
