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
alternative.
Yup.
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.
Yup.
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.
Yup.
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
[1] http://marc.theaimsgroup.com/?t=112177144100004&r=1&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109770175206107&w=2
[3] http://www.knopflerfish.org/desktop.html
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
