> > 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 dynamic container can load and reload the classes on demand (deploy
redeploy, debugging cycling as done today) if the classloader that has the
visibility on the classes is the system one you are stuck.
>
> 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?
>
There is an order in which the VM will look through classloader. the
context first the system if not found. In fact you can define the order in
which these are done.
> what's catalina?
catalina is the next iteration of Tomcat, they finally saw the "interceptor
stack" light and are providing their future implementation as a set of
stacks that do the work. The (french) dudes doing the work with craig
mclanahan seem to know what they are doing. It will then be a breeze to
integrate into jboss since we will just add the stacks to provide the full
j2ee stack in one breeze, think of it as a functional "push-pop" stack where
every layer is JMX managed and replaced and configured and started and
stopped...
FYI AFAIK the EJB3.0 spec is taking that route :)))) we are already there
;-)
> 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?
Well I was answering the "how do you use classloaders" question ;-)
For that particular question I don't know :)
marc
>
> 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]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
