I dislike the parameterized lookups for five reasons:
1. Not type-safe.
2. The Parameters-as-Object[] is a very weak contract.
3. Change to Framework.
4. Interferes with handling of singleton / thread-safe components.
5. Interferes with the Phoenix-style usage of components, where
you can do all your lookups in the compose() method.
The only solution I can see is to equip the component (and the
interface it is accessed via) with some kind of transaction
delimiters:
Based on Marcus's example:
interface Component {
void doOp1(URI uri);
void doOp2(URI uri);
void doOp3(URI uri);
void dpOp4(URI uri);
}
Use:
interface Component {
void beginTransaction (URI uri);
void doOp1();
void doOp2();
void doOp3();
void dpOp4();
void endTransaction ();
}
At the beginTransaction call, the component should initialize a
ThreadLocal
(or transaction-local) URI variable, which is then cleared in
endTransaction().
In effect, the beginTransaction()/endTransaction() will be used instead
of
lookup/release - with lookup moving to compose() and release() to
dispose()
of the Serviceable.
This enables use in Phoenix-style environments, where all components are
singletons. (I am seriously considering this style for all components
instead of the lookup() / release() everywhere that the ECM/Fortress
has.)
It also makes the whole thing typesafe, the contract strong, requires
no changes to framework and has no impact on singleton handling.
/LS
> -----Original Message-----
> From: Farr, Aaron [mailto:[EMAIL PROTECTED]
> Sent: den 26 juli 2003 19:05
> To: 'Avalon Developers List'
> Subject: RE: [RT] Parameterized Lookups ?
>
>
>
>
> > -----Original Message-----
> > From: Marcus Crafter [mailto:[EMAIL PROTECTED]
> > Sent: Friday, July 25, 2003 11:41 AM
> >
> > Sure, I agree we should keep the interfaces lean and mean. If this
> > solution is not the best, perhaps there's a better solution to the
> > problem that we might discover ?
>
> I kinda like the idea of Parameterized Lookups, but as Berin
> pointed out, it
> has some issues. Here's one solution:
>
> In addition to modifying the ServiceManager contract, you'd
> need to either write a new set of ComponentHandlers or
> Lifecycle Extensions. That would be the only way to
> determine how to apply the runtime parameters to the service.
>
> For example, you could have a ComponentHandler which applied
> the parameters to the contructor.
>
> Or you could have a lifecycle extension (URIEnabled or
> something like that) which used the parameters to set public
> variables or bean fields.
>
> Of course in either of these cases, you would need to extend
> the ServiceManager contract. In Fortress this could be done
> by creating your own implementation of a ServiceManager and
> an AbstractContainer which provides this ServiceManager to
> clients. Components could then cast it your new
> ExtendedServiceManager to use the new lookup mechanism. This
> however ties your components to this implementation and
> creates the same problems BlockContext does. I'm not sure
> what all this would involve for Phoenix or Merlin.
>
> Just some thoughts. It's a very interesting question.
>
> jaaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
