My 2 cents: Keep the MBeanProxy, why?? CUZ i'm lazy. Are you going to force
me to do invoke("print", new Object[String.class] {}, new String[] {"hi"});
for a feaking print("hi");!!!! Get out of here.
If I know ahead of time that the object is going to have the method, why
can't I use an MBeanProxy with the interface that I know it must have?
(Reflection performance not being an issue.)
Regards,
Hiram
>From: Jason Dillon <[EMAIL PROTECTED]>
>To: Andreas Schaefer <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: [JBoss-dev] MBeanProxy, Java interfaces & JMX
>Date: Wed, 06 Mar 2002 19:55:12 -0800
>
>>
>>
>>>>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
_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
