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
>>discovery.
>>
>>Niclas
> 
> 
> There's no reason we can't have multiple dependency resolution schemes. 

Sure.

> 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
         ServiceUnknownException,
         ServiceUnresolvableException,
         ServiceUnavailableException;
   }

   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() );
   }

Steve.

> 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
mailto:mcconnell@apache.org

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin



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


Mime
View raw message