Lloyd L Chambers wrote:
> Amy,
>
> Well, I'll speak for myself. I would prefer to write and compile:
>
> final Deployer d = MBeanServerInvocationHandler.newProxyInstance( ... );
>
> d.manageApp( context, "org.apache.catalina.Context" );
>
> than:
>
> MBeanServer.invoke(deployer, "manageApp",
> new Object[] {context},
> new String[] {"org.apache.catalina.Context"});
>
>
> Of course, if it's a one-time use, then the overhead might not be worth
> it, *except* that doing so enforces compile-time type checking, a
I'm a fan of compile-time type checking so it'll def be worthy enough
for me.
Thanks!
Amy
> worthy goal.
>
> Lloyd
>
> On Jan 19, 2007, at 2:27 PM, Amy Roh wrote:
>
>> Lloyd,
>>
>> Lloyd L Chambers wrote:
>>
>>> Amy,
>>> You'll be happier using
>>> MBeanServerInvocationHandler.newProxyInstance () to get type-safe,
>>> compile-time invocation. That might not solve your issue, but it's
>>> safer, since type errors are detected at compile time.
>>> You can write your own java interface for newProxyInstance () if
>>> one is not available, including only the methods relevant to you.
>>
>>
>> Good to know. Hope it dose make me happier. :-)
>>
>> Thanks,
>> Amy
>>
>>> Lloyd
>>> On Jan 19, 2007, at 1:57 PM, Amy Roh wrote:
>>>
>>>> kedar wrote:
>>>>
>>>>> Amy Roh wrote:
>>>>>
>>>>>> kedar wrote:
>>>>>>
>>>>>>> Oh that message is simply a classic
>>>>>>> problem of not being able to provide
>>>>>>> a "rich" java object like "Context" to
>>>>>>> this method on HTML page, that's all.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Oh I Wish that was just the case. However, method invoke fails
>>>>>> with ReflectionException although I can see the method and
>>>>>> signature/param is correct. Perhaps it's related to passing a
>>>>>> "rich" java object since methods that take String get invoked fine.
>>>>>
>>>>>
>>>>> I think I am not explaining it right.
>>>>> On HTML adaptor, primitive Java Objects can easily be sent as
>>>>> params, by
>>>>> entering their value in the text field. That's not true for the
>>>>> non-primitive Java Objects and Arrays. So, if your method accepts
>>>>> such an object, it is simply not "invokable" from HTML adaptor.
>>>>> So, I guess I don't understand what you mean when you say,
>>>>> "method invoke
>>>>> fails ..". How do you invoke it? There is no "button" do so.
>>>>
>>>>
>>>>
>>>> Sorry for not being clear. No, I don't invoke it from HTML
>>>> adaptor. The adaptor was just for me to view MBean information to
>>>> check its availability.
>>>>
>>>> I invoke it in my code (added code is in com/sun/enterprise/web/
>>>> WebContainer.java) like this -
>>>>
>>>> MBeanServer.invoke(deployer, "manageApp",
>>>> new Object[] {context},
>>>> new String[] {"org.apache.catalina.Context"});
>>>>
>>>> which fails with the exception although the method is available
>>>> with right signature.
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>>> Kedar
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Amy
>>>>>>
>>>>>>>
>>>>>>> This unsupported method is basically
>>>>>>> accepting Context object and simply
>>>>>>> speaking there is no way to provide
>>>>>>> that on the page!
>>>>>>>
>>>>>>> Actually, this brings up a good point and
>>>>>>> I am copying Eamonn, the JMX spec lead about
>>>>>>> MBean best practices. This MBean method is
>>>>>>> not a good one because
>>>>>>> 1- it does not use the Open types.
>>>>>>> 2- it is not possible to invoke it from a
>>>>>>> pure JMX client like JConsole.
>>>>>>>
>>>>>>> Note that MBeans are a little different beasts
>>>>>>> from the Java objects :) No need to worry, just
>>>>>>> a question of following best practices.
>>>>>>>
>>>>>>> If you use JConsole, see the MemoryMXBean and you'll
>>>>>>> appreciate what open types are.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Kedar
>>>>>>>
>>>>>>>
>>>>>>> Amy Roh wrote:
>>>>>>>
>>>>>>>> kedar wrote:
>>>>>>>>
>>>>>>>>> I agree with Lloyd, when it comes to the GlassFish
>>>>>>>>> Platform MBeans. To be precise, the "amx:" MBeans
>>>>>>>>> are the ones that the clients can "depend on" to
>>>>>>>>> manage GlassFish. The "com.sun.appserv:" MBeans are
>>>>>>>>> not supported. You are on your own, when you call
>>>>>>>>> these MBeans. In that sense, this is a reserved MBean
>>>>>>>>> domain that you should leave alone. In future, we will
>>>>>>>>> try to hide those MBeans from our clients.
>>>>>>>>>
>>>>>>>>> This however, does not mean that you can't have your
>>>>>>>>> own MBeans. Actually, your application code or explicit
>>>>>>>>> admin operation does allow to deploy your own MBeans and
>>>>>>>>> they will be in a domain called "user:". This relates
>>>>>>>>> to our feature of "custom MBeans" and several folks have
>>>>>>>>> used that feature. Look at Admin console or asadmin
>>>>>>>>> commands like "create-mbean".
>>>>>>>>>
>>>>>>>>> Amy: What MBeans (object names) do you refer to, and why
>>>>>>>>> do you want to invoke those MBean operations?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm trying to invoke Catalina Deployer MBean method. The
>>>>>>>> MBean is created after I embed Tomcat so you can think of it
>>>>>>>> as my own MBean.
>>>>>>>>
>>>>>>>> Again, although the method is visible but "not operational".
>>>>>>>> Trying to figure out why and where the MBeanServer is making
>>>>>>>> the method "not operational".
>>>>>>>>
>>>>>>>> If you're on swan, you can access my mbean -
>>>>>>>>
>>>>>>>> http://asengsol1.sfbay.sun.com:8082/ViewObjectRes//Catalina%
>>>>>>>> 3Atype%3DDeployer%2Chost%3Dlocalhost
>>>>>>>>
>>>>>>>> Description of manageApp (Operation Not Supported)
>>>>>>>> void manageApp (org.apache.catalina.Context)context
>>>>>>>>
>>>>>>>> manageApp operation is listed but says "Operation Not Supported".
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amy
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Kedar
>>>>>>>>>
>>>>>>>>> Lloyd L Chambers wrote:
>>>>>>>>>
>>>>>>>>>> Amy,
>>>>>>>>>>
>>>>>>>>>> Most all MBeans that have a JMX domain other than "amx" are
>>>>>>>>>> private and should not be used. AMX are the public ones,
>>>>>>>>>> and there are no unsupported methods.
>>>>>>>>>>
>>>>>>>>>> The com.sun.appserv MBeans have a fair number of unsupported
>>>>>>>>>> methods; the generic code makes no attempt to remove
>>>>>>>>>> inappropriate methods from the MBeanInfo of subclasses.
>>>>>>>>>>
>>>>>>>>>> Lloyd Chambers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jan 19, 2007, at 10:50 AM, Amy Roh wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> Do you know why some MBeans operations are "not supported"?
>>>>>>>>>>>
>>>>>>>>>>> I do see the method available in MBeanInfo and
>>>>>>>>>>> MBeanOperationInfo and the method is public and available
>>>>>>>>>>> through mbean descriptor.
>>>>>>>>>>>
>>>>>>>>>>> However, when I view the MBean through HTML Adaptor I do
>>>>>>>>>>> see the method listed but it also says "(Operation Not
>>>>>>>>>>> Supported)"
>>>>>>>>>>>
>>>>>>>>>>> After looking at various MBeans, it seems that methods that
>>>>>>>>>>> take any parameters other than Object or String says
>>>>>>>>>>> "Operation Not Supported", perhaps serialization issue(?).
>>>>>>>>>>>
>>>>>>>>>>> Is there a way to use these "available" methods without
>>>>>>>>>>> getting "ReflectionException" when invoked?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amy
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>> -- ------
>>>>>>>>>>> To unsubscribe, e-mail: dev- unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>> -- -----
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>> For additional commands, e-mail: dev- help_at_glassfish.dev.java.net
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -- ----
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev- help_at_glassfish.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -- ---
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> -- --
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -- -
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>> ------------------------------------------------------------------- --
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------- -
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>