> > >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. >
The only problem I could see was when a JMX exception was thrown... like for no such method or whatever... which we would just translate into some Error. Or could simply ignore, because Dymanic proxy will throw an error if a undeclared throwable is tossed. It would be better to decode, but not doing so will result in the came behavior. >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. > I would have to check, but I think the MBeanProxy impl in the JBoss/JMX module will propertly treat set/get calls as attributes and not operations. Otherwise you could have MBeanProxy always return an object that has generic set/get methods on it... but that seems like a bad idea, since you will ned to cast to get it and it isn't really that explicit. Better to just translate under the covers. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
