Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
To: geronimo-dev@incubator.apache.org
From: Greg Wilkins <gregw@mortbay.com>
Subject: Re: [General] Container interface and AbstractContainer
Date: Thu, 14 Aug 2003 19:10:17 +1000
Lines: 75
Message-ID: <3F3B51F9.4020906@mortbay.com>
References: <3F3B38BC.4030709@mortbay.com>
 <E8B9F9E3-CE31-11D7-A6C3-0003934D3EA4@ioshq.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.4) Gecko/20030704 Debian/1.4-1
In-Reply-To: <E8B9F9E3-CE31-11D7-A6C3-0003934D3EA4@ioshq.com>
Sender: news <news@sea.gmane.org>


Alex Blewitt wrote:
 >> I propose that the Container interface looks like:
 >> Container extends Component
 >>    Components[] getComponents()
 >>                 setComponents(Component[])
 >>                 addComponent(Component)
 >>                 removeComponent(Component)
 >
 >
 > Reviewing the code, I can't see why (a) you'd have a setComponents
 > method (given that you've already got an add/remove) and the
 > getComponent unecesarily returns an array. If you're using a collection,
 > then you can simply return a reference to the embedded data structure
 > which can then be anything depending on how you want to implement it.
 >
 > Arrays have given me way more headaches in implementation than they need
 > to, whereas the only downside of using a Container is that you need to
 > throw in a few casts. Given that a number of IDEs will do this
 > automatically for you when required, I'd vote for moving over to a
 > Collections-based structure instead.


I think Jan added the array methods at my prompting.

The reason I like them is that add/remove are good for
scripting & programming, but are not very good for configuration.

I've been using a system that uses MBean for persistent configuration,
so it is important that everything can be set and got via getters
and setters.

I'm not sure how applicable that is in this situation, as I don't
know what we are doing about configuration - and an array of all
components may not be the best way to do that no matter...

So how about the following

      void addComponent(Component)
      void removeComponent(Component)
      ObjectName[] getComponents()

The getComponents returns an array of JMX object names, which
most JMX agents render nicely for browsing.

But we still don't have a method to iterate over all the
Components, or get them all.  So either we need something like

     ListIterator getComponentIterator()

which gives you the components in the add order.
OR we just give up on typing and do:

    interface Container extends Component, Collection
    {
      ObjectName[] getComponents()
    }

and then throw IllegalArgumentException if anybody adds
a non-Component object to the collection.


>> I also propose that the Component interface has one extra method:
>>
>>     String getObjectName();
> 
> 
> Why not just getName(), by the way?

Because it is a JMX ObjectName


cheers