4 Replies Latest reply on Oct 10, 2008 11:20 AM by Adrian Brock

    Depends on @JMX mbean name

    Scott Stark Master

      I'm looking at moving the naming services over to a beans.xml deployment, and one problem I'm seeing is that the mbean name associated with the @JMX annotation is not associated with the bean. This causes dependencies on the mbean name to fail:

      *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
      
      WebServer
       -> jboss:service=Naming{Create:** NOT FOUND Depends on 'jboss:service=Naming' **}
      
      jboss.admin:service=PluginManager
       -> jboss.jmx:name=Invoker,protocol=jrmp,service=proxyFactory,type=adaptor{Create:Configured}
      
      jboss.ejb:service=EJB3TimerService
       -> jboss:service=Naming{Create:** NOT FOUND Depends on 'jboss:service=Naming' **}
      
      


      How can we get these depends to continue to work?


        • 1. Re: Depends on @JMX mbean name
          Scott Stark Master

          Actually this is working. I had forgot that beans deployments now need to end in jboss-beans.xml and so none of the naming beans were even being deployed.

          • 2. Re: Depends on @JMX mbean name
            Anil Saldanha Master

             

            "scott.stark@jboss.org" wrote:
            Actually this is working. I had forgot that beans deployments now need to end in jboss-beans.xml and so none of the naming beans were even being deployed.


            I spent 30 mins of my time yesterday in tracing the log wondering why my xxx-beans.xml was not getting processed. How can we help users with this? Maybe some warning message hinting at xxx-jboss-beans.xml?

            I did spend another 30mins figuring out why the ENC to obtain the JBoss security manager was not working. I had forgotten the "java:/jaas" prefix in the jboss-web.xml security domain configuration.
            https://jira.jboss.org/jira/browse/JBAS-6060

            It is our own conventions biting us after few days/months. ;)

            • 3. Re: Depends on @JMX mbean name
              Adrian Brock Master

               

              "anil.saldhana@jboss.com" wrote:

              I spent 30 mins of my time yesterday in tracing the log wondering why my xxx-beans.xml was not getting processed. How can we help users with this? Maybe some warning message hinting at xxx-jboss-beans.xml?


              This really falls under the "missing deployer" category.
              But I think this is broken because we are generating some default metadata
              regardless of whether other deployers actually process the deployment.

              AbstractDeploymentUnit has
               public Object addAttachment(String name, Object attachment)
               {
               DeploymentContext deploymentContext = getDeploymentContext();
               deploymentContext.deployed();
               return deploymentContext.getTransientAttachments().addAttachment(name, attachment);
               }
              


              So when the classloader deployers adds attachments, e.g. create
              a default ClassLoadingMetaData for this top level deployment,
              it is treated as deployed.
              The same goes for the classpath deployer.

              I think to fix this, we need a new method that says the attachment we are
              adding should not be considered as flagging the deployment as really processed/deployed.

              • 4. Re: Depends on @JMX mbean name
                Adrian Brock Master

                 

                "adrian@jboss.org" wrote:

                This really falls under the "missing deployer" category.
                But I think this is broken


                We definitely need a test for this behaviour in the testsuite.