I pulled src for 3.3 m2 (with jasper.runtime in common dir) and it
all started working.... cool!
Additionally, I have a much better understanding of tomcat's use
of ClassLoaders.
Thanks for the help.
-Casey
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 11, 2001 3:27 AM
> To: [EMAIL PROTECTED]
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
>
>
> Hi Casey,
>
> I agree, resolving class loader problems is not easy. But it does have a
> bit of logic :-)
>
> The solution you found ( put everything in common/ ) is ok - that's how
> tomcat worked in 3.2 and before, and still works.
>
> Resolving the problem with a separate class loader for container is a bit
> more difficult - the main benefit is that the container implementation (
> modules and libs that are used - including jaxp ) are separated from the
> web application.
>
> > attempt 1:
> >
> > For each contextInit, TagPoolManagerInterceptor called
> > TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl,
> > yet when the jsp called TagPoolManager.getDefaultManager, the static
> > reference set in setDefaultManager came back null.
>
> Try to do a println( TagPoolManager.getClassLoader().toString() ) every
> time you use it. You'll see what happens ( 2 different class loaders ).
>
> You can also try to print the parent loader.
>
>
> > Giving up on that, I tried 2:
> >
> > Use no statics, just call Context.setAttribute in the interceptor. In
> > the jsp use Context.getAttribute. The object that comes back is
> > the exact same TagPoolManagerImpl that was put there by the interceptor
> > but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for
> > that matter), I get a ClassCastException.
>
> Same problem - different class loaders -> different classes :-)
>
> > I was originally trying to follow the model of JspFactory. I modeled my
> > interceptor after the JspInterceptor, but no luck for me. I noticed that
> > sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's
>
> That was fixed recently, servlet.jar should be only in common.
>
>
> > why JspFactory works. I jared up the TagPool* classes and stuck them into
> > TC_HOME/lib/common and everything worked. Even though it worked, it didn't
> > seem right putting jasper.runtime.Tag* classes into the common directory.
> > Any help / suggestions would be greatly appreciated.
>
> jasper.runtime is now in common ( we did a number of fixes since M1 ).
> Everything that should be visible to webapps ( and jasper runtime is one
> example - since jsps are using the classes from runtime ) should be in
> common ( i.e. visible in both apps and container ).
>
> Jasper itself ( the compiler ) is in a separate loader.
>
> Think of the container as another application, that happens to provide
> some services to other apps.
>
> The common dir is what all applications are seeing ( including the
> container ). Each app has it's own local jars, providing the local
> functionality. The container provides jsp compilation, configuration,
> and other services that are used by tomcat.
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
