tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Rothman" <amich...@amichais.net>
Subject Re: Bizarre NoClassDefFoundError
Date Mon, 02 Nov 2009 10:50:18 GMT
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@amichais.net> 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@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.
>>>>
>>>>
>>>>       
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>   
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message