Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 37213 invoked from network); 28 Jun 2002 07:00:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 28 Jun 2002 07:00:38 -0000 Received: (qmail 2412 invoked by uid 97); 28 Jun 2002 07:00:55 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 2372 invoked by uid 97); 28 Jun 2002 07:00:53 -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 2351 invoked by uid 98); 28 Jun 2002 07:00:53 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D1C0983.4040403@apache.org> Date: Fri, 28 Jun 2002 09:00:19 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: ComponentInfo can now be loaded from Serialized object References: <5.1.0.14.2.20020628103732.00b4fa50@mail.optushome.com.au> <5.1.0.14.2.20020628111439.01c52848@mail.optushome.com.au> <5.1.0.14.2.20020628120436.00bc6ea0@mail.optushome.com.au> <3D1BCC9C.2020600@osm.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N Stephen McConnell wrote: > > > Peter Donald wrote: > >> At 04:04 AM 6/28/2002 +0200, you wrote: >> >>>>> Keeping in mind that that the compoent in question can provide >>>>> service information based on static declarations in an assembly >>>>> file - I need to figure out how this information can be made >>>>> available to another container without supplying a .xinfo file. >>>> >>>> >>>> I am not sure it is possible unless we start defining Factorys for >>>> Avalon components. For a factory you pass in a implementation key >>>> (usually classname) and aquire an instance of type. The factory >>>> would also expose the MetaInfo associated with type. >>> >>> >>> No - I'm still at meta-land, no component instantiation. >> >> Read above again - no need to instantiate type to instantiate types >> metadata. >> >>> The action of ComponentInfo (dependecies, services, etc.) creation >>> is the point I want to intercept as part of a "standard" containerkit >>> meta loading/validation process. This is needed to be able to plug >>> the component into something like SimpleServiceKernel and everything >>> will just work fine because the .xinfo for my component will declare >>> the ComponentInfo handler - using this information the kernel can >>> delegate the ComponentInfo creation to the handler. The kernel just >>> gets back the ComponentInfo and continues on as normal. >>> >>> E.g. >>> >>> interface InfoProvider >>> { >>> ComponentInfo getComponentInfo( Class class ); >>> } >>> >>> And in the .xinfo: >>> >>> >> >> >> >> What I prposed was more along the lines of >> >> interface ComponentFactory >> { >> Object createComponent(String implKey); >> ComponentInfo createComponentInfo(String implKey); >> } >> >> When "registering" a type into the system you register a coresponding >> factory and all is good. You can do what you want and plenty more. >> > > This would work for me. In commons-sandbox we are starting a commons-patterns package. There will be Factory in it. IMHO we could use that for non-core interface concepts (ie not tied to a container or to a lifecycle). What about (Factory invented) interface ComponentFactory org.apache.commons.patterns.Factory { Object newinstance(String implKey); } interface ComponentInfoFactory extends org.apache.commons.patterns.Factory { Object newinstance(String implKey); } -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: