cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] The environment abstraction, part II
Date Tue, 31 Jan 2006 19:43:30 GMT
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. And as soon as a block uses these
features you need a full servlet environment and not just a http
request, response and context.
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. 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.
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.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message