> > >>There is absolutly NO coupling when using a Java interface and >>MBeanProxy to invoke operations on a target MBean, as there is no >>requirement that the target MBean implement that interface. At runtime >>the interface only plays a role on the client side. BUT durring compile >>time, it plays a role on both, assuming that the target implements the >>Java interface. >> > >But the MBean doesn't have too and for DynamicMBean you have >to rename them different as "XXXMBean" !! >
Who said anything about using a MBean suffix? >>In a closed system it seems like a logical choice to make use of a Java >>interface on the client and target MBean sides of JMX, as it will allow >>for more error detection durring compile time. This DOES NOT mean that >>external/thirdparty components will not work because they do not >>implement the Java interface, becase that is just not true. Any object >>which provides the appropriate methods will function, regaurdless of the >>Java classes it extends or interfaces it implements. >> > >But now you have to use reflection one time more than necessary. One time >in the MBeanProxy and them maybe in the MBeanServer (exception for >Dynamic MBeans handling the mapping on their own). > So cache the values, or cache the handler. This is not specific to any type of MBean. >>By making use of Java interfaces with JMX it allows us: >> >> o to simplify client code, as it no longer has to deal with the details >>of the MBeanServer. >> o to catch JMX interfacing / typeing errors introduces when the system >>changes at COMPILE TIME. >> o a mechansim for documenting the methods required for a target MBean >>to function correctly. >> > >But you loose: >- you have to manage an additional Interface not always necessay >(DynamicMBeans) > The interface is always there... if it is a Java interface or not. Using a Java interface only makes it easier to catch problems. >- you loose the ability to investiage the object at runtime (is a method, >attribute available > or not etc.) > How so? You DO NOT loose anything! What is stopping you from using the MBeanServer directory when you need to? Ummm... nothing! >- the interface can contain more method than effectively used. Now you have >to > look for the "invoke" method and for MBeanProxies as well. > If there are more methods in a Java interface than are used... then get rid of them from the interface. If they are never called, why have them? Just because the client proxy interface has a method does not mean that the target MBean has to have the corresponding method... unless you want to call it, then it does if you expect it to work. >- getting / setting a list of attributes on one call > Again, if you need to use the raw facilities of the MBeanServer, then use the MBeanSerever. In most cases client code does not need this... it just complicates. >>JMX allows greater flexibilty with respect to external/thirdparty >>component vendors and compatiblity with JBoss at the cost of detyping >>method calls. MBeanProxy resolves the type issue and client side >>simplification and ease of use. It does NOT introduce any additional >>coupling. >> > >Because in our project performance is pretty important I think MBeanProxy >should be used rarley > Do you have any real numbers to show that the use of a proxy is slowing down the system? >and then we have two different ways to handle JMX calls. > Where? MBeanProxy still does a MBeanServer.invoke()... --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
