Return-Path: 
 <geronimo-dev-return-3658-apmail-incubator-geronimo-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org
Received: (qmail 54320 invoked from network); 15 Sep 2003 18:19:34 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 15 Sep 2003 18:19:34 -0000
Received: (qmail 6224 invoked by uid 500); 15 Sep 2003 18:19:00 -0000
Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org
Received: (qmail 6168 invoked by uid 500); 15 Sep 2003 18:19:00 -0000
Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:geronimo-dev-help@incubator.apache.org>
list-unsubscribe: <mailto:geronimo-dev-unsubscribe@incubator.apache.org>
list-post: <mailto:geronimo-dev@incubator.apache.org>
Reply-To: geronimo-dev@incubator.apache.org
Delivered-To: mailing list geronimo-dev@incubator.apache.org
Received: (qmail 6079 invoked from network); 15 Sep 2003 18:18:59 -0000
Received: from unknown (HELO public.coredevelopers.net) (209.233.18.245)
  by daedalus.apache.org with SMTP; 15 Sep 2003 18:18:59 -0000
Received: from coredevelopers.net (dsundstrom-host236.dsl.visi.com
 [208.42.65.236])
	(using TLSv1 with cipher DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by public.coredevelopers.net (Postfix on SuSE Linux 8.0 (i386)) with ESMTP id
 434231DC51
	for <geronimo-dev@incubator.apache.org>;
 Mon, 15 Sep 2003 11:11:35 -0700 (PDT)
Date: Mon, 15 Sep 2003 13:18:59 -0500
Subject: Re: [jsr77][core] Components & Containers.
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: <3F653F2C.3030206@mortbay.com>
Message-Id: <13A56DAC-E7A9-11D7-8FB2-000393DB559A@coredevelopers.net>
X-Mailer: Apple Mail (2.552)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

On Sunday, September 14, 2003, at 11:25 PM, Greg Wilkins wrote:

> It does appear that our current AbstractComponent and AbstractContainer
> really should be ManagedObjects and it is simple to make them 
> implement the
> ManagedObject interface.

+1  The StateManageable thing was just a mistake.

> Also instead of renaming them to StateManageableComponent & 
> StateManageableContainer
> (as per my previous email) I think it makes more sense to rename them 
> to
> ManagedComponent and ManagedContainer

+1  because they are more then StateManageable; they are EventProviders 
and StatisticsProviders.

> However, they should probably extend AbstractManagedObject - which 
> currently
> duplicates much of the content of AbstractStateManageable.  Thus I 
> think
> AbstractStateManageable should be moved to kernel and used as the base 
> for
> AbstracteManagedObject.

This is where I disagree.  I don't think we should have 
AbstractStateManageable at all.  Will we ever have something that is 
StateManageable and not a ManagedObject? No JSR 77 management system 
will recognize it because it will not have the isStateManageable method 
from the ManagedObject interface.

> Thus we would end up with the following hierarchy:
>
> kernel:
>                                                       
> <<StateManageable>>
>                                                           ^
>                                                           |
>                                                       
> AbstractStateManageable
>                                                           ^
>                                                           |
>                                                       
> AbstractManagedObject
>                                                           ^
> core:                                                     |
>          <<Component>>  <--- AbstractComponent  <---  ManagedComponent
>              ^                 ^                          ^
>              |                 |                          |
>          <<Container>>  <--- AbstractContainer -----o ManagedContainer
>                  ^                                    /
>                   \                                  /
>                    ----------------------------------

Damn you are getting good at ASCI art :)


kernel:

<<ManagedObject>> <----------------+
<<StateManageable>> <--------------+
<<EventProvider>> <----------------+
<<StatisticsProvider [1]>> <-------+
                                    |
                           AbstractManagedObject
                                    ^
core:                              |
          <<Component>> <--- ManagedComponent
              ^                     ^
              |                     |
          <<Container>> <--- ManagedContainer


For ManagedObjects all of the interfaces except ManagedObject are 
optional.  I just don't see anyone ever using an implementation of 
StateManageable without doing the a full managed object.  I feel the 
same way about EventProvider and StatisticsProvider.

I also don't see why we need AbstractComponent and AbstractContainer.  
If we find a need later, we can extract the abstract implementations 
(just a few clicks in Eclipse and IntelliJ).

I think this model is much simpler hierarchy, will be quite easy to 
understand, and most importantly it is what we need today.



On an related issue.... I also need to fill you in on the 
GeronimoMBean, as we either must use the GeronimoMBean for all of our 
ManagedObject implementations or we must change the 77 interfaces.  The 
problem is 77 call for attribute names like "startTime" where the first 
character is lowercase.  If we are using StandardMBeans then the getter 
and setter must be getstartTime and setstartTime (it is an mbean spec 
thing that we can't fix).  Since the GeronimoMBean is a dynamic MBean, 
we can fix the capitalization issues, and that is what I did.

I'll try to pull together some docs on it this week.

-dain

[1] The AbstractManagedObject does not currently support 
StatisticsProvider, but I'm sure it eventually will.