Dain,
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:
AbstractContainer was not designed to be implemented by things like a web server; it was designed to be managed collection of instances and services for those instances. Further the instances can be invoked. It would be more property named RPCContainer. I would see the web server implementing component and maybe some other interfaces.
I think, as I've said in other threads, we need to have some more architectural discussions vis a vis "Service" "Container" and "Component". Here is what I am suggesting, in kinda bastardized notation, can you point out where and how your vision differs?
Component <------------- AbstractComponent |0..n ^ ^ | | | | | ------------------------------------ | | | | | | | AbstractWebApplication Plugin Interceptor | | ^ | has | ^ | | | | | | | | | | | |1 | Container <--- AbstractContainer <--- AbstractRPCContainer |0..n ^ ^ | | | | | | has AbstractWebContainer (ejb)ContainerImpl | | |1 Service
Or is a Service really just a Container?
But if Component now has method getObjectName(), then there is no issue here, right? See code sample and further comments below for more on the Plugin issue.1. Why does Container already contain deprecated methods?! Can't these be removed, they're kinda cluttering up the codebase.
It was designed to be used today, and since the base services were not MBeans, so I could not use ObjectName. The plan is to make everything mbeans and remove the get depreciated methods.
So that method would fit nicely into AbstractRPCContainer then? In fact, many of the method implementations in ContainerImpl would shift into AbstractRPCContainer I think?
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?
Yes, it was designed to be an RPCContainer. We could make a interface that has that.
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?
How would someone add a plugin if we did not have these methods.
Well, I was envisaging:
AbstractRPCContainer:
public void addComponent (Component c)
{
if (c instanceof Plugin)
plugins.put (c.getObjectName(), c); if (c instanceof Interceptor)
interceptors.add (c); super.addComponent(c);
} //or if you really want to make it explicit
public void addPlugin (Plugin p)
{
addComponent(p);
} //and
public void addInterceptor (Interceptor i)
{
addComponent(i);
} //and
public Plugin getPlugin (String name)
{
//either use super class's list
// (Plugin)super.getComponent (name);
// or
(Plugin)plugins.get(name);
}
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 think there's also maybe a case for adding a method: Component getComponent (String name)
It is defensive programming. As we progress, there will no doubt be some need to enumerate all the Components belonging to a Container - eg it will probably help with exposing some of the information needed by JSR77. And yes, it will be an immutable List.
I know the array vs list thing was hotly debated, and my opinion just to throw it out there is to use only collections interfaces like Collection, List, Set, and Map. What I don't see is a need to return all the plugins. Is there an actual use case or is this just for debugging? If it is for just debugging, I suggest we return an immutable copy (snapshot) of our collection to avoid synchronization problems.
So, as Component will have a name, then your concerns re Plugins will be addressed, no?
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.
Agree.
Jan
