Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3F52ED1F.9050502@apache.org>
Date: Mon, 01 Sep 2003 08:54:23 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: [meta+merlin] runtime service dependencies
References: 
 <03334AAF1DF8D2119B1000A0C9E32F5803EE3101@us-pb-xmsg-2.am.sony.com>
	 <3F510C41.1030701@apache.org>
	 <1393.202.187.40.8.1062389980.squirrel@www.hedhman.org>
 <1062390838.1306.21.camel@aragorn.jadetower.org>
In-Reply-To: <1062390838.1306.21.camel@aragorn.jadetower.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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