14 Replies Latest reply on Jun 6, 2005 8:48 PM by starksm64

    JBoss Bean Deployer - JMX Integration

      I know we said we weren't going to worry too much about JMX integration in JBoss4.
      But it should be possible to provide some basic integration at the deployment level,

      <?xml version="1.0" encoding="UTF-8"?>
      <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
       <bean name="Name1" class="test.Hello">
       <property name="prop">Property</property>

      Where "loader-repository" and "depends" are the standard JMX MC notions.

      The main issue is how to do this while minimizing the "kludges" we have to support
      for backwards compatibility when there is a real integration between the JMX and POJO

        • 1. Re: JBoss Bean Deployer - JMX Integration

          If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name.

          The only scenario where I can see needing to specify a loader-repository is if a standalone bean deployment needs to use the scoped namespace of another legacy deployment. This is a rather exotic deployment for most users.

          If your just talking about allowing a standalone bean deployment to use a scoped class loader, can't we just use a bean reference to a class loader configuration and embed the configuration in the target bean?

          • 2. Re: JBoss Bean Deployer - JMX Integration


            "scott.stark@jboss.org" wrote:
            If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name.

            I'm not sure I like the idea of introducting yet another arbitrary naming space.
            Though I do agree that logical names are important.

            I would prefer the "alias notion" to be based on something more concrete, like.
            a contract rather than just an ad hoc notion.

             <mbean code="org.jboss.tm.TransactionManagerService"
             <attribute name="TransactionTimeout">300</attribute>
             <!-- set to false to disable transaction demarcation over IIOP -->
             <attribute name="GlobalIdsEnabled">true</attribute>
             <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
             <!-- depends optional-attribute-name="RecoveryLogger" proxy-type="org.jboss.tm.recovery.RecoveryLoggerInstance">jboss:service=RecoveryLogger</depends-->
             <bean interface="javax.transaction.TransactionManager"
             <factory bean="jboss:service=TransactionManager" method="getInstance"/>
             <bean name="MyBean">
             <property name="TM"><inject interface="javax.transaction.TransactionManager"/></property>

            And ideally, this type of monomorphic (one implementor of the contract) behaviour would
            be "automatic" without the too much need for explicit declaration.

             <bean name="MyBean">
             <property name="TM"><inject/></property> <!-- optional? -->

            There are other dependencies that are not directly related to injection,
            but have some logical component:

             <depends implementation="javax.jms" version="1.5"/>
             <bean name="MyBean"/>

            • 3. Re: JBoss Bean Deployer - JMX Integration

              If we are to have an alias scheme, I would prefer it to have some sort of "type"
              that could be used to identify mbean automatically, e.g.

              <depends type="Queue" name="testQueue"/>

              Otherwise you're going to either need to explicity declare aliases
              in the MBeans or get the relevent MBeans to populate the alias database
              in such as a way that they don't conflict.

              • 4. Re: JBoss Bean Deployer - JMX Integration

                How is the type enabling the namespace management? In you example it would seem that you are carving out a Queue namespace that can be augmented with keys known to be unique in the Queue namespace. So you want a type based name to ObjectName mapping function on the alias aspect of the SARDeployer?

                • 5. Re: JBoss Bean Deployer - JMX Integration

                  Yes, I would segment the namespace by type IF I were going to do it that way.

                  The trouble is that it relies on something that does not really exist, i.e.
                  some notion of an abstract Queue MBean or class/grouping of such MBeans.

                  Such a notion could be retrofitted to the MBeans with a
                  but that is pretty intrusive to the implementation
                  or it requires more xml in the deployment to state it,
                  or it requires another listener on deployments to generate the alias database
                  from known patterns in MBean deployments (often with those patterns being conventions

                  • 6. Re: JBoss Bean Deployer - JMX Integration

                    So use both an explicit alias attribute on the legacy mbean for complete control, and allow for a mapping function on the SARDeployer to transform ObjectNames meeting understood patterns to be transformed into a unique alias. The latter should generally be universially applicable as one would expect a convention was in place for all object names.

                    • 7. Re: JBoss Bean Deployer - JMX Integration

                      Yes, but surely all that does is introduce a binding to the new alias notion
                      rather than the ObjectName.

                      This might be useful for solving some problems like specifying the default datasource
                      (which already has an alias in that DefaultDS is already "hardwired" is some places)

                      To solve some other problems you would need to be able to specify an alias
                      based on some other name. e.g. automatically adding dependencies on
                      resource-refs based on jndi-name or ejb-refs based on ejb-name

                      <depends type="ejb" name="MyEJB"/>
                      would resolve to
                      but this also depends upon context as well since MyEJB can exist in multiple

                      I don't think adding a "trivial" alias notion would solve many problems,
                      and it would likely confuse some users. Users are confused enough
                      when the MBeans are created by deployers so they don't know what
                      names to use.

                      Instead, we should be working towards defining an
                      extensible dependency notion that understands context, type or anything
                      else that might be important.
                      This should produce something intuitive and allow users to "write their own
                      dependency" if nothing fits what they need.

                      • 8. Re: JBoss Bean Deployer - JMX Integration

                        Ok, but we seem to be mixing legacy vs future naming issues. Just throwing an alias attribute onto the existing mbean would seem to ease integration of non-jmx based stuff into the jmx mc, and avoids the exposure of a jmx name dependency in the new bean deployer.

                        • 9. Re: JBoss Bean Deployer - JMX Integration

                          Yes, but as I said above, I want to "minimiz(e) the kludges".

                          This can be done by introducing something that is based on what we want
                          going forward (even if it is incomplete).

                          e.g. when I've integration the jmx/pojo MCs
                          the injection should be "transparent" between the two. The transaction manager
                          factory above, doesn't really know that it is using an MBeanProxy on the

                          The problem before that integration (jboss4) is that the lifecycles or
                          configuration spaces aren't linked, except that the whole bean deployment is
                          managed by an MBean known to the SARDeployer.

                          I can hack some things to make it work better, but it isn't going to work as well
                          as the real solution in JBoss5.
                          There is sort of cross over here, in that we still want the old loader-repository
                          config to work in JBoss5, even when the classloaders are part of the DI framework.

                          • 10. Re: JBoss Bean Deployer - JMX Integration

                            So what is the "minimiz(e) the kludges" approach?

                            • 11. Re: JBoss Bean Deployer - JMX Integration


                              "scott.stark@jboss.org" wrote:
                              So what is the "minimiz(e) the kludges" approach?

                              I don't know yet.
                              If it was trivial, I probably wouldn't have mentioned the issue in the forums :-)

                              The issue is to spot that a dependency/injection is really an external dependency
                              outside the control of the bean MC and preprocess them into "depends"
                              to attach to the ServiceController registration, i.e. the wrapping container.

                              Anyway, we said we weren't going to worry too much about the JMX integration
                              for JBoss4 (at least in the initial release).

                              • 12. Re: JBoss Bean Deployer - JMX Integration

                                So I'm not seeing why its not as simple as injecting an object name pattern matcher to the sar deployer that returns the string alias:

                                interface TheMinimalHackThing
                                 String mapObjectNameToAlias(ObjectName name);
                                 String getAlias(ObjectName name);
                                 ObjectName getObjectName(String alias);

                                • 13. Re: JBoss Bean Deployer - JMX Integration

                                  I'm not sure I follow, I think we have got a bit off-topic :-)

                                  Certainly, I could make it a rule that if the depends or inject tag in the bean's xml
                                  has a name that is a valid ObjectName, then it is assumed to
                                  be a jmx dependency. This logic can be hidden away in the deployer/dependency
                                  processing of JBoss4's BeanDeployer.

                                  Whether we want to keep the jmx ObjectName as the namespace convention
                                  down the road is a different issue. It does have some advantages in terms
                                  of the flat namespace and querying, but it fails in its original intention of being a "logical"
                                  name for the underlying object (which is probably partly a fault of the way we use it).

                                  In many ways, querying on the real attribute/property values is probably better?

                                  Like I expressed above, I don't think that just a name is necessarily the best/only way
                                  to do this. Though using any other scheme will still require at least an internal unique "id".

                                  • 14. Re: JBoss Bean Deployer - JMX Integration

                                    I think we are still on topic target, its just a question of how the bean deployer is implementing the depends tag. Maybe I'm confusing the issue with the belief that the bean deployer already has a depends tag. That is what I am thinking and the question is one of making the jmx mc components available as dependencies targets in the bean deployers.

                                    As you said, this has a straightforward impl if one uses the jmx mc component object name, and the bean deployer assumes valid jmx names refer to components in the jmx mc.

                                    Beyond that is the question of mapping the jmx mc names into a non-jmx object name namespace for more natural pojo mc naming convention. Its a notion that has validity purely in the jmx mc as well given that there are more logical names/aliases for many services.

                                    For the not so logical names such as that assigned to an ejb local home or mdb deployment, there really is no natural name other than the existing ejb-name, but its far from being unique. I'm punting on this for now.