Stefano,
Some separation of Cocoon kernel services from Cocoon using webapps with (I'm guessing) the need for some Avalon lifecycle interfaces to be honored for this type of Cocoon deployment. Particularly ServiceManager.
Sorry Paul, I don't get this. Too concise ;-)
Could you please expand? Thanks.
I love code examples :
CocoonKernelUsingCocoonServlet extends HttpServlet, implements Serviceable, Startable { public void doGet( // blah ) { // blah }
public void service( ServiceManager sm) { // blah }
public void start() { // blah }
public void stop() { // blah }
}
I.e. the Servlet container also (non servlet spec) provides Avalon lifecycle to servlet (if implemented as ever).
Nah, mixes concerns.
The CocoonServlet should be used as a servlet interface.I was not thinking of just Cocoon. A extended framework for anyone's special needs servlet.
Note, however, that Cocoon *must* be able to run as a servlet and still be fully functional, so it must be able to include an embeddable container which is capable of all the things that we outlined in the Cocoon Block design specs.Goes without saying.
My thoughts were that there would be two entry points for Coocon. One the traditional servlet and one that delegates to an external (servicemanager provided) Cocoon engine..
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
