avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yannick Menager <ymenager...@fastmail.fm>
Subject Re: [RT] Merlin Service autoassembly / plugin infrastructure
Date Mon, 24 Nov 2003 23:06:46 GMT


Stephen McConnell wrote:
> 
> 
> Yannick Menager wrote:
> 
>> I have been working on some apps that have require a plugin 
>> infrastructure.
>>
>> However merlin doesn't really handle that kind of things very nicely. 
>> First there's the lack of selector that already has been discussed, 
>> but more, classloading needs to be manually edited to include blocks 
>> which might contain such service implementations. 
> 
> Classloader definitions can be programatically modified by this is 
> complex territory.  If (and there is a very big if here) you need to  
> expand a classloader (as opposed to branching a classloader) then you 
> basically have to take the classloader down (which means taking down all 
> of the components and suspending all consumers), modify the classloader 
> metamodel, revalidate and redeploy the classloader, and all of the 
> components.  On the otherhand - if the API of the components you want to 
> plug in are already in the classloader - then you talking about 
> branching which is comparitvely drop dead easy (just add a block to the 
> block you want to plug in to - this will result in a new classloader 
> branch automatically).

Yes i'm thinking about branching.... so you have already the block X 
with the interface Y ... and you request for all implementations of the 
service Y, in all jars present in the local repository.

>> What I was thinking, is that it would be nice to implement a 
>> functionality where a module could actually request all services X, 
>> without indicating the classloading dependencies. Of course in order 
>> to do that, merlin would need to have a cache index of which jars 
>> contains which services, and then use that to provide the service 
>> requestor with a list of available implementations. 
> 
> This is what the block defintion provides this - it *is* the persistent 
> defintion of the classloader dependencies for a particular deployment 
> scanario.

Yes but at this time it does not keep an index of all the repository 
jars metadata

> 
>> What do you guys think ?
> 
> I think I need a more complete picture of the definition of plugin (that 
> you have in mind) and how this differs from the plugging in of a block 
> as a child of another block.

The difference, is that you have to *declare* the child of a block. What 
I'm talking about is that he will automatically add the childs based on 
the Service I requested ( so it will look in it's index of service 
implementations, and add all the blocks that implement that service )



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


Mime
View raw message