Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 77266 invoked from network); 15 Jun 2002 21:14:49 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Jun 2002 21:14:49 -0000 Received: (qmail 21164 invoked by uid 97); 15 Jun 2002 21:14:55 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 21138 invoked by uid 97); 15 Jun 2002 21:14:55 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 21124 invoked by uid 98); 15 Jun 2002 21:14:54 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D0BAEB9.6070401@osm.net> Date: Sat, 15 Jun 2002 23:16:41 +0200 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [A5] Activity Package References: <000501c21481$187d0b60$ac00a8c0@Gabriel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Berin Loritsch wrote: > This houses the Initializable, Startable, and Resumable interfaces. > > I'm pretty happy with it, but we should consider a couple of points: > > 1) are Initializable and Disposable separate concerns? If so we should > split the interface. If not, then we will leave it alone I don't think there is a justification for change for the pattern from 4.1 (i.e. Initializable and Disposable are seperate interfaces) - i.e. we should return A5 proposal on this point back to A4. > 2) We have determined that start() and stop() apply to the same concern > of an active component. We should explicitly state that the > Startable > interface is designed to let an active component know when they can > start background execution threads and when to stop them safely. > We should also state as a contract that stop()ing a component > MUST NOT FAIL! This preculdes the necessity of an exception at this > point. It also makes it the responsibility of the component to clean > up any expensive resources like threads and sockets successfully. > - The container has no way of nowing what system resources a > component > takes if they are not retrieved from other components. I'm not sure I'm following the MUST NOT FAIL comment. The current 4.1 interface can throw an exception which means that it can fail. I think what your getting at is that an exception is thrown at that point its really a delema for a container - and as such - appropriate wording in the documentation should make is clear to the component developer what the implications of throwing an exception. Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: