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, 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: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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
