Intermixed...
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Friday, November 15, 2002 2:58 PM
> To: Struts Users Mailing List
> Subject: Re: [OT] Tomcat class loading
>
>
>
>
> On Fri, 15 Nov 2002, Sri Sankaran wrote:
>
> > Date: Fri, 15 Nov 2002 14:38:40 -0500
> > From: Sri Sankaran <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts-User <[EMAIL PROTECTED]>
> > Subject: [OT] Tomcat class loading
> >
> >
> > It seems as if the class-loader that loaded a particular class
> > maintains some kind of reference to the class. Any dependent class
> > can be loaded only by this loader or any one up the Tomcat hierarchy
> >
> > Bootstrap
> > |
> > System
> > |
> > Common
> > / \
> > Catalina Shared
> > / \
> > Webapp-1 Webapp-2
> >
> > So in other words, if Class-A is loaded by the Common
> classloader and
> > Class-A requires Class-B the search will only be conducted by the
> > Bootstrap classloader, the System classloader and the Common
> > classloader (in that order).
> >
>
> If you are just doing standard Java style instantiations:
>
> Foo f = new Foo();
>
> then you are correct -- Java looks up but not down. In fact,
> there is no way to go down, because a java.lang.ClassLoader
> instance has no knowledge of other class loaders that
> consider it to be a parent.
10-4. What I meant to ask is, is there any association maintained between the loaded
class and the class loader that loaded it?
Here's what I saw today in resolving a classpath issue:
Suppose Foo above is required by a webapp and is loaded by the Shared classloader.
Now, if Foo references Bar, only the Bootstrap, System, Common and Shared classloaders
are apparently being queried. Even though Foo is being used by the webapp. Is this
expected behavior?
>
> However, there is a workaround for the very common scenario
> that something in the Common class loader needs to
> instantiate a class from a webapp (for example, you want to
> put struts.jar into common). There is a Java thing called a
> "context class loader" attached to each request processing
> thread, and the app server will generally (required in J2EE
> 1.4, but commonly implemented in current servers) store the
> webapp class loader for the current webapp there. Thus, if
> you want to load class "com.mypackage.MyFoo" out of the
> webapp class loader, you could say:
>
> // Get reference to the class loader for this webapp
> ClassLoader wacl = Thread.currentThread().getContextClassLoader();
>
> // Load the desired class from this class loader
> Class fooClass = wacl.loadClass("com.mypackage.MyFoo");
>
> // Instantiate an instance of this class
> Foo foo = (Foo) fooClass.newInstance();
>
> If you look into the Struts 1.1 method
> RequestUtils.applicationClass(), you'll see that it uses this
> technique. Because of that, you should -- in principle -- be
> able to put struts.jar into the common class loader in
> Tomcat, and things should still work. (There may be some
> corner cases we haven't caught yet, but it *should* be possible).
>
> Note that this won't work at all for Struts 1.0, because that
> code doesn't use the context class loader.
>
> > Is this correct?
> >
> > Sri
> >
>
> Craig
>
>
Sri
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:struts-user-help@;jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
