|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
parent
|the adaptive class loader doesn't override getParent (I talked about
|this in a later mail in this thread).
Irrelevant we set the Parent in the interceptor (should be).
|> |2. The class loader of the class doing the work is the same as the
|> |remote interface.
|>
|> what class "doing the work" the local one or the one "behind Remote".
|
|The class loader of the class looking up the logic is the same as the
|class loader of the remote interface to which the looked up object is
|being cast.
Right, then it should work, I don't think it's a "parent not set" problem.
|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?
Afaik no, the ACL from tomcat picks them up... aaaaaahhhh!!!!!!!!
but now that I think about it... could that be the trick?
I mean that the ACL picks up the classes and says "yes I know how to resolve
it" and the URLCL picks for jBoss/JNDI and the VM says "nope" not the same.
hmmmm if your ACL resolves the stuff that could be it, the CL are well
installed it is just that someone down the hierarchy yells "yes, I know that
class" when it should be up...
could be? can you resolve the CL in a System.out???
|
|> 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.
yes and no ;-)
The class loader integration is something more fundamental than that.
<flame>We are all yelling and fighting religious wars about license
integration, but we are still missing "classloaderintegration" i.e. the bare
technical layer</flame>.
Let me explain, all pieces of software that implement J2EE APIs are almost
"stand alone" (by definition) and that means that all little pieces of
software (tomcat/jboss) have their own little mechanism for loading classes
in their own little implementation. You use the apache
AdaptiveClassLoader, we use the URLClassLoader.
The problem is not even that they are different classes, the problem is that
they are different *instances* of classloaders but that it is **Necessary**
since these products are supposed to work standalone.
NOW, when we integrate we need to have the SAME DEFINITION ( name+CL)
classes in the VM otherwise we get the craziness we are seeing now.
My own religious pet peeve has been for an exposure of the CLassLoaders per
Name at an "OS" layer, i.e. JNDI. So that any stack integrating could look
up the right definition of the CL for the give forName... i.e a "inVM
distributed" Class.forName() implementation that assure that we have only
ONE instance of a CL.
How do we do it today? well we use the "context" trick and we attach the CL
to the thread "at the top" (the deployer) and let that thread carry the CL
INSIDE the implementations. IF WE CAN GET the implementation to behave
correctly with this Thread COntext information then we can achieve
integration (something we do in the TomcatInterceptor courtesy of Sebastien)
but in our specific case I suspect the local classloader of the tomcat stack
say "YES" when they should defer to the Parent. Always defer to your
parents, I just had confirmation today with my own dad (love you dad, :))).
That "passing" is "implicit" in the sense that it is not an argument or a
value you look up it is passed by the thread (and it is somewhat "thread
local") and that is BAD (tm, imho). It is the simplest though, but we have
to assume people in tomcat are well behaved. I don't believe implicit
constructions are elegant and they leave too much in the open when we
integrate. At least I know we can wage a "normal" battle with humans since
we are now on the logic domain and explaining CL is feasible, but an
explicit visibility would prevent too many screw up.
Ok on to your final point... YES because we have "shared visibility of the
classes" (something the proprietary vendors DON'T CARE ABOUT) we can do
fantastic things such as the java:comp visibility on the space for our
integrated stacks. And the way we do that is with the deployer that
launches threads into the stack. It is a dynamic structure (ok, rickard it
IS elegant as a solution). But remember the visibility is important to the
stacks (I think that is what you meant anyway)and that in the case of J2EE
is App based so that could be our identifier for CL.
I rest my case
marc
|> 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.
|
|-Kevin Lewis
|
|
|
