Integrating platform mbeans into kernel bus?

[starksm64]

One thing I need to do is enable the KernelBusRuntimeComponentDispatcher to be aware of the platform mbeans. I can just code that knowledge directly into the KernelBusRuntimeComponentDispatcher, but is there a better way to bridge better way to do this? By better I mean generally make these mbeans available via the KernelBus.

[alesj]

What are platform mbeans?

[starksm64]

They are the jdk internal mbeans. See:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/package-summary.html

[alesj]

I can think of three ways where you really don't change the KernelBusRuntimeComponentDispatcher, which is completely generic.

(1) extend KernelBusRuntimeComponentDispatcher class with platform awareness
(2) add those mbeans in jmx.xml - via some new service that just adds ServiceControllerContexts to MC for those mbeans
(3) add a service/bean that implements KernelRegistryPlugin and knows how to serve these platform mbeans

(3) is the easiest and nicest imo.

[starksm64]

Its taking a combination of 2+3 as I need to be able to invoke methods on the entry and this requires a InvokeDispatchContext. I'm down to this failure now:

java.lang.reflect.UndeclaredThrowableException
 at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:123)
 at org.jboss.profileservice.management.ManagementViewImpl$ManagedOperationDelegate.invoke(ManagementViewImpl.java:1358)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
 at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
 at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
 at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
Caused by: java.lang.IllegalArgumentException: Cannot execute invoke on non InvokeDispatchContext context: AbstractKernelRegistryEntry@2bc94f{target=ServiceControllerContext@4b934c{name=java.lang:type=Threading target=null state=**ERROR** depends=AbstractDependencyInfo@ada032{idependOn=[]} error=javax.management.InstanceNotFoundException: java.lang:type=Threading is not registered.
 at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
 at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:675)
 at org.jboss.system.microcontainer.ServiceProxy.getServiceProxy(ServiceProxy.java:112)
 at org.jboss.system.microcontainer.ServiceControllerContext.getServiceProxy(ServiceControllerContext.java:255)
 at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:41)
 at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:37)
...

I'm going to allow the MBeanServer to be specified at the ServiceControllerContext level so that it can be different from default MBeanServer used by the JMXKernel.

[alesj]

I'm going to allow the MBeanServer to be specified at the ServiceControllerContext level so that it can be different from default MBeanServer used by the JMXKernel.

I wouldn't change that.
I would just create new JMXInvokeDispatchContext.

Keeping ServiceControllerContext for what it's meant for == real MC component (it goes over proper lifecycle).
Where this new JMXIDC is just a diff way of mapping IDC.

[alesj]

"alesj" wrote:
Where this new JMXIDC is just a diff way of mapping IDC.

Where your (3) impl just returns pre-cached instances of JMXIDC.
e.g. Map<ObjectName, JMXIDC>

[starksm64]

Ok, I have the dispatch working using a subclass of AbstractKernelRegistryEntry that implements InvokeDispatchContext, but there is an issue with the RuntimeComponentDispatcher implementation and spi. The problem with the implementation is that it does not build the correct signature for a method if the method takes a primitive. The signature is java.lang.Long rather than just long.

However, the MetaType spi does not have an isPrimitive notion, so there is not much the default RuntimeComponentDispatcher can do. I can work around this in my InvokeDispatchContext and try to match the invocation against the MBeanOperationInfo metadata.

In general we need a notion of primitives in MetaType, or we need it on the ManagedParameter api.

[starksm64]

Ok, I finally finished this and the signature naturally falls out of the extended SimpleMetaTypes for the primitives, so no changes to the RuntimeComponentDispatcher or implementations are needed. These changes are in the 5_x branch which is now using the 2.1.0.CR2 jboss-managed release.

[alesj]

I see you still have ServiceController in PlatformMBeanKernelRegistryPlugin.

Or, why not injecting MBeanServer,
but instead getting it through ManagementFactory.getPlatformMBeanServer()?

[alesj]

I remember I had issues with attribute name in
ServiceControllerContext, WRT upper case first letter.
See ServiceControllerContext::getAttributeName.

I see you don't impl that in PlatformMBeanIDC.

[starksm64]

ServiceController is not being used, I'll just drop it.

I need to add some tests of setting/getting the platform mbean attributes through the ManagedPropertys to see if there is a case issue.