Hi, 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 ;) Cheers, Pete *-----------------------------------------------------* | "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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
