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
