[MERLIN] status report

[Stephen McConnell]

Over the past couple of months I've been working on the assembly, meta and Merlin packages as part of the transition out of Excalibur and into the avalon-sandbox project. The transition involved a number of changes that are listed below:

1. refactoring of the classloading mechanisms (following Berin's suggestions
from way back) taking into consideration the discussions concerning a
profile driven container

2. incorporation of requirements posted under the Cocoon general discussions
relating to blocks and overall component management requirements
(Stefano, et. al.)

3. incorporation of support for the concepts and direction established in the
"context discussions" including the ability to customize your
contextualization interface (Leo's process)

4. clean separation of the assembly concerns from containment concerns
(Steve)

5. simplification of the meta XML descriptors
(derived from context discussions)

6. introduction of the notion of "blocks" as composite components
(Cocoon requirements)

7. clean separation of component deployment (under Appliance) as distinct
from development templates (under Profile)
(Gary's comments on separation of concerns)

8. improvements in XML schemas for the container and profile mode so that
naming matches usage
(Steve)

9. introduction of a bootstrap system that is independent of the extension
directories or any other jar file (enabling support for Java WebStart
based applications
(Gary with respect to WebStart requirements)

10. addition of a appliance customization layer that makes is drop-dead
simple to set up an component management engine and launch customized
components
(Steve)

11. addition of test cases

12. elimination of the necessity to explicitly declare components in
jar file (files are now auto scanned)
(Steve)

13. improvements to the logging system
(Vinay Chandran patches)

14. addition of proxy support for ComponentManager and ComponentSelector
(content from Berin in framework)

15. separation of the kernel configuration form the deployment configuration
(based on suggestions from Vinay Chandran and others)

Structurally speaking - the excalibur/assembly (Merlin 2.0) package has been split into two distinct packages - avalon-sandbox/assembly and avalon-sandbox/merlin (Merlin 2.1). The new assembly is independent of a containment strategy - it basically handles all of the stuff to do with component deployment. The avalon-sandbox/merlin handles the hierarchical containment mode and the implementation of a block concept. Just as the assembly package separates component management under an Appliance class, the Merlin package separates containment management under a Block class.
Operationally speaking there are some changes that need to be considered. The avalon-sandbox.merlin package has introduced some changes that will require some client rework - not much, but important non-the-less. These changes include:

1. the kernel.xml is now limited to "just the kernel" - i.e. it doe not contain
the definition of the container hierarchy, instead - the kernel reads a blocks.xml
file which tells the kernel the location of blocks to be loaded. Each block is an
semi-independent container hierarchy

2. the blocks.xml file contains references to the set of blocks to load. Each block
is a jar file containing the resource BLOICK-INF/block.xml. The block.xml contains
the container hierarchy definition. The container definition has been improved with the
separation of interface versus implementation - in effect each block declares the
service it provides, and the implementation in the form of a container hierarchy
under an <implementation> tag.

3. There have updates to the xinfo and xprofile resource. The xinfo resource now
supports a simpler and cleaner definition of dependencies and service declarations.
Instead of:

<dependency>
<role>rolename</role>
<reference type="foo.bar.Xxx" version="1.1"/>
</dependency>
You can use the simplified form:

<dependency type="foo.bar.Xxx:1.1" role="rolename"/>

This should be backward compatible (for a while). The xprofile resource
that contains profile templates under the <profiles> tag use to contain
profiles declares under a <component> tag - this has been changed from
<component> to <profile>. Similarly, the <container> tag in the block.xml
file use to contain <component> tags which have been replaced with
<appliance> tags to more correctly reflect the object established from the
declaration and facilitate separation of the notion of an "appliance"
from a "profile" (where a profile is simply the template on which an
appliance is established).

Demos are available in both the assembly and Merlin packages that incorporates
these enhancements - but documentation is not up to the same level - more work
to be done in that area following the reshuffle.

Aside from documentation updating, there are still a couple of more things to be done before Merlin 2.1 stabilizes - namely some more work on the context area to integrate an abstract location implementation model and handling of alias declarations, and secondly, the introduction of dynamic meta into blocks - so that things like dependencies and services can be resolved based on the computational requirements of the containment solution. However - what is ion place today in avalon-sandbox/assembly and /meta is functionally equivalent or exceeding to 2.0 and is structurally a lot cleaner. Testing and validation actions are still pending but once that is complete I suggest we drop the excalibur repository a few weeks time.

Just for reference (and because it isn't documented anywhere just yet) to run the Merlin 2.1 demo (which includes a totally custom contexualization interface demo) all you need to do is checkout the Avalon, excalibur and sandbox repositories, then:

$ cd avalon-sandbox
$ cd merlin
$ ant
$ java -classpath build\lib\avalon-merlin-bootstrap-2.1.jar org.apache.avalon.merlin.bootstrap.Merlin merlin.properties


One more thing - based on the success of the context implementation approach, I would like to see Merlin 2.1 move closer to the deployment state model I described earlier in the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonFive. To go from where we are not to that model is not a big jump in terms of the code - but I thing it will be a massive jump in terms of overall flexibility in that we will be able to support arbitrary component models.

Next step - cleaning up - polishing documentation - and getting in place a workplan for remaining feature additions and/or structural adjustments.

Cheers, Steve.


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>