Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D8F0626.7000104@apache.org>
Date: Mon, 23 Sep 2002 14:16:38 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Getting rid of deprecated Interfaces/Classes/Methods
References: <Pine.LNX.4.44.0209231247390.2285-100000@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Giacomo Pati wrote:

>Hi Team
>
>I'll have some spare time this week and thought of moving the HEAD branch
>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>
>My plan will be:
>
>   1.  Get rid of Loggable in favor of LogEnabled
>

Good idea.

>   2.  Get rid of Component and move to Service infrastructure
>  
>

Dito.

>1. is straight forward and doesn't need any voting I think
>
>2. can be done in two steps:
>
>   a. move from Component to Service infrastructure as the
>ExcaliburComponentManager supports this.
>
>   b. use Fortress/Merlin (don't know the status of those and which one
>makes more sense for Cocoon to be used, so I need some advice of
>Avalonians here)
>


I'm available to help out with any tests related to Merlin.  In practice 
the ideal solution would be complete protability of components between 
either Merlin or Fortress (something that both Berin and I are aiming 
towards).  Berin has recently added lifestyle support to Merlin whcih 
bring both Merlin and Fortress to an equivalent level on that front - 
and lifecycle estensions between Fortress and Merlin are interchangable. 
 The main differences not are the Fortress orientation with role manager 
(which does not exist in Merlin) and the Merlin strong support for 
meta-info (which is at inital stage of development in Fortress).

>
>Ok, can those of you more familiar with Fortress/Merlin (Berin?) give some
>status about those ServiceManagers and also a suggestion to move the b.
>step or to postpone it for later because of the status of hose
>ServiceManagers?
>

Both Merlin and Fortress support both the ComponentManager and 
ServiceManager interfaces.  However, it's a very good idea to move from 
ComponentManager to ServiceManager because you reduce the degree of 
"Avalon" lockin.  It's much easier to use external objects as service 
providers and publish legacy applications as component solutions (and 
the transition isn't that difficult).

>
>I know using one of these ServiceManagers means rewriting the
>configuration files and/or use additional tools like phoenix-xdoclet
>
>NB: why is that tool so phoenix specific? Should be a avalon-doclet more
>appropriate or have I missed some discussion on Avalonland?
>  
>

The phoneix-xdoclet content deals with component descriptors that are 
specific to phoenix.  A more comprehensive component descriptor API that 
is used by both Merlin and Fortress is the excalibur/meta package - but 
it does not include xdoclet support at this time  Using xdoclet as the 
generation mechanism is somewhat painful (today) because the xdoclet 
APIs have yet to be finalized. As an interim mesure its easy to write 
descriptors by hand (lots of examples over in the excalibur/assembly 
package).

>What are the drawbacks I will face?
>  
>

The primary objective should be to deliver container independent 
components.  This basically means not using a container API unless you 
are specifically dealing with a deployment tool of some kind.  From this 
point of view your in safe territory if you use the excalibur/meta 
package for the component descriptors and the excalibur/container 
package with respect to lifecycle extensions.

>What do I have missed in my reflections?
>  
>

One of the main "issues" concerning ECM to "container" migration 
concerns the role management legacy from ECM.  This is included in 
Fortress but not in Merlin.  In effect the Merlin container provides 
similar functionality to the role manager through the use of the 
meta-model - at the end of the day you have a much stronger API but its 
an overhead to be dealt with when considering transition.

Cheers, Steve.

>Giacomo
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


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