Return-Path: Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 5198 invoked by uid 500); 11 Feb 2003 16:20:04 -0000 Mailing-List: contact dev-help@avalon.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 dev@avalon.apache.org Received: (qmail 5186 invoked from network); 11 Feb 2003 16:20:03 -0000 Received: from nan-smtp-10.noos.net (HELO smtp.noos.fr) (212.198.2.81) by daedalus.apache.org with SMTP; 11 Feb 2003 16:20:03 -0000 Received: (qmail 4954623 invoked by uid 0); 11 Feb 2003 16:20:03 -0000 Received: from unknown (HELO apache.org) ([212.198.17.4]) (envelope-sender ) by 212.198.2.81 (qmail-ldap-1.03) with SMTP for ; 11 Feb 2003 16:20:03 -0000 Message-ID: <3E4922DF.6090909@apache.org> Date: Tue, 11 Feb 2003 17:20:47 +0100 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: [Proposal] Avalon Framework 4.1.4 RC 3 References: 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 Peter Royal wrote: > On Tuesday, February 11, 2003, at 01:06 AM, Stephen McConnell wrote: > >> Wrapper classes (major) >> ----------------------- >> >> The wrapper classes that that exist in framework are broken. The >> WrapperComponentManager takes a ServiceManager as a constructor argument >> and when lookup invocations are made against the wrapper, the wrapper >> returns Component instance "if and only if the object returned from a >> lookup on the service manager is an instance of Component". The wrapper >> makes no attempt to proxy an Object as a Component. > > > I have no problem with the wrappers the way they are. What you mention > is indeed a limitation, but they have known deterministic behavior. We > can create another project with proxying wrappers as you suggest if > needed. > -pete Pete: Not sure what you use-case is - but my understanding of the purpose of these classes is to aid migration from CM -> SM. This means existing clients that implement Composable would be supplied with a WrapperComponentManager. As different components move from CM to SM, they are going to appear as non-Component components - and with the current implementation - it will fail. I don't think this is a very satisfactory solution because the behavior of the wrapper will be inconsistent with the behavior of a DefaultComponentManager or any other ComponentManager implementation. Do you have a problem with these classes moving out of the framework and into a seperate jar? At least if we do that we can make sure we have a complete migration solution. Cheers, Steve. -- Stephen J. McConnell mailto:mcconnell@apache.org http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org