cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 07:40:31 GMT
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
alternative.
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.
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
same.

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.

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?

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

Regards
Carsten

[1] http://marc.theaimsgroup.com/?t=112177144100004&r=1&w=2
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message