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: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 10:09:18 GMT
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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112362483115086&w=2 and 
that we have implemented part of, for testing the concept, in the 
template block. And one active way, where the block contain an own 
component manager and an component manager <-> OSGi bridge. Sylvain have 
started to implement the later approach, see 
http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2.

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

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

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.

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.

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

/Daniel


Mime
View raw message