I've found a solution to this, finally.
Tomcat depends on Jakarta Commons Modeler for JMX MBeans registration
and operations.
Upon further examination, Jakarta Modeler implementation of ModelMBean
interface (org.apache.commons.modeler.BaseModelMBean) uses
Thread.currentThread().getContextClassLoader() to load
attribute\parameter class rather than the MBean's class loader that the
method is getting invoked to. So I have to make sure to set thread
contextClassLoader to the class loader used for the particular MBean
registration before invoking a method.
This seems like a bug in Modeler though. Shouldn't we able to depend on
MBean's class loader and use MBeanServer.getClassLoaderFor(ObjectName)
to load its attribute classes?
Thanks,
Amy
Amy Roh wrote:
> kedar wrote:
>
>>
>>
>> Amy Roh wrote:
>>
>>> kedar wrote:
>>>
>>>>
>>>>
>>>> Amy Roh wrote:
>>>>
>>>>> kedar wrote:
>>>>>
>>>>>> Using proxy apart, I am not able to assess why this
>>>>>> operation fails. I checked fisheye and the actual
>>>>>> invocation code snippet is not available in WebContainer.java.
>>>>>> Can you send me the exact MBean code and the code that
>>>>>> calls the method?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think the issue might be related to ClassLoader.
>>>>
>>>>
>>>>
>>>> Right. This is important piece of information.
>>>>
>>>>>
>>>>> I've created a separate ClassLoader to load and start Tomcat in a
>>>>> lifecycle listener module. Tomcat related MBeans are created using
>>>>> this
>>>>> ClassLoader.
>>>>
>>>>
>>>>
>>>> And are you using the createMBean method on MBeanServer
>>>> that takes the classloader as an object name?
>>>> You've got to handle this rather carefully.
>>>>
>>>> If the MBean code is known to a special class loader, then
>>>> it will be better to
>>>> 1- either, use the registerMBean method where you create
>>>> your MBean instance and register it.
>>>
>>>
>>>
>>>> 2- or, use the createMBean method, but prior to that, register
>>>> the class loader that knows about MBean as an MBean.
>>>>
>>>> Can you try out 1) and report back?
>>>
>>>
>>>
>>> I already register the class loader as an MBean after creating it.
>>> Is that what you mean?
>>
>>
>> Yes.
>>
>>>
>>> I tried MBeanServer.instantiate(String className, ObjectName
>>> loaderName) to make sure if the Object created is using the same
>>> class loader.
>>
>>
>> Right, this should work.
>> But I would prefer you use the registerMBean method, rather
>> than createMBean method.
>> - create the instance of Catalina Context class (cc)
>> - use an object name (on)
>> - MBeanServer.registerMBean(cc, on);
>
>
> Even when I'm just passing this Context as a parameter?
>
> The scenario is that I'm actually invoking a method on Deployer (which
> MBean is already created and registered) not on Context MBean.
>
> server.invoke(deployer, "manageApp",
> new Object[] {context},
> new String[] {"org.apache.catalina.Context"});
>
> The method I'm invoking on deployer will in fact create and register
> MBean for this Context I'm passing as a parameter.
>
> Thanks,
> Amy
>
>> now invoke the operation on that MBean.
>>
>> I suggest this because I don't know how you are
>> setting up the class loaders.
>>
>> In general, when class loaders are involved, you need to
>> to exercise more care with MBeans.
>>
>> Kedar
>>
>>>
>>> Thanks,
>>> Amy
>>>
>>>>
>>>> Kedar
>>>>
>>>>>
>>>>> However, passing a StandardContext Object loaded from the Tomcat
>>>>> JAR to
>>>>> invoke a method on Tomcat Deployer MBean doesn't seem to work.
>>>>>
>>>>> Class contextClass = catalinaLoader.loadClass(
>>>>> "org.apache.catalina.core.StandardContext");
>>>>> Object context = contextClass.newInstance();
>>>>>
>>>>> MBeanServer.invoke(deployer, "manageApp",
>>>>> new Object[] {context},
>>>>> new String[] {"org.apache.catalina.Context"});
>>>>>
>>>>> Since MBeanServer.invoke uses the same class loader as the one used
>>>>> for
>>>>> loading the MBean on which the operation was invoked, I checked the
>>>>> ClassLoader for deployer MBean and found that it is Tomcat's common
>>>>> class loader rather than catalina class loader.
>>>>>
>>>>> I even tried instantiating context Object using
>>>>> MBeanServer.instantiate
>>>>> to make sure the class is the same one but no luck.
>>>>>
>>>>> Thanks,
>>>>> Amy
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>> 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
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>