5 Replies Latest reply on Aug 17, 2009 8:10 AM by emuckenhuber

    profile service overview?

    jhalliday

      I'm working on making JBossTS integrate more cleanly with JBossAS.

      As a first step I'm shifting the configuration from a TS specific style of xml file to a set of beans which can be wired up by MC through deploy/transaction-jboss-beans.xml So far so good.

      However, under the old system the properties file could be rewitten remotely - a 'save' exposed by JMX caused the internal values to be serialized out to xml.

      What's the equivalent for persisting config updates in the JBossAS world? From what little I know of profile service it sounds like what I need. Does my code need to be written or wired up in a particular way to play nice with profile service, or do I just add a magic annotation in the -beans.xml? Pointers to any documentation on such things would be appreciated.

      Thanks.

        • 1. Re: profile service overview?
          emuckenhuber

          Yes, there are some magic annotations to control the management view of ProfileService. We actually expose the TransactionManager as ManagedObject already, by adding:

          <annotation>@org.jboss.managed.api.annotation.ManagementObject(name="TransactionManager",componentType=
          @org.jboss.managed.api.annotation.ManagementComponent(type = "MCBean", subtype = "JTA"),
          targetInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class)</annotation>
          

          Although the generated default view is most probably not usable for persistence, as it would try to persist all properties.

          Basically there are 2 ways of controlling this view: 1) by annotating the beans directly or 2) creatng a separate class and let profileservice create the ManagedObject based on this.
          This is basically what we do for JMS destinations e.g.:
          http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/main/org/jboss/jms/server/destination/QueueServiceMO.java

          There is also a wiki article about the available management annotations:
          http://www.jboss.org/community/wiki/ManagedObjects

          We are currently also working on a xml format describing the management object instead of annotations and additional configuration capabilities for AS6.

          • 2. Re: profile service overview?
            jhalliday

            Thanks for the pointers.

            > Although the generated default view is most probably not usable for persistence, as it would try to persist all properties.

            What's the problem with that? Type limitations?

            I definitely don't want a compile time dependency on profile service, so it looks like using annotations in the -beans.xml is the way to go.

            I can see how profile service can walk the bean properties and squirrel them aways for safe keeping (assuming they are serializable) but I'm less clear on the startup lifecycle.

            What's the relationship between MC injection and profile service overriding the values using those from it's saved settings? I need very specific timing - the values must be set before certain events in the startup sequence if the value set is going to have an effect. When is this currently done and is there a way to control it?

            • 3. Re: profile service overview?
              emuckenhuber

               

              "jhalliday" wrote:
              Thanks for the pointers.
              What's the problem with that? Type limitations?


              Basically all values of ManagedProperties are exposed as a MetaType and MetaValue pair consisting only of simple types.
              As this is a very generic processing it could happen that in some cases we cannot recreate the actual object, if we don't have additional information (e.g. a MetaMapper). That's why it would be good to review what's exposed and provide additional mappings if needed.
              This really depends on the complexity of e.g. your TSConfigurationBean.

              "jhalliday" wrote:

              I definitely don't want a compile time dependency on profile service, so it looks like using annotations in the -beans.xml is the way to go.

              Hmm i've never tried to put property annotations for profileservice in the -beans.xml directly, but should work. That's also why we are also working on a xml descriptor for this view.

              "jhalliday" wrote:

              What's the relationship between MC injection and profile service overriding the values using those from it's saved settings? I need very specific timing - the values must be set before certain events in the startup sequence if the value set is going to have an effect. When is this currently done and is there a way to control it?


              The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.

              • 4. Re: profile service overview?
                jhalliday

                > The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.

                huh? The MC is the only thing that knows how to instantiate some beans - the wiring for the factory method is part of the -beans.xml You are saying the profile service inserts itself after the process that parses the -beans.xml but before the bit that uses the resulting data, then takes upon itself to use the factory to instantiate the bean in place of MC doing that?

                • 5. Re: profile service overview?
                  emuckenhuber

                   

                  "jhalliday" wrote:
                  > The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.

                  huh? The MC is the only thing that knows how to instantiate some beans - the wiring for the factory method is part of the -beans.xml You are saying the profile service inserts itself after the process that parses the -beans.xml but before the bit that uses the resulting data, then takes upon itself to use the factory to instantiate the bean in place of MC doing that?


                  We are updating the meta data only, we don't instantiate/touch the bean itself.

                  Given you have a bean:

                  public class MyBean {
                   int timeout;
                   @ManagementProperty
                   public int getTimeout() { ... };
                   public void setTimeout(int timeout) { ... };
                  
                  }
                  


                  With it's -beans.xml:
                  <bean name="TimoutBean" class="MyBean">
                   <property name="timeout">12</property>
                  </bean>
                  


                  If there are persisted changes e.g. the timout value was changed to 15 then ProfileService would update the meta data like:
                  BeanMetaData.setProperty("timeout", 15):

                  So MC would create the bean still based on the on the -beans.xml descriptor from above, but would inject a value of 15 instead of 12.