Thanks very much for your reply...I could use some clarifications if you
have the time...
btw, I was thinking of summarizing some of the more useful background
info posted to the lists in a FAQ that I can send to you all for posting
on the jBoss website at regular intervals. Would this be helpful? Seems
to me there's a lot of great info that gets restated over and over. Is
there anyone else doing something like this? I'd hate to duplicate the
effort.
My questions...
> When a container is started for a given application, it instanciates a
> classLoader that loads from the URL that defines your repository (this is
> the base of our "ease of deployment"). The container then keeps a reference
> to the CL in its fields. (btw this CL is recreated upon redeployment such
> as when you put new files in your repository, that is what jboss automates
> for you, ease of use).
>
> Whenever an invocation reaches the container, the first thing we do is tell
> the invocation "this is the class loader that knows the classes you are
> talking about" no need for "static global" visibility such as the system
> classpath. These approaches are "broken" for a dynamic container.
What do you mean, "broken", and what do you mean by a dynamic container?
The
> programmatic way to do that is to do a
> "Thread.currentThread().setContextClassLoader(CL)". So that the thread that
> runs through our container has a proper context class loader to resolve
> classes. When a class definition is needed (say when we deserialize a
> method invocation from the client) then the VM will look into the class
> loaders in a certain order and the context one will be there with the proper
> class definition.
Why do you have to look through the CLs in some defined order? I thought
I understood from the above that there would be 1 CL per EJB application
container...why can't you just lookup the CL in a map that maps from the
target application that contains the EJB to the CL for that application?
>
> Upon exiting the interceptor stack we unset the CL.
>
> This is also the source of our problems with Tomcat in ONE VM. See in extra
> VM the stuff is serialized and when the invocation reaches the container it
> is a "byte[]" that we can resolve with the CL. In case of the Integration
> with Tomcat, ideally we would like to do invocations by passing the objects
> by reference and hence saving ourselves the pain of
> serializing/deserializing between jsp/servlet and ejb. This doesn't work
> since Tomcat works from its own classloader and when the classes reach the
> container interceptors, the class definition is not the same (it is the same
> class file but different class loader, hence different classes for the VM)
> and we get Class Type Exceptions. For now we are stuck with serialization to
> bypass this problem.
>
> The work needed for Tomcat is a sharing of the CL so that a class loaded
> from a file is consistently seen as the same one throughout the interceptor
> stacks (and since catalina
what's catalina?
Also, one last question...
I'm still wondering whether all this cool stuff you're doing with
classloaders will affect my usage of JAAS to restrict access to servlets
to authorized users. Any idea?
Thanks again,
Rick
>
> marc
>
> >
> > Thanks again,
> >
> > Rick
> >
> > > Rick Horowitz wrote:
> > > > If you have a moment, could you explain what the issue is. What is
> > > > appropriate use of Thread.getContextClassLoader()?
> > >
> > > Certainly.
> > >
> > > How would you typically do to get hold of a class whose name you know?
> > > Class.forName() is probably the first to tome to mind, so you use that.
> > > The problem is, which classloader is used? And the answer is: the same
> > > that was used to load the class whose object did Class.forName(). This
> > > is not a big problem if you're in a simple classloading environment
> > > where there is basically only one classloader (the application loader),
> > > but if you're in a more complex system, like jBoss, it won't work. Why?
> > > Because, typically the library doing Class.forName() is loaded with the
> > > system classloader (or similar, in our case it would be the server
> > > classloader, which is a child to the system loader), which means that
> > > Class.forName() would break since the class that it needs, which is part
> > > of the component using the library for example, is not loaded through
> > > that classloader.
> > >
> > > So, to fix this the library must be aware of the context in which it is
> > > being used. The proper way to do this is to do all dynamic classloading
> > > from the Thread.getContextClassLoader() classloader, since that is what
> > > was used for the particular component that uses the library at that
> > > particular point in time.
> > >
> > > Is everything clear now, or do you want me to expand on something?
> > >
> > > /Rickard
> > >
> > > --
> > > Rickard �berg
> > >
> > > Email: [EMAIL PROTECTED]
> > > http://www.telkel.com
> > > http://www.jboss.org
> > > http://www.dreambean.com
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> >
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
