ManagedObjects for MBeans

[ips]

I noticed that the various types of jboss.web MBeans are all exposed as ManagedComponents with type ComponentType{type=MBean, subtype=Web}. For example, my AS5 instance has the following ManagedComponents:

org.jboss.managed.plugins.ManagedComponentImpl@17498cb{name=jboss.web:host=127.0.0.1,type=Host, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564}

org.jboss.managed.plugins.ManagedComponentImpl@ca251{name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564}

org.jboss.managed.plugins.ManagedComponentImpl@1babf49{name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564}

It would be more intuitive if each of the different types of jboss.web MBeans were exposed as a different type of ManagedComponent, e.g.:

ComponentType{type=MBean, subtype=Web:Host}
ComponentType{type=MBean, subtype=Web:GlobalRequestProcessor}
ComponentType{type=MBean, subtype=Web:ThreadPool}

That way, in the Jopr jboss-as-5 plugin, each component type can be mapped one-to-one to an RHQ ResourceType. Otherwise, we would have to parse the component names to figure out which type of jboss.web MBean we are dealing with.

[alesj]

"ips" wrote:
Otherwise, we would have to parse the component names to figure out which type of jboss.web MBean we are dealing with.

This is definitely how it should _not_ be done. ;-)

Depending on the name is just bad contract.
e.g. we might drop the names in MC, just have aliases for some beans

[ips]

I'm glad you agree :)

The jboss.web ManagedComponents are not the only place such lumping together is done. For example, the ComponentType{type=MCBean, subtype=*} component type is used as the type for a bunch of different types of underlying MBeans.

[starksm64]

The generic mbean to ManagedComponent feature I'm working on will allow the ComponentType to be specified, so it can be unique to the ManagedComponent.

[starksm64]

We can have whatever ComponentType we want on a ManagedObject as these are being set explicitly for the current set of MangedObjects. We should setup a Wiki page that lists the standard ManangedComponent names and their ComponentTypes, and we can start updating the ComponentType based on that.

[starksm64]

For the GA I have taken a new turn that adds a ManagedMBeanDeploymentFactory notion along with injection into the ManagementView bean to allow one to setup the mapping between mbeans and ManagedDeployment/ManagedComponents. Its not completely finished or tested, but an example of getting some of the web app/servlet components are:

 <bean name="WarManagerManagedDeploymentFactory"
 class="org.jboss.profileservice.management.ProxyManagedDeploymentFactory">
 <property name="factoryName">WarManager</property>
 <property name="compType">MBean</property>
 <property name="compSubtype">WebApplicationManager</property>
 <property name="pattern">jboss.web:host=localhost,type=Manager,*</property>
 <property name="patternKey">path</property>
 </bean>

 <bean name="WebModuleManagedDeploymentFactory"
 class="org.jboss.profileservice.management.ProxyManagedDeploymentFactory">
 <property name="factoryName">WebModule</property>
 <property name="compType">MBean</property>
 <property name="compSubtype">WebApplication</property>
 <property name="pattern">jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,*</property>
 <property name="patternKey">name</property>
 <property name="componetInfo">
 <map keyClass="java.lang.String" valueClass="java.lang.String">
 <!-- Process the servlets components -->
 <entry>
 <key>servlets</key>
 <value>MBean:Servlet</value>
 </entry>
 </map>
 </property>
 </bean>

The WarManagerManagedDeploymentFactory simply maps the mbeans matching pattern "jboss.web:host=localhost,type=Manager,*" name. This would match names like:

jboss.web:host=localhost,path=/admin-console,type=Manager
jboss.web:host=localhost,path=/jbossws,type=Manager
...

The patternKey property indicates which key in the matching object names provides the unique name of the deployment. This will create ManagedDeployments with a name equal to the path key value, with a single ManagedComponent of type/subtype MBean/WebApplicationManager.

The WebModuleManagedDeploymentFactory is similar, but now defines that the servlets attribute of the root component should be treated as a refeferences to other mbeans that should be have ManagedObjects created for their MBeans, and be included in the deployment as MangedComponents(type=MBean,subtype=Servlet). The component name will be the mbean object name that is referenced.

[starksm64]

Also note that ManagedMBeanDeploymentFactory deployments can be done anywhere as long as there is a dependency on the ManagementView which defines the incallback/uncallback context injection for this type:

 <bean name="ManagementView" class="org.jboss.profileservice.management.ManagementViewImpl">
...
 <!-- Accept any implementor of ManagedMBeanDeploymentFactory -->
 <incallback method="addManagedMBeanDeployments"/>
 <uncallback method="removeManagedMBeanDeployments"/>
 </bean>

[jason.greene]

I am currently looking into a way to provide overrides for statistic properties. The code mentions supporting annotation metadata on MBeanInfo Descriptors, however that would require patching tomcat to provide this info.

[jason.greene]

Another problem I am having is that the tomcat mbeans are not invokable via the KernelDispatcher, I guess because the MC was not the creation source of this mbean. So, I guess this needs a special mbean dispatcher:

Caused by: java.lang.IllegalArgumentException: No such context: jboss.web:host=localhost,path=/jmx-console,type=Manager
 at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:51)
 at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:59)
 at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:85)

[jason.greene]

So, I guess this needs a special mbean dispatcher

Ok I have a prototype for this in my workspace that i will commit tomorrow morning once I verify it doesn't introduce regressions. For awhile I thought about registering MBeans into the MC via a kernel registry plugin, but then I realized that clearing these entries would require detecting and acting on unregistering (not so ideal).

[jason.greene]

Another issue that needs to be solved is association of a WAR deployment managed object to a tomcat Manager JMX entry. One possible way to correlate is to use the docBase property on the JSR-77 WebModule object.

Even better would be a way to set the context root on the ManagedDeployment of the WAR.

Is there an easy way for the AbstractWarDeployer to add a new ManagedProperty to the ManagedDeployment?

[jason.greene]

I have committed the new mbean dispatcher, and also introduced a temporary ViewUse default property, which I have set to statistic (until we come up with a better solution).

I also added a simple test case that verifies properties are working for all web component types (JMXMappingUnitTestCase).

[emuckenhuber]

Even better would be a way to set the context root on the ManagedDeployment of the WAR.

Hmm, can't we just connect the creation of statistic MBeans to a ManagedObject/ManagedComponent type?
So instead of having a pattern to do a jmx lookup it would be based on e.g. a JBossWebMetaData component when doing the processing in ManagementView. This would have the benefit that it could get the required information from the MO/component and has it's reference to the ManagedDeployment.

[starksm64]

"emuckenhuber" wrote:

Hmm, can't we just connect the creation of statistic MBeans to a ManagedObject/ManagedComponent type?
So instead of having a pattern to do a jmx lookup it would be based on e.g. a JBossWebMetaData component when doing the processing in ManagementView. This would have the benefit that it could get the required information from the MO/component and has it's reference to the ManagedDeployment.

That is what we need to do in the future, but currently the mbeans are created deep inside of the jbosweb layer as a side effect of creating various components.

[starksm64]

I am currently looking into a way to provide overrides for statistic properties. The code mentions supporting annotation metadata on MBeanInfo Descriptors, however that would require patching tomcat to provide this info.

Right. The only other way to pass this information in would be via the MDR MetaData interface.