1 2 3 Previous Next 36 Replies Latest reply on May 30, 2002 3:45 AM by Juha Lindfors

    MBeans version management

    Fusayuki Minamoto Apprentice

      I wonder how I can unregister/register mbeans based on VERSION attribute of MLet conf file.
      When calling getMBeansFromURL(), I'd like to replace obsolete mbeans with new ones based on the version values of MLet conf files.

      The JMX book p.161 states Sun Reference Implementation doesn't make use of the version attribute.
      Although I browsed the JBossMX source, I couldn't find it supported the version attribute neither.

      Is there any way to handle mbeans version with JBossMX?
      An idea is making a custom mbean that handles the version with the MLet service the recyle mbean on the JMX book pp.162-170.

      Any comments are appreciated.

      Miki


        • 1. Re: MBeans version management
          Juha Lindfors Master

          Hi,

          > I wonder how I can unregister/register mbeans based on VERSION attribute of MLet conf file.
          > When calling getMBeansFromURL(), I'd like to replace obsolete mbeans with new ones based on the version
          > values of MLet conf files.
          >
          > The JMX book p.161 states Sun Reference Implementation doesn't make use of the version
          > attribute. Although I browsed the JBossMX source, I couldn't
          > find it supported the version attribute neither.

          That's true. We parse the VERSION tag but don't do anything with the information. Partly due to spec not really defining how the version should be handled and because even the RI didn't give hints about it, partly due to not knowing how people would want to use it.


          > Is there any way to handle mbeans version with
          > JBossMX?

          Not currently.

          > An idea is making a custom mbean that handles the
          > version with the MLet service the recyle mbean on the
          > JMX book pp.162-170.

          Your idea sounds valid. At the moment though there are few other things on my list of things to do before this one. Would you be interested in contributing the code to do this? I can point you to the classes you need to look at if you need.

          -- Juha

          • 2. Re: MBeans version management
            Fusayuki Minamoto Apprentice

            juha,

            Thank you for your reply.

            > Your idea sounds valid. At the moment though there are
            > few other things on my list of things to do before this
            > one. Would you be interested in contributing the code
            > to do this? I can point you to the classes you need to
            > look at if you need.

            Yes, I would.
            I am very interested in contribution whatever I could.
            (But I don't have a line of code yet about the mbean.)

            I'm looking at the sources for MLet and MLetParser.
            The custom mbean might be a tiny standard mbean with following features:

            o it has a getMBeansFromURL() that replaces the obsolete mbeans based on VERSION attribute.

            o it keeps the mlet info set after parsing MLet conf files and adds update times to the set.

            o it has list() like JNDIView to list all mbeans for management purpose.
            It would show mlet info and update times as text.

            I don't see technical issues about this mbean yet.
            Please give me your adivce.

            Miki

            • 3. Re: MBeans version management
              Juha Lindfors Master

              > I'm looking at the sources for MLet and MLetParser.
              > The custom mbean might be a tiny standard mbean with
              > following features:

              We don't need a custom MBean for this. We already have one. That is the MBean Registry MBean.


              > o it has a getMBeansFromURL() that replaces the
              > e obsolete mbeans based on VERSION attribute.

              We could add this to the MLet class itself. Currently the problem is with the MBeanServer interface which does not allow us to attach custom "metadata" with the MBean registration -- such as the VERSION number passed in an mlet text file. Also the time/date of registration is something useful that we could attach as part of the informtation stored in the MBean Registry (the entries are instances of org.jboss.mx.server.registry.MBeanEntry objects, we can add the relevant fields there).

              Time/date can be handled by the registry itself. The version we cannot get from the MLet to registry through createMBean (which is what we use now), or insantiate/registerMBean combo.

              However, like I said the MBean Registry in JBossMX is just another MBean and we expose a management interface for it. Instead of relying on the insufficient MBeanServer interface from the MLet class, we can invoke an operation on the mgmt interface of the registry that allows the "custom" version information to be added to the registry. We currently already have a version of registerMBean() method as part of the registry interface that allows an extra "magic token" argument to be passed with MBean registration; this is used internally by the server to manipulate the JMImplementation domain. We could replace the Object magicToken field with a map that would get attached with the MBeanEntry going to the registry. Then modify the MLet to call registry directly when MBeans are created -- call MBeanServer.invoke("registerMBean") instead of MBeanServer.registerMBean().

              Then when a new MBean is being registered to the registry, check the existence of version field, if it exists --> compare, if a newer one is being registered, unregister the old MBean first, then register the new one with updated version & date/time fields.


              > o it keeps the mlet info set after parsing MLet
              > t conf files and adds update times to the set.

              see above, we could keep the registration times in the registry


              > o it has list() like JNDIView to list all mbeans
              > s for management purpose.

              this is presentation... should go as part of the "presentationString" xml string in the registry model mbean descriptors -- once we can decide on some sort of schema on what should go into the presentationString field.

              Adrian, any thoughts?

              -- Juha

              • 4. Re: MBeans version management
                Adrian Brock Master

                This sounds ok.

                Looks like we might make the managed version of the
                registry the default after all ;-)

                We should probably make the context classloader part of
                the payload object as well.

                Should we define the payload keys somewhere or just
                document the keys supported by the registry?

                Regards,
                Adrian

                • 5. Re: MBeans version management
                  Fusayuki Minamoto Apprentice

                  Thank you for your good advice.
                  Now I see the whole picture with the Agent View :-)

                  > Then when a new MBean is being registered to the
                  > registry, check the existence of version field, if it
                  > exists --> compare, if a newer one is being registered,
                  > unregister the old MBean first, then register the new
                  > one with updated version & date/time fields.

                  I'd like to skip the unnecessary downloads of new mbeans.
                  That's why I need to have mbeans version management.

                  According to your idea, I believe I could do the following steps at the MLet getMBeansFormURL() method.

                  For each mbean metadata in a MLet conf file:
                  1. Get a MBeanEntry for the mbean from MBeanRegistry.
                  2. If the version of the MBeanEntry is obsolete, continue the mbeans iteration.
                  3. Call server.instantiate() to create the mbean object.
                  4. Call MBeanRegistry.invoke("registerMBean").

                  Is this ok?

                  BTW, I found "(Operation Not Supported)" at the Description of registerMBean with the Agent View.
                  Do we have to change the method signature or argument types of the operation?

                  Miki

                  • 6. Re: MBeans version management
                    Adrian Brock Master

                    The operation not supported is a shortcoming
                    of the html adaptor. It does work just not from
                    the agent view because of the Object parameters.

                    Regards,
                    Adrian

                    • 7. Re: MBeans version management
                      Juha Lindfors Master

                      > We should probably make the context classloader part of the payload object as well.

                      yes


                      > Should we define the payload keys somewhere or just document the keys supported by the registry?

                      could probably define at least the basic ones in the ServerConstants, this is mostly for internal use for the moment, although someone probably comes up with an application specific use at some point.

                      if that is what you meant by define?

                      -- Juha

                      • 8. Re: MBeans version management
                        Adrian Brock Master

                        Yes, a bit like the way notification types are defined.

                        I will look at doing the registry part this weekend.

                        Exposing the get(ObjectName) method might be a bit
                        dangerous.
                        Should the mangement method return a clone or
                        is this to be left to security?

                        Regards,
                        Adrian

                        • 9. Re: MBeans version management
                          Juha Lindfors Master

                          > Exposing the get(ObjectName) method might be a bit
                          > dangerous.

                          yeah I don't like it either...

                          how about we don't expose get in the management interface, just a method to query the values, like getValue(VERSION)... keep MBeanEntry as an internal structure to the registry.


                          > Should the mangement method return a clone or
                          > is this to be left to security?

                          avoid returning it altogether if possible... clone if you have to... then slap security permissions on it later

                          -- Juha

                          • 10. Re: MBeans version management
                            Juha Lindfors Master

                            > Do we have to change the method signature or argument
                            > types of the operation?

                            no, don't change the API because of the adaptor (it sucks anyway).

                            eventually we will need a real adaptor implementation that can handle complex types

                            -- Juha

                            • 11. Re: MBeans version management
                              Fusayuki Minamoto Apprentice

                              Thank you guys.
                              I understand the flaw of the HTML adapter.

                              > Exposing the get(ObjectName) method might be a bit
                              > dangerous.

                              In fact, I saw the method and called it on the Agent View.

                              >> o it has list() like JNDIView to list all mbeans
                              >> s for management purpose.
                              >
                              > this is presentation... should go as part of
                              > the "presentationString" xml string in the registry
                              > model mbean descriptors -- once we can decide on some
                              > sort of schema on what should go into the
                              > presentationString field.

                              Sorry I don't follow this in the context of my question.
                              You mean you would re-implement MBeanRegistry as a model mbean?

                              Miki

                              • 12. Re: MBeans version management
                                Juha Lindfors Master

                                > Sorry I don't follow this in the context of my
                                > question.
                                > You mean you would re-implement MBeanRegistry as a
                                > model mbean?

                                it is a model mbean already..

                                with a proper http adaptor you could just get an MBean view of the registry, which in this case might be the list of MBeans in the agent... the presentation is controlled by an XML string that is attached as a descriptor to the MBean. Good starting point for an adaptor.

                                -- Juha

                                • 13. Re: MBeans version management
                                  Fusayuki Minamoto Apprentice

                                  > it is a model mbean already..

                                  Oh, I didn't notice the ManagedMBeanRegistry.

                                  > with a proper http adaptor you could just get an MBean > view of the registry, which in this case might be the
                                  > list of MBeans in the agent... the presentation is
                                  > controlled by an XML string that is attached as a
                                  > descriptor to the MBean. Good starting point for an
                                  > adaptor.

                                  Now I'm reading the ModelMBeanInfoSupport.java.
                                  In jmx sources, I couldn't find how to use the presentationString.
                                  Besides, the JMX spec p.93 says it is not yet deinfed.

                                  If we recognize this as an implementation dependent matter,
                                  which module is responsible to define the schema between the agent or the registry mbean?
                                  Do you have any pointer or reference to know that?

                                  Thank you.

                                  Miki

                                  • 14. Re: MBeans version management
                                    Juha Lindfors Master

                                    > Now I'm reading the ModelMBeanInfoSupport.java.
                                    > In jmx sources, I couldn't find how to use the
                                    > presentationString.

                                    I mean pseudo:

                                     Descriptor d = new DescriptorSupport();
                                    d.setField(PRESENTATION_STRING, "<YOUR XML GOES HERE>");
                                    
                                    mbean.setMBeanDescriptor(d);
                                    



                                    > Besides, the JMX spec p.93 says it is not yet
                                    > deinfed.

                                    That is alright, we can define our own. We will set the de facto standard for JMX usage.


                                    > which module is responsible to define the schema
                                    > between the agent or the registry mbean?
                                    > Do you have any pointer or reference to know that?

                                    It would most likely be a XLS transformation between the defined PresentationString schema (which schema is being used can also be included in the descriptor) and the adaptor doing a conversion to a HTML presentation.

                                    We do not have an adaptor like that yet.

                                    I apologize that I'm mixing these two different issues with the same conversation. It is a bit confusing. However, this is how I see the future HTML adaptors working.

                                    -- Juha


                                    1 2 3 Previous Next