Alexis Agahi wrote:
Hi,
Maybe this already exist (who knows, merlin has incredible power ;)) but it could be funky to have automatic composition feature in merlin.
What I'm thinking about, is a sort of "deployement" jar repository that would be used by an 'application' as a 'composable component'.
The question is: how can I provide application users/developpor a simple way to add plugin without block.xml modification.
This is possible today. Instead of referencing a jar file (with an embedded block) you can reference an-embedded standalone block descriptor. This is what I did in the jetty demo. The only difference between the block.xml that you embed in a jar file and a standalone version is that you need to include you implementation jar file in the classloader defintion of the standalone descriptor.
Take a look at the following descriptor:
http://dpml.net/avalon-http/blocks/avalon-http.block
Everything needed is included to run out-of-box.
However, this is not the end-game. You can also reference externally located blocks within a block. For example:
<include name="demo" src="http://dpml.net/avalon-http/blocks/avalon-http.block"/>
But in this case there are some issues to be dealt with. Firstly - including something is generally done in order to expose a service - i.e. an avalon-jetty block may expose a service enabling registration of a new context or addition of a servlet to an existing context. Naturally the service export would need to be declared in the block.
Secondly, to make this totally-cool - we need to be able to look inside a block and see what the exposed api assumptions are - because it only makes sence to include a service into an existing classloading context if that service is already known. We already pre-scan blocks to grab classloader information before creating the block - in fact we construct the classloader first then construct the container using the classloader defined by the container. What would be better is to scan includes as well and add any required apis to the container classloader. This means that the block that is included needs to differentiate between api classpath entries as distrinct from impl entries. And that is currently not possible.
What we could do is something like the following:
<container name="avalon-jetty-web-server">
<classloader>
<api>
<repository>
<resource id="avalon-http:avalon-http-api" version="1.3" />
<resource id="servletapi:servletapi" version="2.3"/>
<repository>
</api>
<implimentation>
<repository>
<resource id="avalon-framework:avalon-framework-impl" version="4.1.5"/>
<resource id="avalon-http:avalon-http-impl" version="1.3"/>
<resource id="jetty:org.mortbay.jetty" version="4.2.14"/>
</repository>
</implimentation>
</classloader>
I.e. the <api> set declares what must be available in the parent classloader as opposed to classpath reosuces required by the <implementation>.
Stephen.
Stephen.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
