-
1. Re: Why do Topic/Queue descriptors need extra metadata in or
starksm64 Nov 20, 2008 5:09 PM (in response to ccrouch)Its needed because the mbeans from the messaging project are not annotated with the jboss-managed information.
-
2. Re: Why do Topic/Queue descriptors need extra metadata in or
ccrouch Nov 20, 2008 5:25 PM (in response to 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 -
3. Re: Why do Topic/Queue descriptors need extra metadata in or
starksm64 Nov 20, 2008 5:46 PM (in response to ccrouch)"charles.crouch@jboss.com" wrote:
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."charles.crouch@jboss.com" wrote:
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."charles.crouch@jboss.com" wrote:
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. -
5. Re: Why do Topic/Queue descriptors need extra metadata in or
ccrouch Nov 20, 2008 5:59 PM (in response to ccrouch)"scott.stark@jboss.org" wrote:
I'll create an issue and ask Ales to look at the metadata repository approach.
Thanks -
6. Re: Why do Topic/Queue descriptors need extra metadata in or
adrian.brock Nov 21, 2008 5:19 AM (in response to ccrouch)"scott.stark@jboss.org" wrote:
"charles.crouch@jboss.com" wrote:
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. -
7. Re: Why do Topic/Queue descriptors need extra metadata in or
adrian.brock Nov 21, 2008 5:21 AM (in response to ccrouch)"adrian@jboss.org" wrote:
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". -
8. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 8:39 AM (in response to ccrouch)"adrian@jboss.org" 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).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. :-) -
9. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 8:50 AM (in response to ccrouch)"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>
-
10. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 8:54 AM (in response to ccrouch)"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);
-
11. Re: Why do Topic/Queue descriptors need extra metadata in or
adrian.brock Nov 21, 2008 9:04 AM (in response to ccrouch)"alesj" wrote:
"adrian@jboss.org" 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 likepublic void create() { managedObjectFactory.add(type, builder); } public void destroy() { managedObjectFactory.remove(type); }
-
12. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 9:04 AM (in response to ccrouch)"alesj" wrote:
We could do it same way we do @JMX.
The question is, would this intercept ServiceControllerContext? -
13. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 9:21 AM (in response to ccrouch)"adrian@jboss.org" wrote:
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 -
14. Re: Why do Topic/Queue descriptors need extra metadata in or
alesj Nov 21, 2008 9:28 AM (in response to ccrouch)"alesj" wrote:
- ManagedObjectDefinitionInstaller (or some better name) that does add/remove to managedObjectFactory
Actually this is unnecessary.