Hi!
> > |1. The class loader of the remote interface is an adaptive
> > class loader
> > |(which has all the classes). It's parent is a sun.misc.Launcher...
> > |loader (maybe it should be the thread context class loader?).
> >
> > If that is the case it means the Tomcat loading is not
> > triggered by the J2EE
> > deployer. If it was you would see the proper URLClassLoader.
> > Are you using
> > the J2EE deployer for Tomcat?
>
> Yes; I have a full ear I'm deploying.
>
> To which part are you referring? That the adaptive class loader is in
> play, or that it's parent is wrong? If the latter, it may be because
> the adaptive class loader doesn't override getParent (I talked about
> this in a later mail in this thread).
Since the Tomcat integration interceptor calls setParent it should work
anyway.
> Here's a question: I have to have my application classes in
> WEB-INF/classes because I have JSPs that must be compiled and depend on
> them. Should these classes be loaded through the URLClassLoader set up
> by the j2ee deployer?
No, they should be loaded by the ACL.
> > the j2ee deployer sets the parent CL to the contextCL before
> > calling the
> > tomcat loading, the jndi uses the contextCL, jboss uses the contextCL,
> > tomcat too if deployer is used (that is part of its purpose
> > expose class
> > visibility in integration).
>
> Right. If I understand correctly, that's what gives me the java:comp
> namespace upon which I build the web app's JNDI.
Right. java:comp is switched on context classloader.
> > Are you sure you use the deployer? if so then that is buggy
>
> Yes, but maybe I'm screwing it up with the rest of my
> EmbeddedTomcatService integration work.
Could be ;-)
/Rickard
