cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 07:53:46 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
> 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?

Just replying to this bit - Daniel showed me the block.xml before he 
left ApacheCon. It looks pretty simple. Also, given all the other 
'dependency' files we will/might need (gump.xml, manifest, maven project 
files, etc) in a discussion it was suggested that we're better of 
sticking with our own blocks.xml file - we can always generate anything 
else we want from that.

So, AFAICS, blokc.xml stays as Stefano proposed it.

Regards, Upayavira

Mime
View raw message