Re: [Webmacro-devel] The webapp: I need help with WM config hassl es

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

On Wed, 26 Mar 2003 15:25:46 -0500, <kea...@na...> wrote:

> I think it would be great to add this Constructor, but it's a bit more
> complicated.  The args to the WM constructor are used to determine the
> Broker instance.  Currently the key used to retreive the Broker for a
> Servlet is just the ServletContext.  Since the broker manages the 
> settings,
> you would want a separate broker instance for each 
> ServletContext/Settings
> combination AFAICT.

Argh! I just looked at the source and you are right... bah this is why I 
hate singleton-like behaviour (vis a conversation I recently had with 
Lane!).

I don't understand what design decision led to this system of "caching" 
brokers. I'm sure there's genius hidden in there somewhere, but this 
concept of "WM partitions" and one broker per partition (just gleaned from 
the Javadocs) seems very strange to me.

How many apps create multiple WM instances that exactly the same broker? I 
would have made it so that everything uses its own new broker by default, 
and only uses a "shared" broker if it is explicitly passed to the WM 
constructor. i.e.

Broker mySharedBroker = Broker.findBroker( mySharedKey);
WM wm = new WM(mySharedBroker);

...rather than having using this hidden "sharing" mechanism.

$0.02 - and I know it's easy to say this with hindsight.

> The best approach may be to implement a new Broker class that the new WM
> constructor would use.  Then the new Broker could handle the various 
> kinds
> of settings that you want to throw at it transparently.

Hmm... how about a new ctor for WM that takes an Object that is the 
WM/broker partition "key".  I think this can be done quite easily by 
passing this key to the static getBroker methods on Broker and 
ServletBroker (and 22 and 20 Broker).

Have a quick look at the code with this in mind. What do you think? It 
shouldn't need much in the way of changes: a few new ctors for WM, and add 
an "Object" parameter to the static getBroker calls, and change it to use 
that param in the findBroker call. Existing static getBroker methods would 
be adjusted to call the new form of it, passing their current "key" (i.e. 
ServletContext) as the key parameter.

Thus, nothing should break. Perhaps my understanding of the broker 
"caching" mechanism is oversimplified?

> btw, this seems like a lot of extra complexity in order to accommodate 
> this
> particular functionality.  I'm guessing that the idea here is that this
> would require less system resources than lots of separate Web apps.  
> Perhaps
> this should be a post 1.0 enhancement?  Just a thought.  (I like to 
> follow
> the XP model of building the simplest solution first and then 
> refactoring.)

I appreciate this, but I think it's a very fundamental feature of this. 
Plus, it is already implemented. The only problem is getting each new WM 
instance to read the right settings. Once I have cracked that, it's done.

FWIW I have always cursed the fact that WM could not init from a Properties 
object!

Marc