cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Cocoonlet
Date Sun, 01 May 2005 20:27:20 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:


<snip/>

>> By using the Eclipse kernel, Cocoon could be the first RSP, "Rich 
>> Server Platform".
>>
>> WDYT?
>>
>> Sylvain
>>
>> [1] http://www.eclipsefaq.org/chris/faq/faq-list.html
>
>
> Cool! But not that you took my forthcomming RT ;)


Ooops, sorry :-)

> I have also been thinking in this direction the last few days. 
> Reinhard reminded me about that you had proposed OSGi 
> http://www.osgi.org/osgi_technology/index.asp?section=2 as a possible 
> kernel. So I have taken a look at that and a little bit on Equinox, 
> the new Eclipse kernel that is based on OSGi. Other possible kernels 
> are Pier's, the Geronimo kernel and Metro. Of these I find 
> Eclipse/OSGi the far most promissing.


Actually, the idea of OSGi has been running in my head for a long time. 
I discovered OSGi when working on the embedded Cocoon, as we had to make 
an OSGi bundle with it so that it can be added to an OSGi-powered system 
in a car. OSGi is widely used in embedded systems, especially automotive 
and intelligent gateways.

Then came the interesting convergence between embedded system and 
"normal" systems when the Eclipse folks decided to trash their 
proprietary kernel in 3.0 in favor of OSGi. The resulting kernel has two 
layers: OSGi takes care of all classloading stuff whereas the Eclipse 
plugin system takes manages extension points and the associated plumbing.

When learning to write Eclipse plugins a while ago, I found some 
interesting similarities between what Eclipse provides and the Avalon 
semantics we're used to. Writing plugins is amazingly easy. Firstly 
because Eclipse provides an incredible PDE (plugin development 
environment) that guides you through the various tasks needed to write a 
plugin. And secondly because each plugin being isolated in its own 
classloader, there are a lot of issues that go away. For example, using 
static attributes is no more a problem!

> I agree completely with that a micro kernel Cocoon is the way to go. 
> It would as you say give most of what we want for blocks and also 
> numerous other possiblities in building Cocoon based apps. It would 
> also help us in getting Cocoon far more managable if we package it as 
> a bunch of bundles.


Yup.

> I'm making good progess with the pipeline service aspect of blocks and 
> will hopefully be able to check in some code for it soon. When we have 
> a working prototype of that part, I'm interested in diving into the 
> Eclipse stuff.


Great!

> Have you thought about how to make OSGi work together with ECM++, or 
> can they just be considered as different layers?


OSGi could be the top-level container, allowing each plugin/block/bundle 
to use ECM++ if it wants to. But my feeling is that most blocks won't 
need to have their own container.

> Anyway, cool stuff :)


Definitely !

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message