Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Thu, 14 Aug 2003 12:33:06 -0500
Subject: Re: [General] Container interface and AbstractContainer
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Dain Sundstrom <dain@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F3B38BC.4030709@mortbay.com>
Message-Id: <5D604728-CE7D-11D7-8444-000393DB559A@coredevelopers.net>

I'm going to respond to the original message as I think it got a little 
off track.

On Thursday, August 14, 2003, at 02:22 AM, Jan Bartel wrote:

> 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:

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.

> 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.

> 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.

> 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 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.

> 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.

-dain