avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [meta+merlin] runtime service dependencies
Date Mon, 01 Sep 2003 06:54:23 GMT

J Aaron Farr wrote:

> On Mon, 2003-09-01 at 00:19, Niclas Hedhman wrote:
>>Stephen McConnell said:
>>This is why I would "promote" the solution of setAbc() for
>>dependency resolution and a more generic lookup() for service
> There's no reason we can't have multiple dependency resolution schemes. 


> For example, we could support all three IoC types (as defined by the
> PicoContainer project).  I do something like that in my JingDAO project
> already.  This would also allow us to better support:
>  - older Avalon components
>  - traditional JavaBeans
>  - Pico-style components
> One issue would be determining which dependency scheme to use.  It could
> potentially be done dynamically by first trying the contructor, then any
> bean properties and finally via the service() method.  The meta-info
> might also be able to store this information, but I would like it to be
> as automagical as possible, making it easier for component writers.

You would have to include this in meta - the risks are simply too high 
that the container interacts with the component in an unexpected way.

> In the end though, you'll still be stuck with older Avalon components
> which use the service manager for both dependencies and discovery.  I
> personally would like to see the service manager used more for discovery
> than dependency resolution.

Frankly I don't think the current ServiceManager interface is a good 
candidate for dynamic service discovery. It does not provide support for 
the supply of a selection policy and its exception suite needs to be 
beefed up a lot.

This could be handled by doing something like:

   public interface Locator
       Object lookup( Criteria criteria ) throws

   public interface ServiceLocator
     extends ServiceManager, Locator{}

We can easily provide a selectable serviceable strategy such that a 
ServiceLocator could be supplied directly as in:

   public void service( ServiceLocator locator ) trhows ServiceException
      // stuff

While enabling different modes of Locator usage as a pure service .. e.g.:

   public class HelloComponent
       public HelloComponent( Logger logger, Locator locator )
           // constructor stuff

Or, classic service lookup:

   public void service( ServiceManager manager )
       m_locator = manager.get( Locator.class.getName() );


> I'm working on some ideas for this now -- should have something a little
> more concrete tomorrow.  Any other thoughts or comments would be
> appreciated.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message