[RT] Blocks that modify web.xml

[Upayavira <uv...@odoko.co.uk>]

Seeing as we're all in RT mode at the moment...

So, I remember someone (Carten?) saying that the only blocks that need 
to modify something 'core' were those that needed to modify web.xml, 
perhaps because they needed to provide their own servlet.

Surely, if, in an OSGi scenario, if a block needs a servlet, it should 
register it directly with the OSGi servlet container service, rather 
than messing with Cocoon's web.xml?

Just a thought.

Regards, Upayavira

Re: [RT] Blocks that modify web.xml

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 26 September 2005 04:20, Upayavira wrote:
> Surely, if, in an OSGi scenario, if a block needs a servlet, it should
> register it directly with the OSGi servlet container service, rather
> than messing with Cocoon's web.xml?

Has it been sorted out how OSGi platform will be positioned in relation to the 
Cocoon Servlet?? I.e. Is Cocoon a plain servlet capable of running in the 
OSGi standard HttpService? Is OSGi runtime platform running embedded inside 
the CocoonServlet? Both? Other?

If OSGi is embedded in the Servlet, it seems 'difficult' to provide a bridge 
between the outer servlet container and the OSGi HttpService. Does the 
servlet spec even allow runtime access to configuration and management yet 
(have not looked at it since 2.1 or something)?
Personally, I don't care if Cocoon would be stand-alone, but I think a lot of 
people would call it regression and get upset ;o)


Cheers
Niclas

Re: [RT] Blocks that modify web.xml

[Carsten Ziegeler <cz...@apache.org>]

Upayavira wrote:
> Seeing as we're all in RT mode at the moment...
> 
> So, I remember someone (Carsten?) saying that the only blocks that need 
> to modify something 'core' were those that needed to modify web.xml, 
> perhaps because they needed to provide their own servlet.
Yepp, this is a complete list:

a) databases
Adds the driver class to web.xml to load the driver - we could either
forget about this or make different bundles/blocks/whatever for each driver.

b) faces
Adds an own listener

c) slide
Adds own servlet and mapping

d) xindice
Adds own servlet and mapping

e) XSP and all blocks adding logicsheets
The configuration for XSP is still in the main cocoon.xconf, so this one
has to be patched for XSP and logicsheets.

In addition, I could imagine a spring support adding the listener/filter.

I think slide and xindice are only required for the samples, or am I wrong?

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/