On Sat, 29 Sep 2001 00:38, Pratik Patel wrote: > Hello, hiya,
> I have been lurking on the list for a while now and have been following > the conversation about JMX and Avalon. > I've been learning Avalon slowly, and I would like to use Avalon for > what I'm working on, but would like to do some things with JMX; anyhow, > enough about me. welcome! > Here are some thoughts. Please feel free to set the record straight if > something is incorrect and of course all comments, suggestions, flame > welcome. ;) > First, I would like to say that integrating JMX at the "Component" level > into Avalon is the wrong thing to do: > * Avalon is far ahead of managing components in the true sense of the > component compared to JMX for lifecycle management - yep. > * JMX is flat in terms of relationships between MBeans, whereas Avalon > components can be hierarchical yep. > * JMX seems more geared to managing Blocks rather than smaller components Agreed - almost. The one problem being things like logging. In this case it would be useful for JMX to manage logging (so individual LogTargets and categories). > Integrating JMX at the "Block" level is the better thing to do. Yep. I would also like to wrap some kernel components as MBeans ... actually thats what I started doing yesterday ;) However there is one thing to note. At this stage I am a little nervous of integrating JMX tightly into the core of Phoenix due to licensing issues. The RI requires the standard things but it also has an advertising clause. However to advertise that you are JMX enabled requires that you seek for your apps to be verified by Sun ... which costs money ;) There is a clean room implementation (or there was) in enhydra but I was told that because of the licensing of the spec you still required validation from Sun if you use any trademarks (ie say it is JMX enabled) and it may cost you to implement agents. I am not sure on these legal matters so until I look further I guess I would prefer to be paranoid ;) > 1) Extend MBeanServer to use Avalon Phoenix > - config files to initialize, stop, start blocks > - MBeanServer and Phoenix are one-in-the-same > - MBeanServer is the main[] > - Phoenix is started by MBeanServer > - Native Avalon Blocks are loaded via a wrapper MBean that is aware > of all of the control interfaces for Blocks > - Phoenix is 'JMX aware' so it can call the MBeanServer and fire up > MBeans or Blocks (which are wrapped around an MBean) > - The MBeanServer can load MBeans as normal BUT (MBeans) must > implement some of Avalon's interfaces for blocks via a 3rd party > WrapperMBean > - 3rd party MBeans will be wrapped using the > AvalonMBeanWrapper (ex: JettyMBeanWrapper implements AvalonMBeanWrapper) > - This JettyMBeanWrapper will know how to define roles, > dependencies, configuration etc for Jetty in relation to how Jetty fits > into Avalon This is one strategy that it would be interesting to try, however I don't think it is appropriate just yet (and besides it is a lot of work). The main reason I don't like it is that it removes all the advantages of using a kernel. It in effect adds a few layers on with little apreciable advantage and in this case I would prefer to just directly write MBeans rather than Blocks. > 2) Bootstrap Phoenix into an MBean > - MBeanServer and Phoenix are completely independent (almost(?)) > - MBeanServer is the main[] > - entire kernel is only start/stop able from the master MBeanServer > - All Avalon blocks are loaded by Phoenix as normal > - The MBeanServer can load MBeans as normal, with no control by Phoenix I actually did this as an experiment by loading parts of Phoenixs kernel via MLet and it works great. It essentially replaces Phoenixs Embeddor with a JMX Embeddor implementation. This sort of thing has a bit more overhead but it is much more flexible because you could add arbitrary MBeans in (like aggregate JBoss/Jetty and anything else as needed). > 3) MBeanServer is made into a block > - create a new class called AvalonMBeanServerBlock > - This block performs the normal duties of an MBeanServer but it > itself managed by Phoenix > - Configuration of loaded MBeans can be passed down from the normal > Avalon configuration/assembly files > - Example: This block can load Jetty without any additional work > required (using Jetty's MBean interface and native configuration) > - Example: This block can load *and* configure Jetty if Avalon's > configuration of blocks is tranlated into Jetty configuration (XML 2 XML > transformation, or discrete setting of Jetty MBean attributes at > init/runtime) This is the way that I think is best todo. The issue is how do we safely pass the MBeanServer down to the appropriate applications. The few ways I have been thinking about doing it is 1. If we have a Block com.biz.Foo then we search for a com.biz.FooMBean and if present it is expected to be a MBean and to have a constructor that takes one argument (namely Foo). So max 1 MBean per Block. 2. Similar to (1) but it acts at Service level. ie If we have a Block that implements service com.biz.Foo then we search for a com.biz.FooMBean and if present it is expected to be a MBean and to have a constructor that takes one argument (namely Foo). So many MBeans per Block (as many MBeans as Services). 3. Enhance BlockContext to expose MBeanServer and let Blocks have their way with it 4. Enhance BlockContext so that they can register arbitrary interfaces for management 5. Enhance BlockContext so that they can register arbitrary MBeans for management 6. Make kernel automagically detect Manageable interfaces and export them. This detection can be by extending some interface or by specifying Manageable interfaces in BlockInfo. 7. Enhance BlockContext and/or assembly descriptor so that Blocks can be marked as "privlidged" which means they get access to the kernel interfaces ... including MBeanServer 1, 2, 4, 6 and 7 have the advantage that we don't require the presence of JMX but if present it will be used. 7 has the advantage that we can add extra "special" Kernel services if the infrastructure is general enough. Currently I tend to like (1) + (7) or (6) + (7). However I am not really sure at this stage. I don't know enough about it - what do you think? > I have some diagrams but haven't had time to move them from my notebook > to e-copy. > I'd be happy to write some code, as long as some people promise to help ;) kool. I will help but I am a bit of a JMX weenie so I am not sure how much help I will be ;) I actually went and had a look at Jettys JMX stuff and found out they had a class similar to what I have just spent a few hours implementing - dammit ! ;) Though they do have a few interesting ideas that I think I can correct in my implementation ;) -- Cheers, Pete ----------------------------------------------------- First, we shape our tools, thereafter, they shape us. ----------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
