1 2 3 Previous Next 30 Replies Latest reply on Jan 3, 2008 6:22 AM by Jonathan Halliday

    migrating from ServiceMBeanSupport

    Jonathan Halliday Master

      I'm migrating some existing code that used to use JBossAS ServiceMBeanSupport to the microcontainer. I'd appreciate any information on the best approach to the following two issues:

      The software is used standalone as well as in JBossAS. Internally we will continue to use MBeans as that's easiest for the standalone version. The JBossAS integration previously called ServiceMBeanSupport.getServer() to get an MBeanServer for use internally. What is the equivalent call in MC (or AS5.0)?

      We previously used NotificationListener to register such that a method on our bean is invoked when some other bean (jboss.system:type=Server) entered a specified state (running). Is there a way to wire such a thing in MC? It's not quite the same as requiring the other bean to be started before our bean. Indeed, such a solution is not viable as we must start earlier. The BarrierController seems close to what I need but the example is old - is this functionality still present in MC? (http://wiki.jboss.org/wiki/Wiki.jsp?page=BarrierController)

      Thanks

        • 1. Re: migrating from ServiceMBeanSupport
          Ales Justin Master

           

          "jhalliday" wrote:

          The software is used standalone as well as in JBossAS. Internally we will continue to use MBeans as that's easiest for the standalone version. The JBossAS integration previously called ServiceMBeanSupport.getServer() to get an MBeanServer for use internally. What is the equivalent call in MC (or AS5.0)?

          MC is all about POJOs.
          So there is no direct link to MBeanServer or other MC internals.
          But you can simply get that injected - @Inject or via XML.
          It's up to your bean. ;-)

          "jhalliday" wrote:

          We previously used NotificationListener to register such that a method on our bean is invoked when some other bean (jboss.system:type=Server) entered a specified state (running). Is there a way to wire such a thing in MC? It's not quite the same as requiring the other bean to be started before our bean. Indeed, such a solution is not viable as we must start earlier. The BarrierController seems close to what I need but the example is old - is this functionality still present in MC? (http://wiki.jboss.org/wiki/Wiki.jsp?page=BarrierController)

          You can use different dependency mechanisms. From the one's that already exist - depend, demand - or you can easily write your own.
          Or there is also KernelEventListener - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/spi/event/ - if that's what suites you best.
          e.g.
          <bean name="mybean" class="org.jboss.acme.FooBar">
           <demands state="Start">jboss.system:type=Server</demand>
          </bean>
          


          • 2. Re: migrating from ServiceMBeanSupport
            Ales Justin Master

            In this e.g. case 'jboss.system:type=Server' must already be installed in order for 'mybean' demand dependency to be satisfied - to pass Start state.

            • 3. Re: migrating from ServiceMBeanSupport
              Jonathan Halliday Master

              Thanks Ales

              For the MBeanServer, I've opted to try injecting. That should work, but I can't figure out the correct xml.

              <mbean name="jboss:service=TransactionManager"
               code="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
               <constructor>
               <parameter type="javax.management.MBeanServer">
               <inject bean="JMXKernel" property="mbeanServer"/></parameter>


              does not work, the parameter elements are not seen. Scott suggested

              <arg type="javax.management.MBeanServer"><inject
              bean="JMXKernel" property="mbeanServer"/></arg>


              instead, which does not work either ("Missing 'value' attribute in constructor arg"). That leaves me stuck, as I can't figure out the syntax for injecting to an attribute in the xml.


              For the notifications, there does not appear any way to specify what I want in xml. I'll either have to split my bean into two or link it against the event listener code.

              • 4. Re: migrating from ServiceMBeanSupport
                Scott Stark Master

                Injection would be done via an attribute like:

                <mbean name="jboss:service=TransactionManager"
                 code="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
                ...
                 <attribute name="MBeanServer"><inject bean="JMXKernel" property="mbeanServer"/></attribute>
                
                </mbean>
                



                • 5. Re: migrating from ServiceMBeanSupport
                  Jonathan Halliday Master

                  Scott

                  That value is write once i.e. I want it set through the constructor, not exposed as a setter on the bean. Are you saying that's not possible currently?

                  Thanks

                  • 6. Re: migrating from ServiceMBeanSupport
                    Ales Justin Master

                     

                    "jhalliday" wrote:
                    Are you saying that's not possible currently?

                    Looking at the code:
                    - http://anonsvn.jboss.org/repos/jbossas/trunk/system-jmx/src/main/org/jboss/system/metadata/ServiceMetaDataParser.java
                    looks like you currently cannot do injection with constructor (see parseConstructor method).

                    • 7. Re: migrating from ServiceMBeanSupport
                      Jonathan Halliday Master

                      Fair enough. So I can't do much of my setup in the service constructor, as I don't have the information yet at that time. I need to do the work in the start method instead. That's actually less effort for me, as it's how things currently work.

                      The problem with that is: many other services depend on the transaction manager. As far as I can tell, under the old pre-MC semantics, depends meant 'ensure the other service has started'. As a result, work the transaction manager does in the start method would be finished before anything that depends on it was executed. Under MC, depends seems to mean 'ensure the service I depend on has reached at least the same point in the lifecycle as the one I'm transitioning to' by default.

                      As a result, some services are being instantiated and failing because they actually depend on the transaction manager having been started, not just created. Moving the work of transaction manager setup into its service constructor would have fixed that, but it's not an option. The only alternative I see is to change the depends clause of all the things that depend on the transaction manager, such that they explicitly require it to be started. That's somewhat less elegant than I was hoping for.

                      • 8. Re: migrating from ServiceMBeanSupport
                        Ales Justin Master

                         

                        "jhalliday" wrote:
                        Fair enough. So I can't do much of my setup in the service constructor, as I don't have the information yet at that time. I need to do the work in the start method instead. That's actually less effort for me, as it's how things currently work.

                        btw: what's stopping you from using MC beans instead of mbeans, if you're already migrating

                        "jhalliday" wrote:

                        The problem with that is: many other services depend on the transaction manager. As far as I can tell, under the old pre-MC semantics, depends meant 'ensure the other service has started'. As a result, work the transaction manager does in the start method would be finished before anything that depends on it was executed. Under MC, depends seems to mean 'ensure the service I depend on has reached at least the same point in the lifecycle as the one I'm transitioning to' by default.

                        Previous depend was/is like this:
                        A depends on B --> B created, then A could be created, B started, A could start
                        And this is still the same:
                        From ServiceDependencyMetaData
                         visitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.CREATE));
                         visitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.START));
                        

                        From MC's AbstractDependencyMetaData
                         DependencyItem item = new LifecycleDependencyItem(context.getName(), ControllerState.CREATE);
                         visitor.addDependency(item);
                         item = new LifecycleDependencyItem(context.getName(), ControllerState.START);
                         visitor.addDependency(item);
                        


                        • 9. Re: migrating from ServiceMBeanSupport
                          Jonathan Halliday Master

                          ok, so I must be doing something wrong then. I take a class that previously extended ServiceMBeanSupport. I change it so it no longer does so. I change startService() to start(). I drop it into the app server and hey presto, thing that depend upon it break.

                          12:29:28,517 INFO [JMXKernel] Legacy JMX core initialized
                          12:29:41,350 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/
                          12:29:43,385 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,type=local state=Create mode=Manual requiredState=Installed
                          javax.naming.NameNotFoundException: TransactionManager not bound
                          at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
                          at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
                          at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
                          at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
                          at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
                          at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
                          at javax.naming.InitialContext.lookup(InitialContext.java:351)
                          at org.jboss.invocation.local.LocalInvoker.startService(LocalInvoker.java:77)
                          at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)


                          If I'm reading that trace right, the name=jboss:service=invoker,type=local bean is being started and running into problems because start() has not yet been called on the transaction manager bean. I think there is some mismatch here between the lifecycle that occured under ServiceMBeanSupport. vs. the one I get with MC.

                          • 10. Re: migrating from ServiceMBeanSupport
                            Ales Justin Master

                             

                            "jhalliday" wrote:
                            I change it so it no longer does so. I change startService() to start().

                            What about createService() --> create()?

                            • 11. Re: migrating from ServiceMBeanSupport
                              Jonathan Halliday Master

                              I don't have a createService/create method. Besides, the invoker bean is moving into the run state, which means the transaction manger should have had start() called on it? It does not seem to get that call. I can add a create() to see if that gets called, but I'm not clear what help that would be.

                              • 12. Re: migrating from ServiceMBeanSupport
                                Jonathan Halliday Master

                                hmm, create() does not get called either. Is it possible there is something odd with lifecycle callbacks to mbeans?

                                • 14. Re: migrating from ServiceMBeanSupport
                                  Jonathan Halliday Master

                                   

                                  <mbean name="jboss:service=TransactionManager" code="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
                                   <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
                                   <property name="transactionTimeout">300</property>
                                   <property name="ObjectStoreDir">${jboss.server.data.dir}/tx-object-store</property>
                                   </mbean>
                                  


                                  1 2 3 Previous Next