4 Replies Latest reply on Feb 6, 2002 1:54 PM by Juha Lindfors

    name and class fields in MMBOpInfo Descriptor

    Trevor Squires Novice


      From the docs for MMBOpInfo descriptor:

      name: operation name
      class: fully qualified class where method is defined

      First off, the class field is pointless because by the time you try to invoke() on a resource you *only* care about methods exposed in the resource.

      On to "name".

      When trying to resolve a Method object for invoke() do I use the "name" from the descriptor or do I use the the name from the MMBOpInfo?

      I would have assumed I would use the one from MMBOpInfo 'cause that's where I have to get the signature from. But then again, the spirit of Descriptors seems to be virtualising everything (operation name "foo" resolves to a method "bar") so maybe I should use the "name" field in the descriptor...

      "name" might also be some sort of unique token so that setMethod and getMethod entries in an MMBAttrInfo descriptor can resolve the correct operation...

      Choices, choices.

      Sigh.
      Trev

        • 1. Re: name and class fields in MMBOpInfo Descriptor
          Trevor Squires Novice

          yet again, I reply to my own post.

          I can now only see one sensible interpretation for the name field in the OpInfo descriptor and the setMethod/getMethod fields in the AttrInfo descriptor.

          OpInfo.Descriptor.name == Method(in target).getName()
          AttrInfo.Descriptor.[get|set]Method == OpInfo.getName()

          Assuming that MMBs have been spec'd to allow multiple target objects, that's the only interpretation that supports them. Otherwise you open yourself up to name collisions where two different target objects have a getStatus() method and you want to expose one of those methods as a Status attribute.

          Still, I could be missing the point...

          Trev

          • 2. Re: name and class fields in MMBOpInfo Descriptor
            Juha Lindfors Master

            name is a link between the descriptor and info objects.

            the descriptor associated with an operation info must have its name set to the name of the operation info

            so MBeanOperationInfo.getDescriptor().getFieldValue("name").equals(MBeanOperationInfo.getName())

            same for the values of the setMethod and getMethod, they're names of the operations (which is the same in both the info and its associated descriptor).

            • 3. Re: name and class fields in MMBOpInfo Descriptor
              Trevor Squires Novice

              Ok,

              found the bit in the spec and I agree.

              I presume rules for binding an attribute to an op with a role of "setter" or "getter" is the same as for StdMBeans.

              I.e. getter has zero length arg list and returns non-void,
              setter returns void and has arg list.length == 1, and setter and getter must both refer to the same type.

              I'm assuming another restriction when binding an Attribute to an operation - that the type for the operation return value and arg list is identical to the type for the attribute. I.e. I won't be doing any isAssignableFrom() checks.

              Trev

              • 4. Re: name and class fields in MMBOpInfo Descriptor
                Juha Lindfors Master

                > I.e. getter has zero length arg list and returns
                > non-void,
                > setter returns void and has arg list.length == 1, and
                > setter and getter must both refer to the same type.

                yes, that's the only way it would seem to work. Although it's something that they really should add to the spec and say explicitly.

                > I'm assuming another restriction when binding an
                > Attribute to an operation - that the type for the
                > operation return value and arg list is identical to
                > the type for the attribute. I.e. I won't be doing
                > any isAssignableFrom() checks.

                ok.

                -- Juha