1 2 3 4 Previous Next 53 Replies Latest reply on May 22, 2008 8:16 AM by dimitris Go to original post
      • 30. Re: migrating TransactionManager and Invokers to POJO

         

        "jhalliday" wrote:

        I also have problems because some things are not happening in the right order. Before either create or start is called on the transaction manager bean I see something that depends on it being started. Huh? This does not follow my understanding of the lifecycle, which is that dependent objects should not move into a state until everything they depend on has achieved at least an equivalently advanced state. Does the required state need to be specified explicitly on the CachedConnectionManager? Or perhaps this behaviour is something to do with the CCM being an mbean whilst the TM is a bean?

        14:22:54,750 ERROR [AbstractKernelController] Error installing to Start: name=jboss.jca:service=CachedConnectionManager state=Create mode=Manual requiredState=Installed
        java.lang.ExceptionInInitializerError
         at org.jboss.resource.connectionmanager.CachedConnectionManager.startService(CachedConnectionManager.java:191)
        ...
        Caused by: java.lang.RuntimeException: Unable to locate the transaction manager
         at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:105)
        ...
        


        What does your implementation look like?

        If you register it as an MBean you effectively get a duplicate lifecycle,
        once from the registeration in the ServiceController and once from the
        registration as a POJO.

        The ServiceMBeanSupport works around this by only allowing create() to propogate
        to createService() when it is not already done.

        Stupid I know, but nobody has gotten around to fixing the
        @JMX support to link the ServiceController lifecycle to the POJO one.

        i.e. it shouldn't move to the create() state in the old JMX kernel until it moves
        to the create() state in the MC (and then it should be a no-op in JMX).

        i.e. The serviceController.start() in the code below shouldn't exist. Instead
        the create/start/stop/destroy moves in the ServiceController should be
        driven off the POJO lifecycle.
        http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/main/org/jboss/system/microcontainer/jmx/ServiceControllerLifecycleCallback.java?revision=70844&view=markup
         server.registerMBean(mbean, objectName);
         try
         {
         serviceController.start(objectName);
         }
         catch (Exception e)
         {
         try
         {
         server.unregisterMBean(objectName);
         }
         catch (Exception t)
         {
         log.debug("Error unregistering mbean", t);
         }
         throw e;
         }
         log.debug("Registered MBean " + objectName);
        


        • 31. Re: migrating TransactionManager and Invokers to POJO
          jhalliday

          > Either use the @JMX annotation or the MBeanExporter, don't do both.

          ok, so I'll go for

          <deployment xmlns="urn:jboss:bean-deployer:2.0">
           <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
           <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation>
          
           <property name="transactionTimeout">300</property>
           <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property>
          
           </bean>
          </deployment>
          


          > You don't have two objects, you have two attempts at MBeanRegistration.

          I still have two calls to my bean's constructor. That means I have two object instances.

          2008-03-31 15:00:47,849 DEBUG [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (main) Added component TransactionManager to vfsfile:/home/jhalli/IdeaProjects/jboss/jbossas_trunk/build/output/jboss-5.0.0.CR1/server/default/deploy/transaction-beans.xml
          2008-03-31 15:00:47,926 INFO 2008-03-31 15:00:47,927 ERROR [STDERR] (main) java.lang.Exception: Stack trace
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at java.lang.Thread.dumpStack(Thread.java:1158)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at com.arjuna.ats.jbossatx.jta.TransactionManagerService.<init>(TransactionManagerService.java:114)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:137)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:200)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:80)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:240)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:45)
          2008-03-31 15:00:47,927 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:108)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:69)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:54)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1324)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:574)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:398)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:46)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
          2008-03-31 15:00:47,928 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:946)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:967)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:887)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1324)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:579)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:259)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:137)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.Main.boot(Main.java:209)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at org.jboss.Main$1.run(Main.java:544)
          2008-03-31 15:00:47,929 ERROR [STDERR] (main) at java.lang.Thread.run(Thread.java:595)
          ...
          2008-03-31 15:00:48,121 ERROR [STDERR] (main) java.lang.Exception: Stack trace
          2008-03-31 15:00:48,121 ERROR [STDERR] (main) at java.lang.Thread.dumpStack(Thread.java:1158)
          2008-03-31 15:00:48,121 ERROR [STDERR] (main) at com.arjuna.ats.jbossatx.jta.TransactionManagerService.<init>(TransactionManagerService.java:114)
          2008-03-31 15:00:48,121 ERROR [STDERR] (main) at com.arjuna.ats.jbossatx.jta.AOPContainerProxy$0.<init>(AOPContainerProxy$0.java)
          2008-03-31 15:00:48,121 ERROR [STDERR] (main) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at java.lang.Class.newInstance0(Class.java:350)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at java.lang.Class.newInstance(Class.java:303)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.instantiateAndConfigureProxy(GeneratedAOPProxyFactory.java:145)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.getProxy(GeneratedAOPProxyFactory.java:120)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.createAdvisedProxy(GeneratedAOPProxyFactory.java:85)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:87)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:240)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:45)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:108)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:69)
          2008-03-31 15:00:48,122 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:54)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1324)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:574)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:398)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88)
          2008-03-31 15:00:48,123 ERROR [STDERR] (main) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:46)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:946)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:967)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:887)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1324)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
          2008-03-31 15:00:48,124 ERROR [STDERR] (main) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:579)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:259)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:137)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.Main.boot(Main.java:209)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at org.jboss.Main$1.run(Main.java:544)
          2008-03-31 15:00:48,125 ERROR [STDERR] (main) at java.lang.Thread.run(Thread.java:595)


          If the startup ordering problem can be resolved I don't really care how many instances are created. But right now I need to do setup in the constructor because it's the only way I can ensure it happens before things that depend on it are started.

          • 32. Re: migrating TransactionManager and Invokers to POJO
            alesj

             

            "jhalliday" wrote:
            I still have two calls to my bean's constructor. That means I have two object instances.


            The second call to the constructor is a call to the AOP proxy constructor:
            2008-03-31 15:00:48,121 ERROR [STDERR] (main) at com.arjuna.ats.jbossatx.jta.AOPContainerProxy$0.<init>(AOPContainerProxy$0.java)


            • 33. Re: migrating TransactionManager and Invokers to POJO
              jhalliday

              That thread dump is caused by my code. That means my object's constructor function is being invoked twice. I don't care what's doing it, I just want it to stop :-)

              • 34. Re: migrating TransactionManager and Invokers to POJO
                alesj

                 

                "jhalliday" wrote:
                That means my object's constructor function is being invoked twice. I don't care what's doing it, I just want it to stop :-)

                Go for the MBeanExporter than + remove the @JMX pointcut. ;-)

                • 35. Re: migrating TransactionManager and Invokers to POJO
                  jhalliday

                  > Go for the MBeanExporter than + remove the @JMX pointcut. ;-)

                  I'm not sure I understand that. You are saying to remove the

                  <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectl
                  y=true)</annotation>
                  and go back to the
                  <bean name="MBeanExporter"
                  stuff instead? Ok, that removes one constructor call, which makes me happy. It also prevents anything that depends on "jboss:service=TransactionManager" from working. How do I resolve that without linking my source against the JMX stuff again?

                  • 36. Re: migrating TransactionManager and Invokers to POJO

                     

                    "jhalliday" wrote:
                    That thread dump is caused by my code. That means my object's constructor function is being invoked twice. I don't care what's doing it, I just want it to stop :-)


                    The double construction is because AOP is creating an instance proxy
                    as you have an instance annotation. The @JMX only applies
                    to that instance not all instances your class.

                    Try doing a System.out.println(getClass()) where you dumpStack()
                    and you'll see the class is different.

                    Either, move the @JMX to be an annotation on your class (thus removing the
                    need for the instance proxy) - a simple way to do this would be to have
                    a subclass in the JBossAS project with that annotation.

                    Or use the MBeanExporter so you don't have instance annotations.

                    In practice we don't need an instance proxy for the @JMX annotation
                    so we should probably look at creating a meta annotation
                    to exclude @JMX from the decision as to whether an instance proxy is required.

                    • 37. Re: migrating TransactionManager and Invokers to POJO
                      alesj

                       

                      "adrian@jboss.org" wrote:
                      In practice we don't need an instance proxy for the @JMX annotation
                      so we should probably look at creating a meta annotation
                      to exclude @JMX from the decision as to whether an instance proxy is required.

                      I though the proxy instance came from this:
                       <!-- Add the JMX -->
                       <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0"
                       name="JMXAdvice"
                       class="org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback"
                       classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX"
                       manager-bean="AspectManager"
                       manager-property="aspectManager">
                       <property name="serviceController"><inject bean="JMXKernel" property="serviceController"/></property>
                       </aop:lifecycle-configure>
                      


                      Or do we really create proxy instance (if AOP present) for instance annotations?



                      • 38. Re: migrating TransactionManager and Invokers to POJO
                        • 39. Re: migrating TransactionManager and Invokers to POJO
                          jhalliday

                          If I've understood the ServiceControllerLifecycleCallback/MBeanExporter stuff correctly, it takes some metadata and uses it to expose a bean as an mbean. That metadata can come from an annotation on the class (which I don't want because it takes me back to having JMX info in my source, which is no improvement on the current situation in which I extend a JMX relate base class) or it can come from an annotation element in the -beans.xml (which causes the extra constructor call). Is that correct?

                          • 40. Re: migrating TransactionManager and Invokers to POJO

                             

                            "alesj" wrote:

                            Or do we really create proxy instance (if AOP present) for instance annotations?


                            We need the instance proxy if we actually bind aop advices for runtime uses.

                            In this case, we just want to use the pointcut language to decide what extra
                            operations should be performed on the instance during deployment.

                            When I originally wrote it, the @JMX added an aop introduction to the class
                            for the KernelControllerContextAware.
                            This intercepted the setKernelControllerContext() but that's not how it
                            should be working now?

                            If it is how it still works, then it isn't what I asked you and Kabir to do for this task
                            http://jira.jboss.com/jira/browse/JBMICROCONT-77

                            e.g. When we implement JBMICROCONT-78 there won't even be an
                            instance of the POJO to intercept, just a registration in JMX with an option to "start()"
                            that will create the instance.

                            • 41. Re: migrating TransactionManager and Invokers to POJO
                              alesj

                               

                              "alesj" wrote:

                              Or do we really create proxy instance (if AOP present) for instance annotations?

                              Aha, ok this is the code:
                               boolean hasInstanceMetaData = hasInstanceOrJoinpointMetaData(metaData);
                               ContainerCache cache = ContainerCache.initialise(manager, clazz, metaData, hasInstanceMetaData);
                               AOPProxyFactoryParameters params = new AOPProxyFactoryParameters();
                               Object target = createTarget(cache, params);
                               params.setProxiedClass(target.getClass());
                               params.setMetaData(metaData);
                               params.setTarget(target);
                               params.setContainerCache(cache);
                               params.setMetaDataHasInstanceLevelData(hasInstanceMetaData);
                              
                               return proxyFactory.createAdvisedProxy(params);
                               }
                              
                               private boolean hasInstanceOrJoinpointMetaData(MetaData metaData)
                               {
                               if (metaData == null)
                               {
                               return false;
                               }
                              
                               if (hasMetaDataAtInstanceLevel(metaData))
                               {
                               return true;
                               }
                              
                               //Check for method annotations
                               return hasMethodMetaData(metaData);
                               }
                              
                               private boolean hasMetaDataAtInstanceLevel(MetaData metaData)
                               {
                               if (metaData != null)
                               {
                               MetaData instanceMetaData = metaData.getScopeMetaData(CommonLevels.INSTANCE);
                               if (instanceMetaData != null && instanceMetaData.isEmpty() == false)
                               {
                               return true;
                               }
                               }
                               return false;
                               }
                              

                              What would this return (e.g. target == Jonathan's TransactionManager):
                              a) target.getClass().getAnnotation(JMX.class) == null
                              b) target.getClass().getAnnotation(JMX.class) == @JMX instance

                              • 42. Re: migrating TransactionManager and Invokers to POJO
                                alesj

                                 

                                "jhalliday" wrote:
                                If I've understood the ServiceControllerLifecycleCallback/MBeanExporter stuff correctly, it takes some metadata and uses it to expose a bean as an mbean. That metadata can come from an annotation on the class (which I don't want because it takes me back to having JMX info in my source, which is no improvement on the current situation in which I extend a JMX relate base class) or it can come from an annotation element in the -beans.xml (which causes the extra constructor call). Is that correct?

                                Yup, you're on target. :-)
                                It's just that JBMDR-21 is missing that will make your thing work as you (and we also :-) want it to.

                                • 43. Re: migrating TransactionManager and Invokers to POJO
                                  alesj

                                   

                                  "alesj" wrote:

                                  What would this return (e.g. target == Jonathan's TransactionManager):
                                  a) target.getClass().getAnnotation(JMX.class) == null
                                  b) target.getClass().getAnnotation(JMX.class) == @JMX instance

                                  (a) as expected. ;-)
                                   assertIsAspectized("Bean5");
                                   Object bean = getBean("Bean5", SimpleBeanImpl.class);
                                   Class<?> clazz = bean.getClass();
                                   Annotation annotation = clazz.getAnnotation(SomeNonIA.class);
                                   assertNull(annotation);
                                  


                                  • 44. Re: migrating TransactionManager and Invokers to POJO
                                    kabirkhan

                                    Having thought about it a bit, I don't like the @InstanceAnnotation from JBMDR-21. It works fine for the majority of cases where people use the lifecycle-configure stuff. BUT what if they for whatever reason also want to do things like

                                    <bind execution="* @JMX->*(..)">
                                     <interceptor-ref name="JMXTrackingAspect"/>
                                    </bind>
                                    


                                    Then since the JMX annotation is ignored due to the @InstanceAnnotation annotation, no proxy is created.

                                    I added the following to your test locally
                                     <interceptor xmlns="urn:jboss:aop-beans:1.0" class="org.jboss.test.microcontainer.beans.TestAspect"/>
                                    
                                     <bind xmlns="urn:jboss:aop-beans:1.0" pointcut="all(@org.jboss.test.microcontainer.support.ContainsIA2)">
                                     <advice aspect="org.jboss.test.microcontainer.beans.TestAspect" name="advice"/>
                                     </bind>
                                    
                                     <bean name="Bean7" class="org.jboss.test.microcontainer.support.SimpleBeanImpl">
                                     <annotation>@org.jboss.test.microcontainer.support.ContainsIA2</annotation>
                                     </bean>
                                    


                                    @ContainsIA2 is similar to @ContainsIA. The test fails on
                                     assertIsAspectized("Bean7");
                                    


                                    Bean7 should have a proxy.

                                    I don't think it is a good idea for the annotation to dictate the usage? I could add something to AOP to determine if the instance annotation actually ends up resulting in more aspects (not lifecycle callbacks), and if that is the case return a proxy?