[RT] Merlin Service autoassembly / plugin infrastructure

[Yannick Menager <ym...@fastmail.fm>]

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.

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.

What do you guys think ?

If there is a strong interest on that, I just might implement it.



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

Re: [RT] Merlin Service autoassembly / plugin infrastructure

[Timothy Bennett <ex...@comcast.net>]

David Worms wrote:

>>
>> 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 )
> 
> 
> This could be applied to the http-jetty block. If I'm not wrong, we 
> wouldn't have to extend the session manager and explicitly declare every 
> dependency.

Good thinking.  This would be an especially nice solution for the 
merlin-http block.



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

Re: [RT] Merlin Service autoassembly / plugin infrastructure

[David Worms <da...@simpledesign.com>]

>
> 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 )

This could be applied to the http-jetty block. If I'm not wrong, we 
wouldn't have to extend the session manager and explicitly declare 
every dependency.


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

Re: [RT] Merlin Service autoassembly / plugin infrastructure

[Yannick Menager <ym...@fastmail.fm>]

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

Re: [RT] Merlin Service autoassembly / plugin infrastructure

[Stephen McConnell <mc...@apache.org>]

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).

>
>
> 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.

> 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.

Cheers, Steve.

>
> If there is a strong interest on that, I just might implement it.
>
>
>
> ---------------------------------------------------------------------
> 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

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|





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