avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: JMX Integration
Date Mon, 02 Sep 2002 11:03:16 GMT
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 )

The reason is that we have discussed that feature in the past without really 
coming to any conclusion. 

For example, lets consider the things that you may want to do with a 
"ManagementContext". Usually you will want to 

* register/bind object to name
* unregister/unbind object to name
* get a sub context
* get a list of names bound to current context
* get a object bound with a specific name

This is the exact same sort of operations you may want to do if you wanted to 
"remote" an object (via soap, altrmi, rmi, corba, or whatever). It is also 
the same set of operations that you would do if you wanted to expose an 
object in one application to an object in another application.

In effect, the act of registering into a management context is identical to 
registering into any directory service. The manager then either exports all 
services in directory or the directory itself is responsible for exporting 

Anyway the basic interface you end up with is something like

interface Directory
  void register( String name, Object value ); /* possibly also have 
                                                attribute map here */
  void unregister( String name );
  String[] list();
  Object get(String name);
  Directory getSubDirectory(String name);

Anyways. A couple of years ago, me Berin and Stefano went through all the 
different permutations of this (from a one method interface to JNDI with all 
20+ methods + 15 classes). However there is no real way to decide what will 
be sufficient for all purposes. Berin - any thing I left out from way back 

I would prefer we experiment with this and if in a year or so we come up with 
a interface that everyone likes then we can promote that to framework and 
deprecate the appropriate methods in BlockContext. 

Also the architecture of Phoenix is not really friendly to hierarchy of 
multiple layers at this stage so I don't see that as a real hinderance. Maybe 
when we see it in action we can change it but until then I think we go with 
the simple approach.



Peter Donald
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."                   *
*              - John Kenneth Galbraith               *

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