Re: Changes to WM/Broker

Keats Kirsch wrote:
> I don't have a problem with adding this constructor to WM and adding a 
> corresponding getBroker method to the ServletBroker.   In fact the other 
> constructors could delegate to this one so we don't have duplicate code 
> paths.
> 
> However, I don't see any need to make the Broker constructor 
> non-private.  Maybe you can explain.  Also I don't understand why you 
> think the classloader will not work if WM is in a shared path.  A webapp 
> classloader should delegate to it's parent if it can't find a resource.

1. Making Broker constructor protected: Rationale is that I needed to 
create a new broker to workaround WM's lack of getBroker(ServletContext, 
ClassLoader, ...) method and this was not possible without a major copy 
and paste from existing Broker implementations. I should have been able 
to just extend ServletXXBroker but I couldn't call the inherited 
constructor because it is private. It's pointless.

2. Classloader stuff. As I understand it there is the following issue:

If webmacro.jar is in a shared lib directory of the application server, 
and not in WEB-INF/lib isn't it the case that some application servers 
will load that lib on a different classloader to the webapp? My memory 
and gut tells me this is why the ServletXXBroker implementations jump 
through hoops to get the Servlet instance so they can get the 
ClassLoader for the servlet (== the WEBAPP classloader) as doing 
somehing like WebMacro.getClass() is typically != MyServlet.getClass() 
in this situaiton.

If webmacro.jar is in WEB-INF/lib there is no such problem.

What this then means is that if we want to be able to load webapp 
specific templates from WEB-INF/xxx etc we -must- have a reference to 
the Servlet (== webapp) ClassLoader instance if webmacro.jar is in a 
shared location... otherwise it just will not work.

The ServletContext is no good to us here because it is loaded on one of 
the main application server classloaders as part of the API, and as such 
will not find resources in the webapp's tree.

See what I mean? This is why ServletXXBroker take a reference to Servlet 
and note ServletContext.

It's problematic.

Cheers



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click