Background ----------------
We (chefproject.org) are (in our version II) building a market for portable applications by providing an application development methodology and framework. Part of this is to use service APIs and plugable components using the Avalon Framework paradigm and classes. Another part of this is to use standard Java Servlets and Portlets. We also refer to the full standards of Servlets / Portlets and Avalon for use in this framework.
We are not including any particular Servlet container (such as Tomcat), Portal engine (such as Jetspeed), or Avalon Container (such as Fortress) in our standards (although they will be supported options). Any choices should work; the Servlet, Portlet and Avalon Service using and implementing code will not have to change.
There's only one thing missing from Avalon Framework to allow us to do this. We need a standard way to have non-avalon-component code access the service manager and logger. There may be ways to do this that are packaged with some of the containers (such as Fortress), but not in the Framework itself.
Proposal ------------
I propose that we add two standard but optional things to the Avalon Framework.
These are standard, in that they are considered part of the framework, and so will be followed to by all the rest of the Avalon software (containers) and, we hope, the Avalon developer community.
Optional, because if an Avalon Framework user is not building a Servlet or Portlet, they will not want to have this stuff around, since it will depend on javax.Servlet and javax.Portlet to compile. These would be packaged in separate downloads or something, so they are available but not a burden.
These define:
class AvalonServlet
and
class AvalonPortlet
AvalonServlet extends the javax.Servlet class, adding two access methods.
AvalonPortlet extends the javax.Portlet class, adding the same two methods:
org.apache.avalon.framework.service.ServiceManager getServiceManager();
org.apache.avalon.framework.logger.Logger getLogger();
In this way, Servlets and Portlets which declare themselves AvalonServlets and AvalonPortlets have a standard way to get access to the Avalon serviceManger and logger.
This will work by having a serviceManager and logger placed into the ServletContext under a set of standard keys defined by the Framework. The actual creation of these objects and their placement in the context is not a framework responsibility, but instead is something the container optionally provides, in much the way that Fortress's FortressContextListener does now.
Fortress's Listener is a ServletContextListener, registered in the web application, which is called when the web app's context is created and destroyed. It creates and destroys the Avalon container. It has a convention for configuration of the container. Other embeddable containers would have a similar feature so they can be used in this way. The only changes for Fortress to comply with this new proposed framework standard are a) change the key used for the context, and b) add the logger to the context, too.
The implementations of getServiceManager() and getLogger() are simply to get the object from the servlet context using the standard key.
* * *
If we like this so far, there are probably some details to work out.
Such as the GenericPortlet, and GenericServlet and HttpServlet. These abstract base classes are common to Servlet and Portlet developers, and we probably need to extend all three as well as the baser Servlet and Portlet. But that's not too bad.
And we need to decide if the logger makes sense here, since Portlet defines a logging mechanism itself (but I don't believe Servlet does). So I'm including it, to give developers the option.
Also, I've heard talk about using JNDI to find the service manager, which is a more general solution. But the ServletContext seems so perfect for Servlets and Portlets that I'd like to do this now, and perhaps include a standard (optional) JNDI in the framework as well at a later date.
* * *
Interested? If we get consensus here and work out the details, I'd be happy to put together the code and contribute it to Avalon.
Thanks,
- Glenn
Glenn R. Golden CHEF Architect System Research Programmer III School of Information + Media Union @ University of Michigan [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
