avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject [phoenix] JMX Management - the good, the bad and the ugly
Date Wed, 25 Apr 2001 09:15:55 GMT

I have mostly merged in Leos JMX management stuff to the main trunk except
for a few things (which should be easy enough todo). So we are getting
closer - Yea !!!

There is a few changes that are different from Leos proposal. They
important ones are the following. I hid most of the complexity behind a
facade of 3 methods rather than directly accessing MBeanServer and creating
MBeans directly.

I also moved most of the functionality into the "SystemManager" component
that sits at the same abstraction level as Kernel. This is responsible for
instantiating mBeanServer, exporting it via RMI and binding it in
nameserver. There is also a kernel Facility (ApplicationManager) that
exports the sub-components of Application (ie Blocks). 

Now most of this is going to be really easy to enable (2-3 lines in a few
places and a few marker interfaces). However we have a few things we have
to work out. 

RMI is insecure by default - we can make it more secure over SSL and
requiring certain certificates so I hope we can solve this issue. For this
reason RMIAdaptorImpl now extends RemoteServer rather than
UnicastRemoteServer and we have to manually export the object.

DynamicMbeanFactory will throw exceptions when there is get/is/set methods
that don't conform to JavaBeans standard where I think it should just
ignore them (Leo can you confirm that???). Consequently no objects are
exported because they all have these get/is/set "features".

I also want some way of limiting what attributes/operations/notifications
are exported. The way I think is best is by passing in interfaces to
DynamicMbeanFactory which will introspect on those interfaces rather than
directly on the object itself. Thoughts? This way we could limit ourselves
to set management interfaces. Leo do you want to hack at
DynamicMbeanFactory to add this??? :)

Another thing we have to think about is how we define management
interfaces. One way is tagging them as manageable in .xinfo while another
way is having them extend ManagedService rather than Service directly. I
currently favour the second approach as it feels more heavyweight and I
don't see any need for "configurable" management interfaces. Thoughts?

There is a few other issues to do with thread protection boundaries.
Currently methods etc execute in kernel thread - in the future we will have
to make sure it executes in the appropriate thread (ie application thread
or whatever). I think we will be able to do this when I get around to
revamping the ThreadManager/ThreadPool/ThreadContext classes.

Anyways thats it for now - congrats to Leo on JMX stuff ;)



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

View raw message