> I don't have the parts, but it is easy to write one.
> DynamicMBean basically has
> - get|set Attributes: Java Beans reflection would map to actual service
> - invoke: again reflection to rescue.
> It sould be easy to point to a class or interface and wrap it
> dynamically by
> a DynamicMBean wrapper. This wrapper could be influnced by configuration
> files and driven by JMX agents. This would not do full JMX compliance but
> would get the first stage and then more complex parts of the Spec could be
> tackled.
I get the idea. It was sort of what I was thinking -> another option
instead of DynamicMBeans is the use of Model MBeans, which probably
means some of the reflection work is not neccessary. These are not
implemented by enhydra jmx, though.
> Let me know if you want some help.
Definately!
> I have been thinking of JMX and Avalon.
> Just didn't get the time. Would be happy to help out.
I'm at the moment looking into the available code (downloaded 70megs of
Enhydra Enterprise so far =) and documentation, to familiarise myself
with jmx.
After that, I will evaluate the different options (which jmx agent impl.
to start with, which kernel loading model to adapt (jboss vs enhydra vs
tomcat), and then the best way to wrap the various avalon services in
MBeans.
Once that's up and running, I'll look at writing an adapter / html-based
admin interface like provided by the RI. I might even try learning some
GUI programming to build a graphical tool =)
So, the process to follow as I envision it would be:
1 - get Enhydra running, compare jmx impl to reference impl
2 - if we choose Enhydra, extract jmx code from it
3 - look into license issues (I don't expect difficulties)
4 - redesign kernel to prepare for jmx (especially Main.class, probably)
5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
implement Phoenix's services as MBeans.
6 - write custom adapter (avalon-based using RMI, probably)
7 - write management app to talk to adapter (either java program or
servlet-based)
long-term:
8 - create our own jmx impl
9 - design authentication scheme for allowing access to adapter
I'd like any and all suggestions for #4-7, as well as help actually
implementing all this stuff. Harmeet, I'm guessing you'd be most
productive helping out with the kernel design. So draw up some
schematics, if you want ;-)
Oh, comments on the route to follow welcome as well =)
g'night, all!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
