> > >>>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? >> > >StandardMBean requires that. You could (unlikely but possible) run into >a problem when the XXXMBean you need for a StandardMBean want >to apply to a Dynamic MBean because this is forbidden. >
So for StandardMBean you can just use the *MBean interface, and for others use an interface which does not have the *MBean suffix. >>>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. >> > >On a method invocation ? How do you speed reflection up with this ? > The reflection API is only used to construct the method signature... who knows what the proxy instance actually does. What is the reflection performance you are worried about? >>This is not specific to any type of MBean. >> > >You mean with respect to Dynamic MBeans ? Dynamic MBeans invoke() >method gets called and when it makes it own mapping then NO reflection >is necessary. > Sure, a Dyamic MBean can do whatever it wants. I don't see how that matters at all. MBeanProxy is NOT specific to a given MBean type. Why do you think it is? >>>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. >> > >XMBean as example only have a XML deployment descriptor. The JMX >management interface is, by the spec., only fixed when the MBean gets >registered at the MBeanServer. It could adapt to environment etc. But >this shouldn't be the case here. > What is your point? I don't get it. The MBean target interface is now defined by the XML dd... but there is still the client interface. When the XML changes, the client interface and clients that use that MBean will have to change. Keep the XML and client Java interface in sync and you will have a dramatically easier time maintaining the clients which use it. >>>- 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! >> > >Don't you think this is pretty ugly when you use the MBeanProxy and the >default >way to access the MBeanServer as well ? > No... or I would not even both trying to explain it. Use the MBeanServer interface where you need to. Look at the different places where we use it. Count the number of places that do anything other than call an operation or set/get an attribute. Then look to see how "ugly" the code would be if the server.invoke(...) was replaced by a proxy.operation(...). I don't think it is a matter of style in this case. There are concrete benifits. >>>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? >> > >Will create an example and come back to you, soon. > Ok. >>>and then we have two different ways to handle JMX calls. >>> >>Where? MBeanProxy still does a MBeanServer.invoke()... >> > >MBeanProxy.doSomething() vs. MBeanServer.invoke( name, "doSomething", ... ) > doSomething() simply sets up the call to MBeanServer.invoke... what is different there? Nothing... there is just a specialied layer which handles the details of JMX. * * * 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. =| --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
