Hi Leo,
On Tue, Aug 20, 2002 at 12:23:28PM +0200, Leo Sutic wrote:
> Marcus,
>
> thank you for your reply.
no problem, thanks for asking the questions :)
> 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.
I see. Perhaps that's another reason why the extension handlers
themselves should be regular components so they can implement
Composable if they need to access another component, rather than
use the Context.
This is a general Context usage issue though isn't it ?
Fortress doesn't do any context validation whatsoever, but Merlin
will ensure that the context object passed to any particular component
contains object/key pairs as defined in the component's x-file
dependencies. So, if a extension handler requires a context entry
Merlin should speak loudly if it's not there.
It still doesn't handle 3) as you've described above, but then, if
the context key and object type passes validation the context
object has done it's job - its a context population error if
the actual object under the given key doesn't reference the right
entity (eg. a context directory, etc) ? or have I misunderstood you
somehow ?
(btw - was it intended that Context objects only have String
objects in it ?)
> > 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.
Yes. I examined this thought too. There were a couple of reasons why I
didn't take this route.
o Each container has their own component handler implementations and
wanted to make the lifecycle extension code reasonably separate from
any container specifics.
o After thinking about it for a while I started to feel that this
in some way was breaking SoC.
ie. The handler's job is to manage the style of access to a particular
component. Using the handler api to extend the lifecycle
felt to me like I was abusing the api more than it was intended, so I
turned away from it.
Perhaps that feeling was wrong, but that in combination with the
handlers being specific to each container made me take the current
solution.
> 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?
The extra lifecycles are applied at the following times:
creation - when the component is actually created via
newInstance().
access - just before the component is returned from lookup()
release - just when the component is release()'d
destroy - when the component is decomissioned.
I wasn't aware of this particular usage pattern in Phoenix, but
the extensions will still work - they'll just be invoked during
compose()/dispose() rather than on-demand.
> 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?
(I've just seen that Stephen has answered this one on the list
already)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
