Re: [Webmacro-devel] Solution to the context/classpath problem?

[Marc P. <ma...@an...>]

> > Well:
> >
> > 1. is that always guaranteed to be the case
> 
> That's what the Java docs say.  (Although I admit I don't know why they
> return it as an Object.)

Actually I was thinking, it may be that getRequestDispatcher(
pageContext.getServletConfig().getServletName()) would give us a
dispatcher for the JSP that is loaded on the webapps classloader.

I've changed the JSP taglib code to use
pageContext().getPage().getClass().getClassLoader() for now.

> > 3. it doesn't work from Spring views.
> 
> I don't know Spring, but don't you have access to the pageContext
> anywhere?

PageContext is a JSP thing. The Spring view I have is native WM for
Spring, although you can also (and I have) use the WM JSP taglib with
Spring using the default JSP view.

> > 4. it requires a lazy init of the single-instance of WM. I have added
> > this to the taglib code already, so that it can use
> ServletContextBroker.
> 
> Or we could add a new constructor to WM ...

I'll do it. I'm also refactoring my changes to make it so we can retain
the detection of Servlet20/22 and still have this functionality to specify
the classloader instead of the servlet.
 
> > The problem is you can't get WM to load context tools etc from the 
> > webapp classpath if you don't have the servlet classpath.
> 
> Unless you add a new getBroker method ... or a new Broker.

Well you still can't do that unless you can reference the webapp's
ClassLoader from somewhere reliably. 

> I don't like either, but I can't say exactly why.  It just seems to 
> violate the KISS principle.  It's a kludge that doesn't seem necessary.

Well we'll need to see how this pans out. I'm still not sure how we can
get access to the webapp classloader reliably (even with shared WM and/or
Spring JARs) in Spring. RequestDispatcher might do it but again I'm not
confident because you typically use Spring's generic DispatcherServlet
(which delegates to controller classes) which could be loaded from a
shared JAR so you probably wouldn't get the right classloader from it.

Unless anyone else has any insights I think a servletContext attribute for
the classloader is about the only option.

...hmmm although it might be possible to get a known bean application from
the Spring bean factory, or the classloader used by the bean factory. Ugh
this is all so ugly!

The trouble is there's big scope to break existing classloading mechanisms
if this isn't done right.