cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 08:31:44 GMT
Carsten Ziegeler wrote:

>A lot of people have asked me during the ApacheCon (and via mail) what
>the move to OSGi would mean from a user/developer perspective. So I
>think it's time to discuss this a little bit further; we already did
>this briefly at the hackathon, but of course we should continue this
>here visibile for everyone.
>(The following is how I understand/see the whole thing, please correct
>me if required).
>First of all, we have an RT about the goals for the next version[1]. As
>noted there, the goals are independent from OSGi and the vision is to
>*explore* OSGi in the next months. So actually using OSGi is not carved
>in stone, but currently it looks like OSGi is the best available


And the fact that a lot of other Apache projects are considering using 
it is a good sign also.

My personal opinion about why OSGi is hot lately despite being 
not-so-new (OSGi 1.0 was issued in 1999) is twofold:

- from a social POV, a lot of people have been trying to define 
containers with classloader isolation (which is different from what we 
use in Cocoon right now). And this led to endless discussions and 
friction about design, semantics, etc, and even community 
self-destruction (Avalon) because people could not came to an agreement. 
OSGi is written "elsewhere", by a committee. A lot of people don't like 
design-by-committee, but it happened that in this particular case, the 
spec is quite good and, well, it _is_ there and we therefore don't need 
to spend time and argue to define what a container should look like.

- from a technical POV, OSGi is lightweight and has at least 3 robust 
opensource implementations. So we just have to use one of them, and not 
spend time about writing the container. And this as an immediate effect: 
during the ApacheCon hackaton, the question that were raised where of 
much lower level than those we ever had before regarding real blocks. In 
other words, after 3 years of thoughts, experiments and discussions, we 
are now in the implementation phase.

>The most important goal for myself is 7): compatibility. I don't want to
>rewrite each and every piece of code we've done in the past five years.

I would not state it exactly as a "goal", but rather as an important 
requirement. Otherwise, doing nothing is the easiest way to have no 
compatibility problems :-)

>And I think it's as important to not increase the high learning curve by
>introducing another "thing". Ok, from what we discussed in the last
>weeks, it seems to me that we can achieve these goals.


>So, what does all of this OSGi stuff mean? OSGi provides some nice
>features, like isolated class loading and depedency resolution. And it's
>exactly this where we want to use it.
>Although OSGi is a component container by itself, we will not replace
>ECM with the OSGi one. This means for a java developer nothing really
>changes, you just use ECM like you did before or you use
>Spring/Hivemind/Pico/whatever like you did before. Everything looks the


This is what we already called the "two levels of containment" [2]. OSGi 
is to manage blocks and handle inter-block wiring whereas each block can 
have its own lightweight container, i.e. ECM or Spring or whatever.

>Underneath, our own ECM implementation will use OSGi to get components
>from another bundle, but this is totally transparent. The only thing you
>have to do is defining your block dependencies properly. By this our own
>ECM implementation will be able to lookup components from the blocks you
>depend on.
>For a Cocoon user (writing sitemaps, using xml and xslt) everything
>should stay the same. It just works like it does today.
>Now, there is one thing to consider: using OSGi means, everything is a
>bundle. So whatever you develop, it must be a bundle. Currently people
>are using totally different ways of developing. Some are using directly
>Eclipse, others are using build systems (which copy files to the webapp
>directory), others are using the compiling classloader etc. And there is
>no "single right way". For me right now, this is the challenging part.
>We must enable rapid development (we have it in the goals as number 3)
>and I think this should not require any OSGi knowledge. I hope we get at
>this point. Later on, for deployment it's ok to define the dependencies
>and whatever is required.

Yup. A minimal OSGi knowlege will be needed though, to define block 
requirements and exports. But that's mostly about writing a simple 
configuration file.

Furthermore, Eclipse (which is based on OSGi) provides a nice GUI to 
write this manifest file, and there are some cool deployment tools for 
OSGi bundles [3].

>The first time I talked with Stefano about this topic (when he visited
>us in Paderborn - gosh, is this really now nearly three years ago?) we
>talked about a smooth migration path: you could simply use your old
>applications as they are for 2.1.x without using bundles/blocks and they
>would simply still work (with all the disadvantages of course). Or you
>could "migrate" and use the (new) blocks. I'm not sure anymore how we
>wanted to achieve this, but I think the basic idea was to just deploy
>the whole cocoon application as a big single block including everything.
>On this topic, what do people expect in terms of performance? (I know it
>might be a little bit early) With OSGi we add another layer/isolation,
>so does this cost performance significantly?

No, this should have no impact on performance. Blocks add one level in 
the container hierarchy (crawled up when looking up components), but the 
use of blocks is likely to flatten this hierarchy (blocks are siblings) 
compared to deep sitemap hierarchies as of today.

So in the end, this should really change nothing.

>BTW, what is the status about the dependency definition (block.xml).
>What are we planning to use?

A lot of what's was planned to be in block.xml is already defined by the 
OSGi bundle manifest file. So it will be stripped-down to keep only what 
is specific to Cocoon blocks.




Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message