This is an overview of the changes that have gone into the Merlin platform as part of the transition from 2.1 to 3.0. But first, a little background is appropriate. Most of the changes are driven by the impending release and the desire to cleanup stuff that has been in the back of my mind for the last few months. This mainly concerns *simplification* of the container descriptors, and *improvements* to code structure. Also, I should make a qualified confession - Merlin 3.0 inludes some feature reductions relative to 2.1. This reflects some re-engineering to facilitate plug-in kernel enhancement.
Block description simplification. ---------------------------------
Under Merlin 2.1 we had a <block> containing an <implementation> which represented the root container of the block that held subsidiary <component> and <container> defintions. Under 3.0 the notions of <block> and <container> have been converged under the single <container> concept (while maintaining backward compatibility). The <container> defintion now looks like the following:
<container name="my-container">
<!-- optional service publication --> <services/>
<!-- optional classloader --> <classloader/>
<!-- components and containers -->
<component class="aaa.bbb.MyComponent" name="sally"/>
<container name="my-sub-container">
<component class="aaa.bbb.AnotherComponent" name="fred"/>
</container>
<include name="another-sub-container" id="aaa:bbb" type="xml"/></container>
If a <component/> is declared, it will be activated on startup by default. This is different to 2.1 where the default behaviour was lazy activation. The reason for the change is that almost every example of a block that I have seen has had the activation flag set to true. The 2.1 behaviour of default lazy activation is maintained for implicitly resolved components.
Multiple versus Single Blocks -----------------------------
Under Merlin 2.1 you were restricted to defining the root block. Under 3.0 the kernel establishes the root container and adds blocks that you define to that root container. This change came about from comments from Larent and the interest of establishing a dynamic kernel that we can manage remotely. This change may impact your application bacause of the change implied in the path of the container you supply using the Merlin command line. Under 2.1 the container was implicity associated as root under the name "/" whereas under 3.0 the container is a subsidiary of root (i.e. "/your-container"). The up-side is that we can add and remove containers dynamically from the kernel.
Explicit sourcing of supplied components ----------------------------------------
The ability to explicitly declare dependencies has been requested by at least of couple of people. You can now do this inside a <component/> declaration by defining explicit <dependencies> assignments as follows:
<container name="demo">
<component name="sally" class="SomeComponent"/>
<component name="harry" class="SomeComponent">
<dependencies>
<dependency key="director">
<source>/sally</source>
</dependency>
</dependencies>
</component>
</container>One of the important considerations concerning the introduction of explicit source assignment is that we will be able to provide precise simuluation of Phoenix assembly semantics.
Repository Refactoring and Proxy Support ----------------------------------------
Under Merlin 2.1 the support for Maven style repositories sort of came in late in the day. Under 3.0 the repository infrastructure has been repositioned as a core service. In fact the bootstrap Merlin system constructs itself using the a repository bundled with the Merlin installation. Following bootstrapping, the kernel now provides a full repository defintion under which you can declare multiple remote repositories, proxy information and so on.
For more information on proxies, see: F:\dev\avalon-sandbox\merlin\merlin-platform\target\docs\meta\model\kernel\index.html
Internal Architecture ---------------------
Lots of refactoring has been happening driven partly by feedback from Berin and Leo and partly in response to interests in auto-management (and related pub level discussions here in Paris). The refactoring has resulted in a seperation of the assembly and activation notions from the deployment model notions. The deployment model is the interesting thing with respect to providing a full management environment (context, configuration, parameters, assembly bindings, deployment, decommissioning, etc.)without exposing the container hierachy. This refactoring is simply a first step towards smart-management solutions that are referenced in the roadmap.
Context Management Enhancements -------------------------------
Merlin 3.0 now provides improved support for constructed and volatile context entries. The constructed entries were possible under 2.1 but the 3.0 version better reflects asumptions made by users. Here is an example of a context directive using a couple of constructors.
<component name="test" class="Test">
<context>
<entry key="home">
<constructor class="java.io.File">
<param class="java.io.File">${urn:avalon:home}</param>
<param>xxx</param>
</constructor>
</entry>
<entry key="time">
<constructor class="java.util.Date"/>
</entry>
</context>
</component>A new feature in 3.0 is the support for volatile context entries. If a component type declares a context entry dependency as volotile, then each access to the entry results in a new instance. For example, doing context.get( "time" ) in the above example will result in a time instance corresponding to the time of the invocation. There are some test cases that demonstrate this (as part of the composition package) but nothing in the documentation just yet.
Other Stuff -----------
Lots of little nice things importing block xml descriptors from the repository, much more i18n support, better error handling, etc.
Todo ----
Pooled object support is currently suspended. Basically the approach in 2.1 was for the kernel to establish the pool manager. This needs to be reconsidered with the objective of providing pool parameterization at the level of a component declaration. More testing in the lunix environment is needed due to some changes in the command line handling, and tutorials still need to be updated. Most of the documentation is now in sync. but I think there is still more needed in terms of describing the overall architecture and usage assumptions.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
