avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Is the Fortress Direction Official?
Date Fri, 09 Apr 2004 14:39:32 GMT
Bruno Dumon wrote:

> On Thu, 2004-04-08 at 20:01, Stephen McConnell wrote:
> <snip/>
> 
>>fortress/ecm migration
>>----------------------
>>
>>Irrespective o9f interests in delivering an ecm/fortress facility - 
>>there remains an outstanding requirement for the delivery of an 
>>ecm/fortress migration strategy.  Based on experience with the Turbine 
>>Fulcrum project .. this is reasonably strait forward for non-pooled 
>>components.  The main problem areas concern Selector semantics - 
>>however, this can be address using the finder facility.  Today this 
>>means on-list collaboration - and form that we'll get in place the docs 
>>for general migration.  My guess is that this will be demand driven ... 
>>i.e. don't wait for it to happen - if you need it push for it!
> 
> 
> ok, I'll help to do some pushing. I could use something like selectors.
> It doesn't have to be selectors, the finder would also fit.

Good - my impression is that there are a number of people that would 
like to see a viable migration strategy.  Finder is the first step on 
that path.

> Currently the finder looks like this:
> 
> public interface Finder
> {
>     Object find( Class service ) throws FinderException;
>     void release( Object object );
> }
> 
> To have something selector-like, it should need an additional find
> method like:
> 
> Object find( Class service, String hint ) throws FinderException;

We have to kill the "hint" word - it's a key with semantics.

> The hint could be specified on the component as an attribute.
> 
> Or more generic:
> 
> Object find( Class service, Map attributes ) throws FinderException;

Better.

> whereby the attributes would be checked against the attributes declared
> on components.

Two levels to consider:

   (a) attributes at the level of the component type
   (b) attributes at the level of a service export declaration
   (c) attributes at the level of a component deployment descriptor

Classic ECM and Fortresss is based on (c) - but the end-gain here is to 
provide (a), (b) and (c).  I need a little time to clear up the current 
3.3 build but once that's out of the way we can really dig into this area.

Cheers, Stephen.


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message