<snip> > * * * > > I believe that using MBeanProxy (perhaps a redesigned version to cache > handlers and correctly get/set attributes) will greatly improve the > maintainability of the system. It does this by adding compile time type > checking and reduces client side casting problems. When used for target > MBeans it will help keep the implementations in sync with the client > code that will be calling it. > > It will greatly simplify 90% of the JMX client code (where simple > server.invoke() is now). JMX access now looks like a regular method > call with no extra client casting and no need to handle that list JMX > exceptions. Leaving it free to solve the problem at hand with out > getting clogged up with JMX specifics. > > It seems quite obvious to me... I wish I could explain it such that > everyone else could understand.
I think I understand the benefits... I'm not convinced yet that there are no problems we haven't seen yet. I'm still thinking. At the moment I'm thinking that this works best for managed operations rather than attributes. I think there may be a reason to keep the setAttributes method on the proxy, it we use it: if setting an attribute results in cycling through service lifecycle methods, we need to set a package of attributes in one cycle. Otherwise the mbean may be restarted in an inconsistent state. Not exactly transaction.... but perhaps useful. It would be pretty easy to write an xdoclet template to generate an interface including just the managed operations. david jencks > > =| > > --jason > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
