Thanks...got it!
marc fleury wrote:
>
> > > 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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
