cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Blocks that modify web.xml
Date Mon, 26 Sep 2005 19:57:16 GMT
Upayavira wrote:
> Vadim Gritsenko wrote:
>>> Well, we have briefly talked about the fact that we need to support 
>>> both scenarios. We need to be able to run the Cocoon servlet within 
>>> an OSGi framework, and this will probably be the default option, and 
>>> we also 
>> I can not imagine who or in what environment will ever run this, and why.
> You're saying that, as far as you're concerned, Cocoon should _just_ be 
> a servlet, and OSGi should be embedded and invisible?

(don't forget command line, portlet, or any other 3rd party environments too)

Yes, and I've not seen how it can be otherwise (i understand that it's possible 
to use current osgi http service for an R&D process, i'm mostly talking about 
production deployments).

> Well, that's not the way that OSGi works.


> You start a framework, you 
> start a servlet container bundle, then you start your servlet bundle, 
> all within the OSGi framework.

Replace 'you' with 'program', name this program CocoonOSGiServlet, and we have 
something working. No need for servlet & servlet container bundle, though. 
CocoonOSGiServlet will create Environment, and pass it on to the TreeProcessor 
as usual, which can have mounts for different blocks - if blocks are used at all.

Remember, it is always easier to do small steps than one huge leap into unknown :)

>>> need to support running an OSGi framework within a servlet (and a 
>>> Cocoon servlet within that OSGi framework), for those that _must_ run 
>>> Cocoon in a servlet container, such as JBoss, etc.
>> This seems to me like the option used by most Cocoon users. IMHO, for 
>> an average Cocoon user it should not even matter whether you buried 
>> OSGi somewhere inside Cocoon or not.
> This may be the way used my most Cocoon users at the moment, yes. 
> However, many Cocoon users just want to start Cocoon, they're not fussed 
> about a servlet container, that's just a complication. For those, the 
> OSGi approach will work.

It might go well while you are developing an app... As long as you can keep said 
app isolated from other pieces you have to be integrated with (which is usually 
not the case).

> For the more aware, and perhaps constrained (e.g. by corporate 
> requirements for a specific servlet container), will require the ability 
> to run within a container.

Include here hosted apps: as long as there is no abundance of "OSGi hosting", 
you will have to bundle your app as a war.

Include here integration with existing apps: as long as you have investments 
into j2ee or some other technology not available under OSGi, you will prefer 
using Cocoon as a servlet.

Forcing OSGi will limit applicability of Cocoon in many (imho, almost all) 

> To do it the other way brings up some issues that will need to be 
> resolved. We will need to write a servlet that will defer requests to 
> the OSGi framework.

Exactly my point. I never questioned this.


View raw message