Composite components from the Merlin point-of-view:
1. create a simple containment model:
<container name="simple">
<classloader>
<classpath>
<resource id="demo:simple-api" version="1.0"/>
<resource id="demo:simple-impl" version="1.0"/>
</classpath>
</classloader>
<component name="demo" class="Demo"/>
<!-- any other componenents or nested containers -->
</container>2. create a composite component model that includes the simple model.
<container name="composite">
<classloader>
<classpath>
<resource id="demo:simple-api" version="1.0"/>
<resource id="demo:complex-api" version="1.0"/>
<resource id="demo:complex-impl" version="1.0"/>
</classpath>
</classloader>
<include id="demo:block" type="xml"
<component name="complex" class="AnotherComponent"/>
<!-- any other componenents or nested containers -->
</container>Note that the composite container inlcudes the API classes from simple. This ensures that the API content from simple is included in the classloader that the composite container is running within. Containers in Merlin look like components to other components and participate as components during assembly.
A practicle example of this approach to composition is included in the james containment model within which there are about three level of composition mainly dealing with the cornerstone components (some of which are composite). This also allows James to be exported as a component and participate as a peer in higher level assembly and deployment processes.
CHeers, Steve.
Niclas Hedhman wrote:
Hi,
I am working on the higher-level concept of assembling existing components into higher-level components and exposing that assembly as a new Block.
There are several ways to do this, and I would appreciate any comments from others who have looked into this.
1. A tool can map the outer-layer config into the config expected by the inner-layer blocks, prior to packaging the SAR (for Phoenix). Vice versa, it can rip out the inner-blocks assembly and transfer it to the SAR assembly.xml prior to packaging.
2. The higher-level component can wrap a container inside and transfer the outer-layer config to the inner-layers at runtime. The assembly of the inner-layers are handled completely by the embedded container.
As for 1, I can manage to get this to work, but it seems like "the wrong way".
As for 2, I can not manage. Phoenix is out of the question as the embedded container, and I don't know how to go about using Merlin as the embedded container and Phoenix as the app container.
Perhaps there are other alternatives.
Shouldn't this whole issue be addressed by Avalon at its core?? If I can't create components made of other components, we will never manage to build very large re-usable system components.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
