2 Replies Latest reply on Jan 7, 2005 3:01 PM by adrian.brock

    @Mbean

    bill.burke

      I think there are 2 types of definition for this and 2 types of deployment


      Let's look at the 2 types of definition:

      * One is, the introduction obtains the management interface in a generic way.

      * The other is the introduction obtains the management interface (and metadata) through other annotations.

      The two types of deployment

      * The class is just tagged as @Mbean(). MBean instances are defined and deployed through regular XML

      * The class is tagged with @MBean(objectName="jboss:service=Foo"). In this case, the deployer will iterate through all class files in the deployment looking for classes tagged with @MBean and that have an objectName defined. These will be deployed directly into JMX and XML is not needed to deploy these services. We should have a similar @Bean annotation that automatically deploys a class into the JBoss kernel/pojo container.

      Bill

        • 1. Re: @Mbean
          starksm64

          This intersects with the Annotation vs MetaData discussion in the other thread. The two beans you are describing here are just expressing the metadata via different mechanisms. There has to be an overall deterministic way of building up the entire heirarchy of metadata from the annotations to xml to runtime overrides.

          • 2. Re: @Mbean

            There is actually a third. With the new microcontainer there needs to be
            a configuration where the beans registered with a name can optionally (the default
            will be true when this processing is enabled) to expose these on the MBeanServer
            using the DynamicMBean introduction.

            That is when the MicroContainer is configured to be exposed via JMX

            Similarly, the MBeans need to be exposed on the MicroContainer's Bus/registry.

            This allows both configuration spaces to deal with objects regardless of which method
            is used to register them.