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 08:24:10 GMT
JD Daniels wrote:
> Ok, I have a question from a user perspective. I have a large, basically 
> company-wide build system. Each of my own projects has its own build, 
> which is included in a "domain" project. I have as an init task to build 
> cocoon, then all my little projects depending on a properties file 
> whether to include them. Then an awful lot of complicated xpatching to 
> get my final web.xml, cocoon.xconf, and sitemap.xmap.
> 
> will I be able to port (for lack of a better word) these projects into 
> an osgi bundle? ( they all use the CHS design ) how will the hibernate 
> setup and sitemaps be integrated? I have a file in each project 
> pipelines, logging, menus, etc that get patche din during the build. I'm 
> wondering if the goodness of osgi in cocoon will take care of this.
> 
> I am asking because I get the impression the osgi will be "hidden" from 
> me at the level I use cocoon.

Well, as far as OSGi is concerned, no, it won't manage that sort of 
stuff for you. All it will do is manage components from other bundles.

However, already in trunk you have the ability to specify xconf snippets 
in your sitemap, meaning you don't need to patch the core one. As far as 
the web.xml file is concerned, I'd want to see us store the init-params 
in a context independent manner. Where that will be, I don't yet know.

If you want to use xpatch while building your blocks, that's fine!

Personally, I want to see this patching process die, as quickly as 
possible. While it works, it really isn't straight-forward. All 
configuration for a block should either be in the block, or be provided 
at the time you install the block. (e.g. mount point). And the core 
Cocoon should require _NO_ patching at all, even when configuring really 
complex apps - it should be a binary black box to many users.

Hope that helps.

Regards, Upayavira

> Upayavira wrote:
> 
>> 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