Glenn, in general, the threshold for getting stuff into Framework is fairly high. In this case (inter-container lookup) we have, I think, settled on JNDI as *the* method for publishing services.
Standard policy is to not stand in the way for someone who wants to contribute, though, but I'd be much happier if these extensions took the way over avalon-sandbox before we put them into Framework proper. Further discussion makes more sense on the dev list - mind if we move the thread there? /LS > From: Glenn R. Golden [mailto:[EMAIL PROTECTED] > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
