> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rick Horowitz
> Sent: Thursday, August 31, 2000 2:07 PM
> To: jBoss
> Subject: Re: [jBoss-User] running into basic problem with pr4-beta
>
>
> Rickard,
>
> Thank you for taking the time to explain this. I have another question,
> though I'm not sure if it is related to this or not...
>
> I'm using an MVC architecture in which the view is implemented by JSPs,
> the controller by servlets, and the model by EJBs. In this architecture,
> I'm planning to use JAAS 1.0 to enforce security at the servlet level.
> Each request by a user will be checked against the JAAS policy to see if
> it is authorized for that user prior to letting the servlet process the
> request. Does jBoss do anything that will cause this not to work
> correctly, like using a new SecurityManager that will mess it up, or
> possibly the classloading approach jBoss uses?
>
> btw, is there an explanation somewhere about how you are using
> classloaders? I'd be very interested in reading it.
The kid is probably sleeping so here is the skinny.
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. 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.
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, the future tomcat is going there...). This
integration is needed with every "3rd party" provider, and since we are
seeing many proposals of publishing framework integration (1 a day almost)
that is the work that needs to be done at least once for a blueprint of how
integration works.
Also as I said the Tomcat stuff works, even in VM but we go through
serialization and that slows things down. We will try to adress this in the
near future.
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]
