Re: Objects in Vector are loosing type - classload problems

[David Wall <dw...@myEastside.com>]

> I have to restart tomcat each and every time I make one single change to
> _anyting_ of my code. This is the most time consuming part of developing
> on Tomcat, I feel. (How's Jetty doing, btw??)

Of course, you are free to use any implementation, or you could even submit
an example of how to fix it.

Personally, I think the classloader scheme itself is rather broken, which
apparently is why there are so many problems.  It seems absurd to me that
the classloader "hierarchy" only allows you to go UP, but now down.  We've
seen this problem so many times, such as when using JMS and wanting to put
the JMS files in a base classloader (like on the CLASSPATH) or JCE/JNDI code
that may be loaded in the initial classloaders because they are defined in
lib/ext or in java.security properties file.  If you call those libraries
and they need to serialize your object or anything, they can't do it because
your object was probably created using the classloader created by the Tomcat
context.  I can see that the first check for a class should be in the
current classloader, then it can move its way up the hierarchy to the top
level classloader, but if it's not found, it would be great if it could then
start to look DOWN the hierarchy to see if it can find it.  I suspect
there's some odd security reason not to do this, but it seems unlikely since
you first give the system the ability to look up the chain and only go down
if it's not found.

But Tomcat 4.0 was supposed to fix things, but my quick test shows there are
still problems keeping the classloaders all separated.  When I run two
virtual host contexts in the same Tomcat instance, and both contexts make
use of JMS, JNDI, JDBC and JCE, there's always a conflict that makes it not
work (like static/singleton instances being created under one context being
"reused" in the other context).  By putting them in separate Tomcats,
everything works.  So, there's either a longstanding bug in the Tomcat 3.2
and 4.0 classloader scheme, or there's a basic conflict in the behavior of
classloaders that is really not workable.  This probably gets even worse in
EJB worlds, but I'm not sure.

David