JBossDeveloper

Shouldn't be, no.

Hmm, are you starting a JBoss dist in build/output? See http://lists.jboss.org/pipermail/jboss-development/2010-January/015499.html

I created a managed object in cleberts branch for our queue mbean objects and have been messing around with jopr etc, hacking it to expose the new MO's. Th eproblem is that unlike in JBM 1.4 these aren't deployed as services so the management module doesnt create them.

I am not 100% sure how we do this. Does any one know what i need to implement to be able to do this.

Cleberts correct, we don't want to be deploying destinations as beans or services.

I think what we need is a plugin that will update the management view by talking directly to the HornetQ server and also a way of HornetQ updating the management view when destinations are added etc. Any one any ideas if a) this is currently possible and b) where would it need to be implemented.

 
{quote}
HornetQ differs from MQ and JBoss Messaging on that aspect. Destinations are created within HornetQ and exposed as MBeans, JBM 1.4 and MQ do it differently. (You instantiate a MBean, then the Queue is created within the broker).
{quote}

It's not about using BeanMetaData like it was done with JBM 1.4 and MBeans - it's about registering destinations in MC and making them available for dependency handling. Like it's done in JBossMessagingCreateDestinationFactory:

{code}
      // Add this mbean to the mdbs depends

      Set<String> depends = mdb.getDepends();

      ...

      depends.add(objectName.getCanonicalName());
{code}

MC provides some indirection layers, so that you can use e.g. the BeanMetaDataBuilder programatically using a factory method (e.g. someService.createBean(...)) or use the kernel registry directly.

{quote}
Perhaps a deployer to create MOs based on metadata?
{quote}

Yes the creation of ManagedObjects is based on metadata attachments and the output of a deployer (deployer.setOutput()), since the MOs are based on the attachment meta data - without that you won't be able to create MOs.  Runtime characteristics like Metrics/Statistics and ManagedOperations depend on those beans to be registered in MC as well.
There are actually some workarounds to expose MBeans (not handled by MC) directly - this will most likely be removed in AS7, since we can only expose them and dispatch invocations using the MBeanServer.
 
So i guess it depends on the console what needs to be done. Not sure if it is ok to use this workaround and continual improve the integration, so that we are able to provide some additional features in future?

This is really a TAG issue; I'll open a TAG JIRA later this morning. AIUI, way back when using the ManagmentObject stuff was conceived as a general approach to management for JBoss projects, not just as a JBoss AS thing. So, while the opinions of all of us on this thread are important, none of us can decide the issue.

My opinions are....

I understand the desire to not expose destinations as MC beans. Hiding internal implementation details is architecturally sound. And looking at the HQ code it's clear that changing this would be really invasive.

If JOPR is able to work with JMX interfaces, it's reasonable to ask it to do so as long as all other requirements are met. That is, some convenience in coding the JOPR plugin is not sufficient justification to force projects into implementing MO interfaces. The JOPR folks probably have good arguments to the contrary, but that's how it seems to me.

The core of the issue is the "as long as all other requirements are met" bit. The key requirement is persistence of changes made via the console so they can be reapplied after server restart. HQ, for IMHO perfectly valid reasons, already persists internal state changes. Perhaps (probably) that meets the immediate need. But, as Emanuel said, for AS 7 the requirements are different. The AS intends to unify end user configuration in a single document (into which external schema elements like HornetQ's could be embedded). And the intent is to have the ProfileService persist changes made via the console back to that document. And keep it in sync around a cluster. Obviously for that to work the HQ stuff can't be totally opaque to the ProfileService.

I don't think it's necessary to require the HQ integration in AS 6 to support whiteboard-only features for AS 7. But,  I do think we need to develop a consensus around how we'll get there, not just kick the can down the road.

The other "as long as all other requirements are met" bit is providing a remote management API for the AS. That is, I blithely say above the JOPR folks should deal with a mix of MO and JMX. But in general asking external folks to do that is pretty poor. But, I've never heard of anyone other than JOPR using the MO stuff; from everyone else I hear calls for a REST interface.

We do for sure need the ability to deploy destinations via the ProfileService ManagementView, but that shouldn't require exposing destinations as ManagementObjects or other invasive changes.

Not having much knowledge of any of the management tools and or their implementations i can't really comment on what i think is the way forward. One thing i will say from what i have investigated so far is that there are numerous different ways to implement Management Functionality. One clear picture would be nice.

One thing i have been investigation is to implement a jopr hornetq plugin that contains a number of Components and Discovery Components that can be used to expose management functionality of any HornetQ Server, we can interogate the server using jmx, jms or anything else really. How this fits into the big picture i am not sure, but I will press on investigating.

emuckenhuber wrote:

It's not about using BeanMetaData like it was done with JBM 1.4 and MBeans - it's about registering destinations in MC and making them available for dependency handling. Like it's done in JBossMessagingCreateDestinationFactory:

      // Add this mbean to the mdbs depends
      Set<String> depends = mdb.getDepends();
      ...
      depends.add(objectName.getCanonicalName());

MC provides some indirection layers, so that you can use e.g. the BeanMetaDataBuilder programatically using a factory method (e.g. someService.createBean(...)) or use the kernel registry directly.

Good point about dependency handling. Being able to correctly configure dependencies between clients and destinations is important.