cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: OSGi Bundles, Re: svn commit: r292305
Date Sat, 01 Oct 2005 12:11:20 GMT
Niclas Hedhman wrote:

>On Friday 30 September 2005 04:55, Vadim Gritsenko wrote:
>  
>
>>Also, I'm not convinced that blocks should be active (i.e. contain
>>activator) at all. 
>>    
>>
>
>Without active participation it is no more than a shared library, and as such 
>it is very difficult to swap out and replace with a new implementation 
>without restarting the entire application.
>  
>
Exactly, it is much easier to stop a service and replace it with a new 
implementation but with the same interface.

>>We should probably separate block's code from block's 
>>instance. It is especially important if you have an ability to pass
>>parameters into the block. Two Cocoon Applications will not be able to
>>share single instance of a block if its configuration differs - hence,
>>block itself is passive and is instantiated by the application.
>>    
>>
>
>I have a hard time following this discussion, as "block" is somewhat undefined 
>in OSGi terms, and _I_ don't feel I understand with it is exactly.
>Now, that said, I have assumed that a block bundle consists of 0..n block 
>services.
>
That is right. The block service(s) is what defines a block. For now the 
block service will use o.a.c.components.blocks.BlockManager as API, but 
we should strive for finding something much simpler and less Cocoon 
specific.

 From an implementation POV a Cocoon block will use a BlockActivator 
that reads COB-INF/block.xml that contains a sitemap reference, 
component configuration, a sitemap reference, definition of deploy time 
parameters and definition of connections to other blocks. It will expose 
its components as OSGi services.
...

>I am not sure what you mean by "passing parameters into the block". I have an 
>eirie feeling you are refering to "management" concerns about setting up the 
>service from the outside, and not runtime concerns during the service call.
>  
>
Yes we talk about block deploy time parameters. These should IMO be 
handled with a OSGi configuration service. But that might be something 
that we implement later.

/Daniel


Mime
View raw message