1 2 Previous Next 22 Replies Latest reply on Dec 3, 2008 4:09 AM by Ales Justin

    Why do Topic/Queue descriptors need extra metadata in order

    Charles Crouch Expert

      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

        • 1. Re: Why do Topic/Queue descriptors need extra metadata in or
          Scott Stark Master

          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
            Charles Crouch Expert

            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
              Scott Stark Master

               

              "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
                Charles Crouch Expert

                 

                "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 Master

                   

                  "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 Master

                     

                    "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
                      Ales Justin Master

                       

                      "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
                        Ales Justin Master

                         

                        "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
                          Ales Justin Master

                           

                          "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 Master

                             

                            "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 like
                            public void create()
                            {
                             managedObjectFactory.add(type, builder);
                            }
                            public void destroy()
                            {
                             managedObjectFactory.remove(type);
                            }
                            


                            • 12. Re: Why do Topic/Queue descriptors need extra metadata in or
                              Ales Justin Master

                               

                              "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
                                Ales Justin Master

                                 

                                "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
                                  Ales Justin Master

                                   

                                  "alesj" wrote:

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

                                  Actually this is unnecessary.


                                  1 2 Previous Next