cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [RT] The environment abstraction, part II
Date Wed, 29 Mar 2006 06:39:31 GMT
On Thu, Feb 02, 2006 Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
> >Daniel Fagerstrom wrote:
> >>AFAIK you can't call filters and listeners from within servlets, so they 
> >>are at the servlet container level, and I don't see how a block would 
> >>need them. A block could certainly need something that a listener put in 
> >>a context attribute or that a filter did to the request, but that is 
> >>another question.
> >>
> >There was recently a discussion here about adding a servlet listener for
> >some functionality in the xsp block - I don't know what, but the
> >important message is that this will happen and already happens: some
> >blocks need more than just the servlet: like listeners or filters or
> >whatever the servlet spec requires.
> As I said, servlet listeners are for putting something in a context 
> attribute so that it is available to the servlet. With blocks we have a 
> sophisticated component layer that is available for all blocks, so I 
> fail to see why anyone would need to use a servlet listener at the block 
> level. You need to go into the details of the above usecase to convince me.
> Filters might be usable within blocks, but it is a rather crude 
> mechanism compared to pipelines, so I need usecases to become convinced 
> that it would be worthwhile to support.
> >And as soon as a block uses these
> >features you need a full servlet environment and not just a http
> >request, response and context.
> Question is still why a block would need them.
> >In addition, I could imagine that Cocoon provides filters which might be
> >used by other web frameworks running in the same web app as Cocoon.
> >I might be wrong, but I think another issue is if you are using spring.
> >Spring is initialized through a servlet listener and is assuming a
> >servlet context to work properly. So as soon as you don't have the
> >listener, you can use Spring in that way.
> IIUC, the idea is that you start a Spring container complete with 
> component configurations and everything in a servlet listener, then it 
> makes it service manager available from within the servlets through a 
> context attribute.
> I'm rather certain that we would prefer a less primitive Spring 
> integration in the blocks architecture. One where the Spring container 
> is started within the blocks architecture and where a block can contain 
> Spring managed components with its own component configuration.
> >Of course there are other ways
> >of using Spring which would also work in a CLI but they do not leverage
> >the special web functionality. So you either don't use that or you have
> >two versions, one for the Cli and one for the web.
> As described above "the special web functionality" is a hack around the 
> fact that servlets are more isolated from each other than one would 
> prefer from a system building design POV, blocks was created to address 
> this issues with the servlet architecture.
> >I can imagine more scenarios for these kind of things and we could avoid
> >all of them. The only drawback - if you want to call it drawback - is
> >that the CLI is firing up internally a servlet engine. But I could
> >imagine that this "clarification of environments" would also make the
> >work for Forrest easier in the end.
> I think it would be enough if we provide a lightweight CLI that just set 
> up context, request and response. If someone want to use Forrest in a 
> full servlet container I wonder if there really is any usecases for 
> needing to do that from the CLI, why not just use a web server in that case.

Hi Daniel, sorry i cannot understand that last sentence.
Would you please re-phrase it.

We currently have the three ways:

'forrest run'
Starts its packaged Jetty and uses Forrest/Cocoon as a webapp.

'forrest war'
Builds a projectName.war ready for deployment in a full Jetty
or Tomcat.

'forrest site'
Calls the Cocoon CLI to generate a static set of docs.


View raw message