avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: JMX Integration
Date Wed, 04 Sep 2002 22:14:42 GMT

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.

Igor Fedorenko
Think smart. Think automated. Think Dynamics.

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message