geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [General] Container interface and AbstractContainer
Date Fri, 15 Aug 2003 04:32:36 GMT
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
  *************************/


Mime
View raw message