Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <4076A8C4.8030907@apache.org>
Date: Fri, 09 Apr 2004 15:44:36 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: Framework using Merlin
References: <c53ks2$clm$1@sea.gmane.org> <40757C44.2050703@apache.org>
 <001301c41d86$ce0c6b00$b0da58ca@vijden>
In-Reply-To: <001301c41d86$ce0c6b00$b0da58ca@vijden>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Vijay Kumar AB wrote:

> Thanks for your reply,
> 
> But currently is there an equavalent for ECM in merlin? which I can use to
> the problem is I cannot expose the framework as it is confidential
> (company).

There is content dealing with migration (as opposed to emulation).  This 
is linked to the avalon-facility package which provides the bridge to 
pull based service acquisition.  This will need enhancement to handle 
property based resolution which in turn will require some updates to the 
underlying meta-model.

> Currently I am using a wrapper class which uses ECM to lookup for the
> component and returns the component to the clients who use the framework. I
> need to change that class to start using Merlin. Also I have used interfaces
> lie ThreadSafe which I don't find equvalents in Merlin. 

In merlin you declare this sort of thing via javadoc tags - for example 
the following class level tag declares the component as thread safe:

   @avalon.component name="anything-you-like" lifestyle="singleton"


> Looks to me like
> there is lot of work, but is it possible for you to give me a class which
> has main() method which uses some component manager to load a component by
> Role.

There is already the cli handler which is basically this.  There are 
also a bunch of embedded examples - from a simple main method, unit 
tests, sevlets, etc.

> I also find that the Selector, Role concepts are not found in Merlin.

Correct - Selector semantics mix component type information with 
component deployment information - which basically ties your component 
implement to a specific deployment scenario - which in turn breaks 
component portability.  The solution to this is to encapsulate the 
selection semantics within the scope of a composite component - which means:

   (a) selection semantics are moved to a specific configurable
       component
   (b) your component falls back to lock of a selector component

The avalon-facility will be updated to enable this scenario - which 
means that (a) your components will not be tied to a deployment scenario 
- but instead - they will be tied to a configurable selection service.

> How are the components identified? (Artifact??) I am not sure. Sorry but the
> documentation takes me no where.

Components are not normally identified by a component - instead you 
simply declare the dependencies that your component has and the 
container will assure that the dependency can be fulfilled before your 
component is deployed.

This is main semantic difference - merlin is pushed based, Fortress/ECM 
is pull based.  The work related to the finder facility is to enable 
reliable assurable pull-based service acquisition.

I'm hoping to cut a binary of merlin 3.3 sometime this weekend 
(providing I can resolve some issues concerning the recent version 
management updates).  Once that is out of the way I'll be able to really 
dig into the finder development and make sure we can provide not only a 
migration path - but also a gross-net-improvement in the end result.

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