geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: [General] Container interface and AbstractContainer
Date Fri, 15 Aug 2003 02:58:27 GMT
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


Mime
View raw message