-
1. Re: ManagedObject support in next messaging release
clebert.suconic Sep 11, 2007 2:06 PM (in response to starksm64)> or 1.4.0.GA to be usable in jbossas5/4.x, a separate integration layer is needed to isolate the jbossas specific dependencies
Shouldn't this integration with MC exist on jbossas/trunk? on that case there is no need to hold the 1.4.0.GA release?
JBossMessaging, as you said, could be both used by JBAS 4 and JBAS 5... so we can't implement those MC interfaces directly, right?
anyway... do you have any other service as an example with what needs to be done? -
2. Re: ManagedObject support in next messaging release
starksm64 Sep 11, 2007 3:13 PM (in response to starksm64)Yes, I would say it should be in AS or an AS specific codebase outside of the jms core.
You simply need to annotate the service mbean code class, an example of which is here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ManagedObjects in the "Annotating a Service MBean Class" section.import org.jboss.managed.api.ManagedOperation.Impact; import org.jboss.managed.api.annotation.ManagementObject; import org.jboss.managed.api.annotation.ManagementObjectID; import org.jboss.managed.api.annotation.ManagementOperation; import org.jboss.managed.api.annotation.ManagementParameter; import org.jboss.managed.api.annotation.ManagementProperties; import org.jboss.managed.api.annotation.ManagementProperty; import org.jboss.managed.api.annotation.ViewUse; @ManagementObject(componentType=@ManagementComponent(type="JMSDestination",subtype="Queue"), properties=ManagementProperties.EXPLICIT) class QueueService { // Add ManagementProperty, ManagementOperation annotations }
-
3. Re: ManagedObject support in next messaging release
timfox Sep 17, 2007 10:25 AM (in response to starksm64)Ok if this is just adding an annotation it should be easy.
BTW lucky we decided to move to Java5 with JBM, otherwise I don't know how we would have done this. -
4. Re: ManagedObject support in next messaging release
alesj Sep 17, 2007 10:59 AM (in response to starksm64)"timfox" wrote:
BTW lucky we decided to move to Java5 with JBM, otherwise I don't know how we would have done this.
MC has annotations per instance via XML.
So no luck included here. ;-) -
5. Re: ManagedObject support in next messaging release
clebert.suconic Sep 20, 2007 12:59 PM (in response to starksm64)"alesj" wrote:
MC has annotations per instance via XML.
So no luck included here. ;-)
That would be a good option for us, so we wouldn't need to add any JBoss5 specific annotations on our code, as our code is also intended to run on JBoss4.
but i can't find any documentation on how to do it. -
6. Re: ManagedObject support in next messaging release
clebert.suconic Sep 20, 2007 2:15 PM (in response to starksm64)"clebert.suconic@jboss.com" wrote:
"alesj" wrote:
MC has annotations per instance via XML.
So no luck included here. ;-)
That would be a good option for us, so we wouldn't need to add any JBoss5 specific annotations on our code, as our code is also intended to run on JBoss4.
but i can't find any documentation on how to do it.
I just confirmed that this doesn't exist yet...
I will just add the annotations to org.jboss.mq.server.jmx.Queue and Topic...
So the annotation will sit in an integration layer:
http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/main/org/jboss/mq/server/jmx/Queue.java
http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/main/org/jboss/mq/server/jmx/Topic.java -
7. Re: ManagedObject support in next messaging release
starksm64 Sep 20, 2007 7:12 PM (in response to starksm64)That means that the messaging destinations need to use these mbeans. Currently that is not the case:
[starksm@succubus testsuite]$ cat ../build/output/jboss-5.0.0.Beta3/server/default/deploy/messaging/destinations-service.xml <?xml version="1.0" encoding="UTF-8"?> <!-- Messaging Destinations deployment descriptor. $Id: destinations-service.xml 64130 2007-07-18 23:21:27Z clebert.suconic@jboss.com $ --> <server> <!-- The Default Dead Letter Queue. This destination is a dependency of an EJB MDB container. --> <mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=DLQ" xmbean-dd="xmdesc/Queue-xmbean.xml"> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> </mbean> <!-- The Default Expiry Queue. --> <mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=ExpiryQueue" xmbean-dd="xmdesc/Queue-xmbean.xml"> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> </mbean> </server>
-
8. Re: ManagedObject support in next messaging release
timfox Sep 21, 2007 4:27 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
That means that the messaging destinations need to use these mbeans. Currently that is not the case:
Right, I'd rather not force people to change their configs - this could be a real hassle.
I'd rather just add the annotations to the current classes and live with the necessary imports.
When we do the full MC integration as part of JBM 2.0 (i.e. POJOify everything) then we'll be changing everything around anyway and this will result in config changes. We could create the proper integration layer at that stage. -
9. Re: ManagedObject support in next messaging release
clebert.suconic Sep 21, 2007 10:36 AM (in response to starksm64)I'd rather just add the annotations to the current classes and live with the necessary imports.
This would force us to add jboss-managed.jar (from jboss-5) into jboss4/lib when installing jboss-messaging.
If there is no issue on adding that jar, I would prefer doing it this way also.
(Actually Scott, why don't you see if we could have jboss-managed.jar officially distributed as part of jboss-4. This way annotated services would be able to be deployed on both servers). -
10. Re: ManagedObject support in next messaging release
timfox Sep 21, 2007 10:50 AM (in response to starksm64)Can't we just annotate via xml as Ales mentioned?
That would make life a whole lot easier -
11. Re: ManagedObject support in next messaging release
starksm64 Sep 21, 2007 11:00 AM (in response to starksm64)Here is another approach that also moves toward having the annotations in the xml config. We do have some annotation support in the service mbean descriptors, for example:
<mbean name="jboss.test:type=BasicMBeanName" code="BasicMBeanCode"> <annotation>@org.jboss.test.system.metadata.annotation.CompType(type="DS",subtype="LocalTX")</annotation> </mbean>
so I can add a ManagedCode annotation that allows you to specify the class to scan for the management annotations. You can then add empty subclasses of the jms destination mbeans in the server/messaging project and then specify the management annotations on those, and point to those classes using the annotation element. Perhaps this can reuse the legacy mbeans Clebert updated. I have reopened JBAS-4658 for this. -
12. Re: ManagedObject support in next messaging release
starksm64 Sep 21, 2007 4:02 PM (in response to starksm64)"timfox" wrote:
Can't we just annotate via xml as Ales mentioned?
That would make life a whole lot easier
Possibly, if you change from -service.xml to -beans.xml for the destinations. -
13. Re: ManagedObject support in next messaging release
anil.saldhana Sep 24, 2007 4:48 PM (in response to starksm64)Just like EJB3, Web Services , why cannot messaging have the integration code base in the AS workspace?
This really is a critical task which has been raised since few months now. -
14. Re: ManagedObject support in next messaging release
dimitris Nov 7, 2007 12:53 PM (in response to starksm64)In my local workspace I can add an annotation in the mc/managed api like:
package org.jboss.managed.api.annotation; ... @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface ManagementObjectClass { /** The class annotated with ManagementObject */ Class code(); }
Then update the mc/org.jboss.managed.plugins.factory.AbstractManagedObjectFactory to handle the indirection from the ManagementObjectClass annotation to the real ManagedObject one.
Will this be picked up whoever calls the ServiceMetaDataICF.getManagedObjectClass(ServiceMetadata md) method?
If yes, no change would be need there.
Or have I missunderstood what you want?