Re: Changes to WM/Broker

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.

Keats

Marc Palmer wrote:

>Hi,
>
>I've just, very easily, got a basic Spring view implementation working
>with WebMacro. This means I have successfully used basic test Spring web
>applications with either JSP front end using a WM Taglib to use WM within
>the JSP, as well as a no-JSP application that only uses WM templates for
>the view.
>
>I have yet again run into issues with WM's Broker mechanism. I still
>strongly believe this is a major thorn in our sides and it needs to be
>removed or reworked.
>
>Basically in the Spring WM view implementation we have access only to our
>ServletContext, not the Servlet. All WM + Broker's constructors/factories
>need a Servlet if you want to be able to access templates from the
>webapp's directories/classpath.
>
>So for example, I have had to create a new "Servlet22BrokerPlus" (because
>Servlet22Broker has a private constructor - argh!) and add a new static
>getBroker:
>
>public static Broker getBroker (
>  ServletContext sc, 
>  ClassLoader servletClassLoader,
>  Properties additionalProperties) throws InitException
>
>In my view implementation I call this method, and I can pass in
>servletClassLoader by doing this.getClass().getClassLoader() on the spring
>view. Well, this will only work I believe if the webmacro/webmacro Spring
>JAR is not in a shared location such as tomcat/shared or tomcat/common/lib
>or endorsed. 
>
>So this in itself is imperfect but better than not being able to access
>webapp templates at all. I don't know how we can get to the servlet's
>classloader from a Spring view class. (it's the webapp classloader we want
>of course - clarifying terminology).
>
>Anyway, I therefore suggest that:
>
>1. We need to add a new constructor to o.w.WM:
>
>   public WM(ServletContext sc, ClassLoader webappClassLoader);
>
>...and as a result also new getBroker(ServletContext, ClassLoader, ...)
>methods to Servlet20Broker and Servlet22Broker (or ServletBroker if we can
>polymorphize it!)
>
>2. We make these private constructors in ServletXXBroker protected
>instead. Private is just such a pain in the ass when you need to do
>something like this without tweaking the original WM source.
>
>What say you guys?
>
>My Spring view needs more testing obviously but I'll put it forward soon.
>
>
>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