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. -David
