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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
