avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RT Merlin] Automatic composition
Date Wed, 12 Nov 2003 05:52:57 GMT


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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message