-
1. Re: How to Expose MBean Invocation Stats into admin-console?
emuckenhuber May 7, 2009 6:33 AM (in response to alrubinger)In general ManagedObjects are generated based on the meta data attachments in the deployers and exposed over ManagedDeployments (@see mainDeployer.getManagedDeployment)
So ManagementView load() gets all ManagedDeployments managed by ProfileService.
This basically means that when statistic MBeans are getting directly registered over the MBeanServer (so no meta data attachments) are not visible to ProfileService.
The ProxyManagedDeploymentFactory has a install callback directly on ManagementView to work around this problem. Additionally it provides some functionality to create a ManagedObject based on a MBeanInfo (@see MBeanManagedObjectFactory).
So a basic view would not require any additional annotations, except there should be different behavior for certain properties.
Maybe you also want to take a look at: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229210#4229210 -
2. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 7, 2009 11:01 AM (in response to alrubinger)As soon as the ProxyManagedDeploymentFactory is working adequately, I'll update the current managed object wiki with all of the recent changes. The current page is:
http://www.jboss.org/community/docs/DOC-11349 -
3. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 7, 2009 11:15 AM (in response to alrubinger)Thanks for the links guys.
How do I verify that my ManagedObject is registered, and can I browse through its properties? Is there some equivalent to JNDIView in jmx-console or elsewhere?
S,
ALR -
4. Re: How to Expose MBean Invocation Stats into admin-console?
emuckenhuber May 7, 2009 11:21 AM (in response to alrubinger)"ALRubinger" wrote:
How do I verify that my ManagedObject is registered, and can I browse through its properties? Is there some equivalent to JNDIView in jmx-console or elsewhere?
There is a basic debug servlet:
http://localhost:8080/jmx-console/ProfileServiceDebugServlet?op=listDeploymentTree -
5. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 7, 2009 11:32 AM (in response to alrubinger)"emuckenhuber" wrote:
There is a basic debug servlet:
http://localhost:8080/jmx-console/ProfileServiceDebugServlet?op=listDeploymentTree
That's love.
Will also help me with ensuring the new bootstrap impl has all the correct properties exposed. Mind if I add this link to the Wiki, or is there a more appropriate place?
S,
ALR -
6. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 7, 2009 11:42 AM (in response to alrubinger)Its fine to add it to the wiki. We certainly want to update the debugging tools as well.
-
7. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 27, 2009 1:34 PM (in response to alrubinger)At the point now where I'm adding a ManagedObject:
@ManagementObject(name = "jboss.system:type=ALRTest", isRuntime = true, properties = ManagementProperties.EXPLICIT, description = "Some test", componentType = @ManagementComponent(type = "MCBean", subtype = "*")) public class BasicSessionMetrics implements SessionMetrics{...}
This gets installed like:@Override public void deploy(final DeploymentUnit du, final Ejb3Deployment deployment) throws DeploymentException { // Determine if we process this deployment if (deployment == null) { // Not an EJB3 Deployment if (log.isTraceEnabled()) { log.trace("Skipping non-EJB3 Deployment: " + du); } return; } // Log if (log.isTraceEnabled()) { log.trace("Deploying EJB3 Session metrics for : " + du); } // Make a new metrics definition final String metricsBeanName = deployment.getName() + BEAN_NAME_METRICS_SUFFIX; final SessionMetrics metrics = new BasicSessionMetrics(); // Add the attachment du.addAttachment(metricsBeanName, metrics); // Set metrics upon the deployment deployment.setMetrics(metrics); log.debug("Set EJB3 metrics upon " + du); // Set a flag showing we were here as the output du.addAttachment(NAME_OUTPUT, true, Boolean.class); }
...though does not appear in the ManagedObjects debug servlet. Should I be expecting it there?
S,
ALR -
8. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 27, 2009 3:03 PM (in response to alrubinger)I would expect so, but let me do a quick test.
Also, is this metrics instance going to be registered in the mc kernel under the name jboss.system:type=ALRTest? If not, the properties and operations will not be usable as these are accessed via a kernel bus using the component name. -
9. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 27, 2009 3:14 PM (in response to alrubinger)Aha, works now:
final BeanMetaData bean = bmdb.getBeanMetaData(); // Add the attachment du.addAttachment(BeanMetaData.class, bean);
...yielding:ManagedDeployment: vfszip:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.1.0.GA/server/default/deploy/ejbthree1677.jar/ +++ ManagedComponent(name=org.jboss.ejb3.metrics.impl.BasicSessionMetrics, type=(ComponentType{type=MCBean, subtype=*}), compName=ejbthree1677.jar-metrics, attachment: org.jboss.ejb3.metrics.impl.BasicSessionMetrics ++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount]
S,
ALR -
10. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 27, 2009 3:31 PM (in response to alrubinger)Which also will have the managed object correctly wired to the bean component.
-
11. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 27, 2009 3:45 PM (in response to alrubinger)The problem now is that I've added a metadata attachment, whereas I need to be adding the object itself. As it's this object which I'll later inject into the EJB3 Code and invoke upon it to update the stats.
S,
ALR -
12. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 27, 2009 3:50 PM (in response to alrubinger)Just set the ctor on the bean meta data to use the JBossASKernel.AlreadyInstantiated ctor metadata. I think we are doing this elsewhere for the situation you describe.
public static class AlreadyInstantiated extends AbstractConstructorMetaData { private static final long serialVersionUID = 1L; private Object bean; public class Factory { public Object create() { return bean; } } public AlreadyInstantiated(Object bean) { this.bean = bean; this.setFactory(new AbstractValueMetaData(new Factory())); this.setFactoryClass(Factory.class.getName()); this.setFactoryMethod("create"); } }
-
13. Re: How to Expose MBean Invocation Stats into admin-console?
alrubinger May 28, 2009 6:35 PM (in response to alrubinger)Cool, so I'm still going the POJO route to pave the way for the future. Plus it's easy to just write a deployer to do this.
What I'm seeing however, is that only *one* @ManagedObject is exposed per DeploymentUnit, and it's whatever the last one added by my deployer is.ManagedDeployment: vfszip:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/stateless-test.jar/ +++ ManagedComponent(name=org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=UnsecuredStatelessBean-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics ++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount
Is this because of a non-unique name for the attachment?du.addAttachment(BeanMetaData.class, bean);
The following does not pick up any attachments:du.addAttachment(uniqueName, bean, BeanMetaData.class)
What's the deployer which inspects the DU attachments?
Once I get all my attachments in place, I'm done w/ exposing EJB3 Metrics :)
S,
ALR -
14. Re: How to Expose MBean Invocation Stats into admin-console?
starksm64 May 28, 2009 6:50 PM (in response to alrubinger)Correct, there can only be one BeanMetaData.class attachment in a unit. To have multiple BeanMetaDatas you need to create a component deployment and add the attachment to it.
Its the org.jboss.deployers.spi.deployer.helpers.DefaultManagedObjectCreator that is building the set of managed objects for a deployment, and it is just iterating over all attachment names so I'm not sure why the unique name approach would not work.