Paul Hammant wrote:
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).
Here is another way of thinking about the same thing:
SomeClass extends SomeThing implements
SomeLoggingStrategy, SomeConfigurationStrategy,
SomeContextualizationStrategy,
SomeInitizationStrategy,
SomeExecutionStrategy,
SomeDisposalStrategy
{
// the logging interface matching
// the strategy
// the configuration interface matching
// the strategy
// the contextualization interfaces matching
// the strategy
// the initialization interfaces matching
// the strategy
// the executioninterface matching
// the strategy
// the disposal interfaces matching
// the strategy
}
Then combine the above with a container that understands the notion of strategies and has a rock-solid default strategy based on Avalon 4 another for Avalon 5 and support for plug-in custom strategies (e.g. Commons Logging, Mailets?, Servlets, etc.).
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
