avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: JMX Integration
Date Mon, 02 Sep 2002 13:12:42 GMT


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

 >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.

This was discussed in respect to the shutdown request handler - this
requirement is no different.

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:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message