Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 60953 invoked from network); 22 Sep 2002 04:26:45 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Sep 2002 04:26:45 -0000 Received: (qmail 5348 invoked by uid 97); 22 Sep 2002 03:27:23 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 5219 invoked by uid 97); 22 Sep 2002 03:27:22 -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 5078 invoked by uid 98); 22 Sep 2002 03:27:21 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D8D1EE7.3000908@thinkdynamics.com> Date: Sat, 21 Sep 2002 21:37:43 -0400 X-Sybari-Trust: a91d1756 40fe6697 20bd98a3 0000093d From: Igor Fedorenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Re: JMX Integration References: <004901c25067$e5c51ff0$ac00a8c0@Gabriel> <3D7194DA.4000104@thinkdynamics.com> <3D724447.6090605@apache.org> <200209022103.16682.peter@apache.org> <3D7363CA.3040408@apache.org> <3D736AA6.9050201@apache.org> <3D7685D2.5060201@thinkdynamics.com> <3D769009.2040106@apache.org> <3D8BE3FF.2000306@thinkdynamics.com> <3D8C6111.3060207@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2002 01:37:48.0666 (UTC) FILETIME=[A871DDA0:01C261D8] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hmm, I think I am starting to understand what I wanted to ask. ;-) I already have block factories which could be used as a generic way to use external services in phoenix application. My question -- do we need another solution which is optimized/simplified for a case when both phoenix application and "external" service live inside same java VM? Stephen McConnell wrote: > > Igor: > > I think you definately on the right track here. I have been thinkinng > about something similar in the work I've been doing in Merlin. If I > understand correctly, what your describing is the ability for an > application to be able to declare dependecies and export services. I'm > thinking/experimenting and working on the same thing in terms of Merlin > Containers. In both cases - (Phoenix and Merlin) the desired result is > that the result of application/container deployment is the establishment > of a new set of services. These services can then be picked up and used > by other services (indepedently of the deployment infrastructure). > > Igor Fedorenko wrote: > >> I am thinking about implementing this in a generic way, so >> (theoretically) block can access components deployed into Embeddor and >> (later) into any application deployed into phoenix. I think we already >> agreed that block developer will declare these external dependencies >> as any other dependency, however we did not talk about assebly.xml >> syntax that would support this. I see two slightly different solutions >> and need your help to choose one of them. >> >> One option is to use block factory to define foreign blocks in >> assembly.xml and use these blocks as any other block. Emberddor would >> extend BlockFactory interface and phoenix would provide it as implicit >> "system-manager" factory (i.e. it does not need to be configured). For >> example, >> >> >> > implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/> >> >> > role="org.apache.avalon.phoenix.interfaces.SystemManage"/> >> >> >> >> >> Another option is to define new tag "foreign", "external" or something >> like that that could be used in place of "provide" tag. For example >> >> >> >> > role="org.apache.avalon.phoenix.interfaces.SystemManage"/> >> >> >> >> In this case we will need to define new interface that will be >> implemented by all block containers and will provide access to blocks >> deployed into the containers. >> >> So, what do you think? > > > > I think that we need to keep the concepts of importing and exporting > services as parrallel (equivalent?) to the component model. In the case > of a Phoneix assembly defintion this would suggests that the assembly is > defining a set of exported services. In the case of Merlin this would > suggst that a container is defining/exporting the same thing. In both > cases there is the problem of scalability - a block providing a > management service runing under machine A should be assignable as a > service provider to a component running under machine B without concern > for the infrastructure support the component deployment - i.e.a Merlin > hosted business component dependent on a Phoneix hosted management > service or whatever. > This ends up raising the requirement for a portable service defintion > and protocol. > Cheers, Steve. > > >> >> >> >> Stephen McConnell wrote: >> >>> >>> >>> Igor Fedorenko wrote: >>> >>>> >>>> >>>> Nicola Ken Barozzi wrote: >>>> >>>>> >>>>> Stephen McConnell wrote: >>>>> >>>>>> >>>>>> >>>>>> Peter Donald wrote: >>>>>> >>>>>> >On Mon, 2 Sep 2002 02:45, Huw Roberts wrote: >>>>>> > >>>>>> > >>>>>> >>>>Rather than this I think I may prefer something simpler - at >>>>>> least >>>>>> >>>>initially. Something like >>>>>> >>>> >>>>>> >>>>BlockContext.register( String topic, String name, Object >>>>>> object ) >>>>>> >>>>BlockContext.unregister( String topic, String name ) >>>>>> >>>> >>>>>> >>>>Job jobOne = ... get the job somehow >>>>>> >>>>ctx.register( "jobs", jobOne.getName(), jobOne ); >>>>>> >>>>... >>>>>> >>>>ctx.unregister( "jobs", jobOne.getName() ); >>>>>> >>>> >>>>>> >>>>The reason for this is that then we don't have to expose >>>>>> SystemManager >>>>>> >>>>to clients and thus we are free to evolve it as we see fit. >>>>>> However it >>>>>> >>>>exposes all the information needed to manage object. >>>>>> >>>>Like? >>>>>> >>>> >>>>>> >>>> >>>>>> >>I have 3 issues: >>>>>> >>1) The ability to add more than one level of hierarchy beneath >>>>>> the blocks. >>>>>> >>2) Using an interface will make the client code cleaner and >>>>>> more portable. >>>>>> >>3) Client code will be hooking into this, meaning we are >>>>>> committed to >>>>>> >>supporting it going forward. >>>>>> >> >>>>>> >>I can live with this for now, but i want to consider how it >>>>>> fits into >>>>>> >>the longer term direction. What I'd like to do, is add a >>>>>> >>ManagementContext interface to Framework, and then have >>>>>> SystemManager >>>>>> >>extend this. That would be the first step towards making the >>>>>> >>functionality available in other containers. Does that sound >>>>>> ok? If >>>>>> >>so, how do we proceed in that direction? If its not too big a >>>>>> deal >>>>>> >>maybe we could skip this intermediate step? >>>>>> >> >>>>>> >> >>>>>> > >>>>>> >I would still prefer to go with the >>>>>> > >>>>>> >BlockContext.register( String topic, String name, Object object ) >>>>>> >BlockContext.unregister( String topic, String name ) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -1 a Context should never be used by a Container for its services. >>>>> If it is used, it's basically giving a service to everyone without >>>>> IoC. >>>>> >>>>>> >The reason is that we have discussed that feature in the past >>>>>> without > really coming to any conclusion. >>>>>> >>>>>> Adding behaviour to an context implementation over and above the >>>>>> framework defintion of context means that you are defining a >>>>>> specilization of the Avalon Component Model for Phoenix. Components >>>>>> that include a dependency on that model are no longer portable. >>>>>> Alternative solutions to introducing the functionality you are >>>>>> describing is totally possible without introducing the complication >>>>>> associated with BlockContext - i..e. use the context object to >>>>>> aquire an >>>>>> abject implementing the interface the component needs, then apply >>>>>> register/unregister against that interface, or, havbe the copmponent >>>>>> declare a depedency on a registery service of some kind. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I resist also this, since we are using services in a context, >>>>> rather than be given them by the Container. >>>>> >>>>> I have looked in the archives and seen that once upon a time, >>>>> Context was indeed used as a common service, and a common place to >>>>> put services. >>>>> >>>>> I think that Context should never keep services where possible. >>>>> >>>>> For example, ServletContext is about instance data, not services. >>>>> >>>>>> This was discussed in respect to the shutdown request handler - this >>>>>> requirement is no different. >>>>> >>>>> >>>>> >>>>> >>>> >>>> What if we provide instance of SystemManager via >>>> ServiceManager.lookup()? I would not bother getting block's >>>> management subcontext -- it does not map into anything in JMX >>>> anyways -- just put root system manager into appropriate >>>> ServiceManager instance. >>>> >>> >>> Sounds perfect - assuming that the component aquiring the >>> SystemManager declares this as a dependency. >>> >>> Cheers, Steve. >>> >> > -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: For additional commands, e-mail: