Paul Hammant wrote:
Nah, mixes concerns.Nicola,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).
The CocoonServlet should be used as a servlet interface.
Then we have the CocoonCLI (currently Main.java) that connects to the command line
Future plans include
- CocoonMailet + MailEnvironment -> cocoon as a james mailet
- CocoonBean + BeanEnvironment -> cocoon as a functional bean
I don't like the concept of "beans". I think Cocoon should be an avalon block itself, and, at that point, implement a Service interface (it already implements a Processor interface which is very similar to that but was created earlier in the Stylebook days)
Like Nicola said, it's not perfect and we'll need some refactoring, but I'm pretty confident that Cocoon could be deployed as a block in a standalone avalon container and include an embeddable container (or light embeddable facade to the underlying standalone one) for its own blocks.
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.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
