Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 16197 invoked from network); 3 Jan 2004 05:36:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 3 Jan 2004 05:36:58 -0000 Received: (qmail 3309 invoked by uid 500); 3 Jan 2004 05:36:30 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 3257 invoked by uid 500); 3 Jan 2004 05:36:30 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 3229 invoked from network); 3 Jan 2004 05:36:29 -0000 Received: from unknown (HELO public.coredevelopers.net) (209.233.18.245) by daedalus.apache.org with SMTP; 3 Jan 2004 05:36:29 -0000 Received: from [10.101.105.100] (dain [208.42.65.236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by public.coredevelopers.net (Postfix on SuSE Linux 8.0 (i386)) with ESMTP id 22AA3281E7 for ; Fri, 2 Jan 2004 21:31:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dain Sundstrom Subject: Re: GeronimoMBeanTarget.doStart() - failure mode ? Date: Fri, 2 Jan 2004 23:36:34 -0600 To: geronimo-dev@incubator.apache.org X-Mailer: Apple Mail (2.609) 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 So I have been thinking about this for a while now... The big problem is the support for multiple targets under a single GeronimoMBean. If we didn't have multiple targets we could easily move from starting to running by calling the doStart method. If that method threw a WaitingException (or whatever we call it), we would leave it in the starting state, and if it threw anything else we would fail the component. This would also make implementing this code much easier. The biggest and only user I know of for multiple targets is JCA. JCA uses this to expose the properties of a connection, which are not known ahead of time. I propose we ditch multiple targets for a DynamicGBean interface. If a GBean wants to define the interface at runtime, it simply implements this interface just like a DynamicMBean. I like the idea of a DynamicGBean being able to use the normal attribute and operation mapping for most methods and the dynamic interface for only the stuff. Comments? -dain