cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The environment abstraction, part II
Date Thu, 02 Feb 2006 11:05:42 GMT
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.


View raw message