Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F44555E.1020100@mortbay.com>
Date: Thu, 21 Aug 2003 15:15:10 +1000
From: Greg Wilkins <gregw@mortbay.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.4) Gecko/20030704 Debian/1.4-1
MIME-Version: 1.0
To: public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@ciao.gmane.org
Subject: Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
References: <3F4404CB.3050401@coredevelopers.net>
 <0BD4790E-D381-11D7-8482-000393DB559A@coredevelopers.net>
In-Reply-To: <0BD4790E-D381-11D7-8482-000393DB559A@coredevelopers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gmane Remailer <public@main.gmane.org>


Dain Sundstrom wrote:
 > [ lots of stuff ]

I still don't agree with lots of what you said - but your concrete
proposals below I can mostly agree with - and we can debate the
details later.

> Here is what I plan on doing:
> 
> Add a ManagedObject interface

+1

> Create an AbstractManagedObject which implements ManagedObject and 
> StateManageable.  
+1

> This class will contain a copy of the 
> AbstractStateManageable code.

-1+1  Can you leave the code dealing with the state machine in
AbstractStateManageable.  ie the setStateInstance check of the
lifecycle and the doStart and doStop abstraction to separate tasks
for this object from any coordinated start processing.

> Change existing code of mine that uses AbstractStateManageable to use 
> AbstractManagedObject instead.

+1

> I propose that we do the following:
> 
> Remove AbstractStateManageable, as I see no real users for it, but maybe 
> you have a use.

-1 as above.  AbstractStateManageable should exist and just have the
code to implement and enforce the StateManageable lifecycle.

> Drink a half dozen pints.

+1 (so long as it is in the order above).

I also think you should make an ManagedContainer interface and
an AbstractManagedContainer class that would have all the
dependency service code in it.  ie it would extend addComponent so
that a dependency is added to the dependency service when it is called.

Actually... with that, I'd probably shut up on this issue as the
dependency mechanism integration into Component and Container would be
a lot more obvious - namely that the AbstractManagedContainer is really
just a conveniance class for configuring the dependency service.

cheers