geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Container interface and AbstractContainer
Date Thu, 14 Aug 2003 07:22:36 GMT
Dain, Jeremy et al,

I am working on the AbstractWebContainer and having difficulty making 
progress given the current form of the 
org.apache.geronimo.common.Container. I'd like to make an 
AbstractContainer class but here are the issues that I face in trying to 
accomplish that:


1. Why does Container already contain deprecated methods?! Can't these 
be removed, they're kinda cluttering up the codebase.

2. Is it really necessary that it has the method invoke(Invocation)? 
Doesn't this pre-suppose that there is some de-typed mode of 
communicating to/between containers like JMX? Couldn't this method be 
moved into another subclass, say something like "InvokableContainer" or 
something?

3. Are the get/addPlugin() methods really necessary to have in the base 
interface type? Again, couldn't these be handled by subclassing from 
AbstractContainer?


I propose that the Container interface looks like:
Container extends Component
    Components[] getComponents()
                 setComponents(Component[])
                 addComponent(Component)
                 removeComponent(Component)

In other words, a standard implementation of the Composite pattern.
Other subclasses can then treat the Components as Plugins, Invokers or 
whatever.

I also propose that the Component interface has one extra method:

     String getObjectName();

which is the identity of the Component, and will help out Containers 
wishing to maintain maps of Components. It will also gel nicely with the
JSR077 requirement to identify ManagedObjects by a name.


Jan




Mime
View raw message