Re: Changes to WM/Broker

Marc Palmer wrote:

> 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.

;I see your point.  I was thinking about just modifying the existing 
class.  The class hierarchy was designed to allow new broker 
implementations, so I suppose it ought to allow for extending the 
ServletBroker implementations as well.

> 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.

I see what you mean.  It sounds like a new Broker implementation that 
relies on ServletContext's resource loading capabilities would be 
useful.  I think that's what Endre is getting at.  We might even 
eventually deprecate the Servlet22Broker in favor of the this 
ServletContextBroker.

Keats

> 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