Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 67266 invoked from network); 2 Jun 2002 14:51:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Jun 2002 14:51:38 -0000 Received: (qmail 23685 invoked by uid 97); 2 Jun 2002 14:51:39 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 23624 invoked by uid 97); 2 Jun 2002 14:51:38 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 23612 invoked by uid 98); 2 Jun 2002 14:51:37 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3CFA3188.3050202@osm.net> Date: Sun, 02 Jun 2002 16:54:00 +0200 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Re: thinking Merlin/Pheoix stuff ... References: <3CE6769A.3030403@osm.net> <200205311134.48785.donaldp@apache.org> <3CF72D70.1020005@osm.net> <200206011704.15446.peter@apache.org> 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 Peter Donald wrote: >On Fri, 31 May 2002 17:59, Stephen McConnell wrote: > >>Looking at a real example - the assembly of an ORB - the information >>supplied to an ORB to assemble itself is specific to an ORB component. >> As shown in the above example, its a bunch of interceptor declarations. >> > >The problem is that there is no way that I can think of of passing in >configuration without restricting yourself to a particular implementation. >For instance most roles/interfaces can have multiple implementations. > >One implementation may require configuration, one may not require >configuration (it may be fixed at compile time), one configuration schema may >be different from another. One implementation may have similar contained >components but represented completely and utterly differently or whatever. ie >Are interceptors specific to OpenORB implementation? or are they generic >across all Corba ORBs? > An interceptor is a standard ORB extension mechanisms. In fact you can look at an ORB as a ServiceManager - interceptors represent service available via the ORB. In the classic ORB specificiation these are accessed via orb.resolve_initial_references( "myService" ). The org.apache.orb.ORB implementation actually implements the ServiceManager interface which simply delegates actions to the standard resolve_initial_references operation. Using the example we discussed before of a component that has a dependecy on an ORB from which it can locate a time service ... if we translate this into Avalon terminaology, it could be described as a component that has a dependecy on a service (which is a ServiceManager) that exposes sub-services. If the dependency declaration were extended to support nested dependencies, we could potentially see something like the following: orb When handling the establishment of the component, a container can spot the nested dependecies and recognize that this menas that the primary dependecy is a service manager that has to be populated relative to the sub-dependencies. This would get out out of the "configuration" issue and focussed on the question of nested dependecy declarations. The actual component could then do something like: public void service( ServiceManager manager ) { m_orb = (ORB) manager.lookup( "orb" ); m_time = (TimeService) manager.lookup( "orb/time" ); } 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: