Timothy Bennett wrote:
Help me out on my thinking about composition within merlin. Make sure I'm
understanding at least one of the purposes of composition...
OK
Here's an example of a server application I'm looking to build with merlin. It will need:
(1) an embedded web server (2) an embedded database (3) an embedded FTP server (4) an embedded mail server (5) plus my "application" stuff that I've either already built for phoenix, or stuff I still need to build
James already works with merlin, and I've recent gotten the Jetty-Phoenix,
HSQL, and FTP server phoenix blocks migrated to run under merlin. Each of
these "servers" have their own block.xml files (which I refer to as a
container descriptor -- don't know if that is correct nomenclature).
To be technically pedentic - they are actually container "directives"- i.e. actionable statements to Merlin that result in container creation. I generally refer to them as blocks.
Separately, they are certainly their own application. But if I combine all the block.xml files together into a single block.xml to make the beginnings of the application I'm really interested in, then:
(1) the block.xml is already getting very complicated and large with all the configuration stuff, and (2) the original "standalone-ness" of the individual server blocks begins to get lost.
Is this what composition is for? Each of these "servers" have their own block.xml, but when I want to make the "uber-server", I construct a new block.xml that "imports" these individual block.xml files? Is that the idea?
Yes.
Here is an example of a composite block.
<container name="composite">
<classloader>
<classpath>
<repository>
<resource id="demo:demo-api"/>
<resource id="demo:test-api"/>
<resource id="demo:test-impl"/>
</repository>
</classpath>
</classloader><include name="demo" id="demo:block" type="xml"/>
<component name="test" type="TestComponent"/>
</container>
If we look at this container defintion there are a number of important features. Firstly, the container contains 1 subcontainer and 1 component. The subcontainer is established as a result of importing a block.xml file from the local repository. The import "name" attribute names this container as "demo". As far as any other components are concerned, this imported container looks like a regual component. Something else to note - in the classpath we include the <resource id="demo:demo-api"/>. This imports just the service interfaces provided by the demo container. We are not concerned with (and should not be concerned with) the implementation of the demo container (i.e. the mechanisms used within the container to establish the services that is exports).
If we look a little deeper into the demo block.xml we will see how the container (a) declares that it can provide services, and (b) how it provides an implementation of these services.
<container name="demo-container">
<services>
<service type="Demonstration">
<source>manager</source>
</service>
</services> <classloader>
<classpath>
<repository>
<resource id="demo:demo-api"/>
<resource id="demo:demo-impl"/>
</repository>
</classpath>
</classloader><component name="manager" type="DemoComponent"/>
</container>
The above container defintion is the hyperthetical demo container that has been imported into our composite container. The main important point is the <services> statement. This statement declares what services the container exports and the mapping to a implementation component (in this case the "manager" componet contained within it.
If you take into consideration the fact that each container runs in its own thread with its own classloader, you would probably start to appreciate the benefits of seperating you API and implementation classes into seperate jar files. In our composite container we included the service interfaces (the demo api) so that other components in the level of the composite container could use services provided by the demo container.
All of the above is a rather simple example of composition. When you get in the application of real composition with real components and larger scale systems you may run into restrictions imposed by the implementations themselves (such as non-publication of seperate APIs which will force you to include lots of dependent jar files in any container into which you include such an application).
There are a couple of other features in merlin that help you deal with composition - these include profile management and configuration targets, but that's a subject for another email - this one is too long already.
Cheers, Steve.
p.s. Once more controls are introduced concerning local repository population, we will be able to do nice things like: <include src="http://avalon.apache.org/componets/threads/default.xml"/> (which should make like even easier).
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
