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
