Marcus,
thank you for your reply.
> > The problem with populating the context with any
> non-constant entries
> > (such as a Spifficator) has already been discussed and
> found to have
> > no solution short of mind-reading the programmer and
> sprouting new code
> > on startup/linking.
>
> I think this must have been before my time here, is
> there a reference
> you can send me so I can read up on what was discussed ?
The basic argument is this:
1) The context requirements are a property of the component type.
For example, *all* components of type X requires that context
key Y gives you a Z. All LeoComponentImpls requires that
"context-root"
gives you a File that points to the context directory. (The actual
directory pointed to can vary between different instances of
LeoComponentImpl, though.)
2) Specifying that LeoComponentImpl requires a File with context key
"context-root" is no problem.
3) Telling the container that it must be a context directory is. There
is no way to tell the container that "you know, the File object you
put there is a context directory." without the container having a
facility for supplying context directories. To illustrate, how would
I
express a need for an entry named "price-tea-china" with the current
price of tea in China?
4) So you can do it two ways: Manually give it as a constant in the
config (the Merlin way, as I understand it), or supply it via a
component (Merlin?). The first way makes the Context a Configuration
with non-string values. The second makes the Context a
ServiceManager.
> If you only needed the handler 'component'
> once, you wouldn't worry
> about defining a new lifecycle stage for it.
> But imagine the case
> when you have many components that you want to add such
> 'component decorating' functionality to.
I would then use composition.
Start with ThreadSafeHandle and PoolableHandler. Both instanceof
interface Handler {
public Object get ();
public void put (Object o);
}
Create
class LeoHandler implements Handler {
Handler delegate;
public void configure (Configuration config) {
createDelegateFromClass (config.getAttribute
("delegate-handler-class"));
}
public Object get () {
Object o = delegate.get ();
// post-process o
return o;
}
public void put (Object o) {
// pre-process o
delegate.put (o);
}
}
Now all you need to do is specify the delegate handler and you're done.
> Hope that helps mate ? :)
It does.
Just two more questions.
How do you handle the Phoenix usage pattern of doing all lookup() in
compose() and no release(), or release() in dispose()? When is the
extra lifecycle applied?
Where is Merlin 2.0 's lifecycle extensions. Stephen told me to check it
out,
but I looked in excalibur/assembly and what I found was the
Creator/Accessor
stuff. I'm not that keen on wading through all of Merlin to find the
code
he told me to check out - so could you give me a ViewCVS URL?
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
