cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 12:38:06 GMT
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>> Daniel Fagerstrom wrote:
>>> Vadim Gritsenko wrote:
>>>> I'd even say that at this point in time, none of the existing blocks 
>>>> should be aware of OSGi existence but only Cocoon "Kernel", which 
>>>> uses OSGi to manage (load/unload) blocks on the fly.
>>> Why?
>>> Do you have any specific design for achieving this that you are going 
>>> to propose?
>> May be I skipped important message - is there any reason why block's 
>> classes has to import OSGi?
> Yes. There are two main ways of handling blocks with OSGi, one passive 
> way that I describe in 
> and 
> that we have implemented part of, for testing the concept, in the 
> template block.

How tis 'passive' way solves dynamic unloading of blocks? And particularly I 
don't like 'build time configuration'. Does not sound like real blocks to me. 
Moving on...

> And one active way, where the block contain an own 
> component manager and an component manager <-> OSGi bridge.

Obviously, each block contains (at least) one sitemap. Each sitemap creates own 
component manager. So we have this covered.

Obviously, component manager has to interoperate with OSGi in order to get 
handle on 'parent' component manager ('Parent' here in quotes because component 
lookup strategy for that parent manager should change from what we have today.)

So no surprise here.

> Sylvain have 
> started to implement the later approach, see 
> In the active approach the inter block component handling is handled 
> through OSGi services. To be able to register a service the block needs 
> an OSGi Activator class.

(minimally, i'd think block only needs to register it's component manager 
service, everything else you can get from it)

The Cocoon Kernel will have to have an 'OSGi Activator', but not each block. You 
are not seriously planning to force each block developer to start creating their 
own activators, right? It's implemented once in kernel, and referenced across 
all blocks.

> Our hope is that it will be enough with a 
> generic ServiceManagerActivator that the block just refer to in the 
> manifest, but we don't know that yet.

Exactly my point.

> The active approach is preferable to the passive one as it makes it 
> possible for the block to just expose the API, the implementation can be 
> shielded.

Sounds good.

> Also it gives the possiblity to use different component 
> containers in different blocks in an interoperable way (ECM++, Spring, 
> Pico etc).


>> Isn't it the first goal to make (any) existing block (with no code 
>> modifications) run under OSGi?
> We could do that with the passive approach, although  the package 
> structure needs to be changed in some places. But it seemed like people 
> prefered to focus on the active approach during the blockathon.


> Wheter 
> approach we take we must start with fixing the package structure as 
> discussed before so that each block has unique packages, two blocks with 
> the same package but with different content will lead to problems'as 
> discussed before.

Everything has a price, and this is price to have 'active OSGi blocks'.

> If we follow the passive approach all blocks need manifest files where 
> all packages are exported. Also we need to implement some mechanisms for 
> using the configuration from the block, (as described in more detail in 
> the reference above).
> In the active approach we need to continue the work that Sylvain has 
> started, and we need to decide what to export from each block - 
> everything or just the API.

Best would be API only; if it makes prototyping easier - exporting everything is 
Ok tradeoff for a time being.

> Anyway, as the active approach is more scalable and the passive one 
> requires some work to be done that not will be reused if we continue 
> with the active approach, it seemed better to me (and others) to start 
> with the active approach right away.


>                       --- o0o ---
> We should IMO make a clear distinction between intra and inter block 
> aspects: within current blocks we should not require any OSGi use, thing 
> should work as before. But as inter block apects are essentially new 
> functionallity we shouldn't beforehand limit ourselves and instead use 
> the best technical solution available.

To me 'best technical solution' should blend in inter block aspects into 
ServiceManager (as additional syntax for role? or new component such as 
BlockManager?), possibly even without direct access to OSGi internals so that 
implementation details of block management are hidden.

As a side effect, blocks won't need much (if any) code changes (package 
restructuring excluded).

>>> People, at this point of time it seem rather pointless to me to 
>>> impose all sorts of restrictions on how we should implement blocks. 
>>> Instead of discussing about how to not implement blocks I would 
>>> prefer to focus on discussing how to implement them or even actually 
>>> continue implementing them ;)
>> Sorry, had no time to look at it :-(
>> I noticed though that currently there is no 'CocoonServler' which 
>> would bootstrap OSGi container, isn't it?
> We are still waiting for someone who want it enough to do the work ;) 
> More seriously I thik we can wait with that until we move to Oscar OSGi. 
> The mechanism for starting an OSGi framework is not standaridised. And 
> there migth be some issues with Java security and URL handler 
> registration when using an OSGi container within a servlet container, 
> those issues would be easier to handle in an Apache project as Oscar.

I see.

Thanks for the mail,


View raw message