Have been thinking about how to move forward with
Fortress/Merlin convergence.
Here is a summary of what I see needs to be done:
(a) enable Merlin to handle ECM/Fortress semantics
on component lookup
(b) enable Fortress to use Merlin assembly of
components
(c) enable easy (transparent) deployment of
components in either container (i.e. launch a
Merlin component in Fortress, or lauch a
Fortress/ECM component in Merlin)
Lookup semantics:
-----------------
Currently the Merlin Service/ComponentManager implementation
is hard-wired to use role based lookup. I.e. the key passed
in under the lookup parameter must correspond to a role name
declared in a xinfo file (which defaults to an interface
classname). No support is provided for selector semantics.
The service/.component manager logic can easily be made
pluggable through a declaration at a component or container
level. Advantages of making the declaration at a component
level is that the policy is colocated with the component.
Disadvantes are that (today) that declaration would be merlin
specific - unless there is a specifciation of an "Avalon"
level lookup processing policy - e.g:
avalon:lookup.policy=resolve (interpritation of the value)
avalon:lookup.policy=match (no interpritation)
Apply properties at the container level (i.e. setting a default
policy at the level of the container) would mean that all of the
components contained in that container would default to the
container value. This would make deployment of existing ECM
style components easier.
Openening up the Merlin Assembly as a Service
---------------------------------------------
Following on from some questions on the avalon-user list I've
been looking at how I could implement an assemably service using
the Merlin implementation. The objective would be to provide a
very simple solution to the assembly of a component - so
developers would never have to for things like lifestyle handling
in their own code.
Transparent Deployment
----------------------
Markus has been working on the configuration converstion tool xfc
which aims to provide translatation between different deployment
formats. To assist in this work I'm planning on move the Merlin
meta model content out of Merlin and into the excalibur/mata
package but built as a seperate jar file. There merlin/model
content is well seperated from the Merlin implementation
(although there I'm not completely happy with a couple of points).
In the meantime, I think its worth moving it across so that work
related to xfc can leaverage this more easily.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
