It all looks good to me. I suggest the specific addInterface and
addPlugin methods, as changing the interceptor stack is a much more
dangerous operation then adding a plugin. Also, they are semantically
just way different things.
-dain
On Thursday, August 14, 2003, at 09:58 PM, Jan Bartel wrote:
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?
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.
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.
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.
So that method would fit nicely into AbstractRPCContainer then? In
fact, many of the method implementations in ContainerImpl would shift
into AbstractRPCContainer I think?
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)
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.
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 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.
So, as Component will have a name, then your concerns re Plugins will
be addressed, no?
Jan
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
