Why do Topic/Queue descriptors need extra metadata in order

[ccrouch]

Looking at our example queues...

http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/etc/deploy/common/destinations-service.xml

I see they contain the following piece of metadata:

<annotation>
@org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO)
</annotation>

This appears to be needed in order for the Queue/Topic to be reachable through the profile service. The only problem with this is all the existing Topic/Queue descriptors created by users which won't have the extra metadata.

Is there anyway to avoid having to get people to update all of their deployment descriptors in order to make these resources manageable?

Thanks

[starksm64]

Its needed because the mbeans from the messaging project are not annotated with the jboss-managed information.

[ccrouch]

Ok so do we go about fixing this?

a) Have we approached the JBoss Messaging team about including these annotations on their classes

b) Can we supply our own version of org.jboss.jms.server.destination.QueueService which acts as a proxy and does include the annotations.

c) Can we supply this annotation as some sort of cross-cutting concern? i.e. all instances of org.jboss.jms.server.destination.QueueService created by the MC need to have this annotation applied. I'm fine with having another *single* deployment descriptor which we would ship with that defines this, as opposed to getting users to update *every* destination descriptor they have.

Cheers

[starksm64]

a) Have we approached the JBoss Messaging team about including these annotations on their classes

No, we were using it as a typical example of introducing admin to an external project. We should not have to annotate the beans to manage them.

b) Can we supply our own version of org.jboss.jms.server.destination.QueueService which acts as a proxy and does include the annotations.

Yes, we originally did that but it was more cumbersome in terms of taking existing messaging destination deployments and making them manageable.

c) Can we supply this annotation as some sort of cross-cutting concern? i.e. all instances of org.jboss.jms.server.destination.QueueService created by the MC need to have this annotation applied. I'm fine with having another *single* deployment descriptor which we would ship with that defines this, as opposed to getting users to update *every* destination descriptor they have.

This should be doable via the metadata repository using a loader that adds this annotation for specific mbean types. This could also be done by changing the ServiceMetaDataICF, probably other ways.

I'll create an issue and ask Ales to look at the metadata repository approach.

[starksm64]

https://jira.jboss.org/jira/browse/JBAS-6225

[ccrouch]

I'll create an issue and ask Ales to look at the metadata repository approach.

Thanks

[adrian.brock]

c) Can we supply this annotation as some sort of cross-cutting concern? i.e. all instances of org.jboss.jms.server.destination.QueueService created by the MC need to have this annotation applied. I'm fine with having another *single* deployment descriptor which we would ship with that defines this, as opposed to getting users to update *every* destination descriptor they have.

This should be doable via the metadata repository using a loader that adds this annotation for specific mbean types. This could also be done by changing the ServiceMetaDataICF, probably other ways.

The original idea was that all these factories (ManagedObject/MetaType/MetaValue)
contain overridde mechainsms.
So for example you can add a ManagedObjectBuilder by class to the
ManagedObjectFactory.

The further idea was that xml definitions for these plugins would be written
which would mean in the jboss-messaging deployment we could add some
xml to define their MO definitions.

This is necessary because although we can ask other jboss projects to annotate
their (m)beans for management, they might refuse, do it wrong or it might not be a
jboss project. So we need a way to retrofit or fix the managed object description.

[adrian.brock]

The further idea was that xml definitions for these plugins would be written
which would mean in the jboss-messaging deployment we could add some
xml to define their MO definitions.

Even without the xml, it should be possible to write a simple bean
that can be deployed to the MC to do this as a "quick fix".

[alesj]

Even without the xml, it should be possible to write a simple bean
that can be deployed to the MC to do this as a "quick fix".

I guess we need something like this (but more generic).

 Kernel kernel = null;
 KernelMetaDataRepository repository = kernel.getMetaDataRepository();
 MutableMetaDataRepository mmdr = repository.getMetaDataRepository();
 String className = context.getBeanInfo().getName();
 if ("org.jboss.jms.server.destination.QueueService".equals(className))
 {
 MutableMetaData retrieval = (MutableMetaData)mmdr.getMetaDataRetrieval(new ScopeKey(CommonLevels.CLASS, className));
 ManagementObjectClass moc = null; // proxy
 retrieval.addAnnotation(moc);
 }

But what would be a good place to add this?
Does ServiceControllerContext even have similar logic?

We need to know that context has passed Instantiate state - to match class name.

This would be pretty trivial to add as a bean with callbacks
if only callbacks could get a hold of ControllerContext that triggered callback. :-)

[alesj]

"alesj" wrote:

But what would be a good place to add this?
We need to know that context has passed Instantiate state - to match class name.

This would be pretty trivial to add as a bean with callbacks
if only callbacks could get a hold of ControllerContext that triggered callback. :-)

It is trivial. :-)

We could do it same way we do @JMX.
e.g.

 <lifecycle-instantiate xmlns="urn:jboss:aop-beans:1.0"
 name="MOCAdding"
 class="org.jboss.managed.MOCAdding"
 classes="org.jboss.jms.server.destination.QueueService">
 </lifecycle-instantiate>

[alesj]

"alesj" wrote:

Does ServiceControllerContext even have similar logic?

I guess not, as I see this in SMDICF:

 // Looks for a ManagementObjectClass annotation that defines
 // an alternate class to scan for management annotations
 List<ServiceAnnotationMetaData> samlist = md.getAnnotations();
 for (ServiceAnnotationMetaData sam : samlist)
 {
 // Annotations are not yet introduced to the actual mbean
 // so just look for the annotation string
 String anString = sam.getAnnotation();
 if (anString.startsWith(MOCLASS_ANNOTATION))
 {
 Class<?> originalClass = moClass;
 ManagementObjectClass moc = (ManagementObjectClass)sam.getAnnotationInstance(loader);
 moClass = moc.code();
 log.debug("Using alternate class '" + moClass + "' for class " + originalClass);

[adrian.brock]

"alesj" wrote:

Even without the xml, it should be possible to write a simple bean
that can be deployed to the MC to do this as a "quick fix".

I guess we need something like this (but more generic).

No I was talking about something like:

<bean code="...ManagedObjectDefinition">
 <property name="type">org.jboss.jms.server.destination.QueueService</property>
 <property name="builder">
 <javabean xmlns="..." class="...QueueMOBuilder"/>
 <property>
</bean>

Where ManagedObjectDefinition does something like

public void create()
{
 managedObjectFactory.add(type, builder);
}
public void destroy()
{
 managedObjectFactory.remove(type);
}

[alesj]

"alesj" wrote:

We could do it same way we do @JMX.

The question is, would this intercept ServiceControllerContext?

[alesj]

No I was talking about something like:
...
Where ManagedObjectDefinition does something like

Aha, I see.
Similar stuff to what you did with CreateDestinationDeployer.

OK, I'll add this to JBoss Managed:
- ManagedObjectDefinition
- ManagedObjectDefinitionInstaller (or some better name) that does add/remove to managedObjectFactory

Then it's up to jbossas components to add proper definition.
e.g. JMS would add QueueMOBuilder that sets proper org.jboss.jms.server.destination.QueueServiceMO

[alesj]

"alesj" wrote:

- ManagedObjectDefinitionInstaller (or some better name) that does add/remove to managedObjectFactory

Actually this is unnecessary.