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]
