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.
/Daniel
