You can get more of my troubles with this from the mail archive.
However, if I remember correctly, the problems revolved around the
following:

Tomcat uses different class loaders for compiling JSPs and servicing the
resulting servlets.

Because of this, the class files necessary for compiling the servlets
must exist in the web tier (WEB-INF/{classes,lib}).  However, having
those classes available to the class loader that loads the servlet means
they are loaded by the web tier class loader.  However, JNDI (through
JNP) goes to the thread context class loader to load classes, and not
the class loader of the class doing the lookup.  This means it gets its
classes from the EJB tier.  Boom!  Class cast city.

I have to think there's an easy way around this, but I haven't been able
to figure it out.  I'm not experienced with class loaders, so I may be
missing something basic.

If you have any ideas, I may have the opportunity to try them out this
weekend (at which time I should be far less busy ;-).

-Kevin Lewis

> From: Rickard �berg [mailto:[EMAIL PROTECTED]]
> 
> Hey
> 
> Since the Tomcat integration just isn't working I have began 
> looking at
> the EmbeddedTomcat module. In a servlet in a .ear file I print out the
> context classloader. It is an AdaptiveClassLoader. But it has 
> no parent
> classloader, or rather, the system classloader is the parent
> classloader. BUT THAT IS WRONG! The strange thing is that I have put
> debug messages in the ContextClassLoaderInterceptor, and it *is* being
> called upon deployment, so that the ACL's parent classloader is right.
> But this doesn't seem to be used for some reason.
> 
> What am I missing??! Any ideas Sebastien?
> 
> /Rickard
> 
> -- 
> Rickard �berg
> 
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
> 
> 

Reply via email to