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: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
