5 Replies Latest reply on Aug 3, 2007 12:37 PM by Scott Stark

    WriteThroughManagedPropertyImpl

    Adrian Brock Master

      What is WriteThroughManagedPropertyImpl doing?

      It is the Fields implementation that should be doing this (setting the property
      on the attachment).
      The ManagedProperty(Impl) is just a wrapper for the Fields to make the api easier to use
      at the front end.

      There should be a JavaBeanFields implementation, a DomFields, etc.

        • 1. Re: WriteThroughManagedPropertyImpl
          Scott Stark Master

          Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed.

          • 2. Re: WriteThroughManagedPropertyImpl
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:
            Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed.


            I don't know what ManagementObejct.fieldsFactory is?
            Are you talking about the annotation or something else?

            It should be upto the caller (deployer or overrides) to decide how to generate the fields,
            i.e.
            1) it is a flattened javabean tree
            2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans
            3) it is from an MBean definition
            4) it represents a XML DOM
            5) something else
            etc.

            The only one I'd implemented was (2) and then that wasn't complete,
            e.g. it didn't update the javabean in the setValue().
            That is unless you count the crappy MockDomFields in the testsuite. :-)

            • 3. Re: WriteThroughManagedPropertyImpl
              Scott Stark Master

               

              "adrian@jboss.org" wrote:

              I don't know what ManagementObejct.fieldsFactory is?
              Are you talking about the annotation or something else?

              Yes, its a field in the @ManagementProperty I added.

              "adrian@jboss.org" wrote:

              It should be upto the caller (deployer or overrides) to decide how to generate the fields,
              i.e.
              1) it is a flattened javabean tree
              2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans
              3) it is from an MBean definition
              4) it represents a XML DOM
              5) something else
              etc.

              Right, which is why I added the ability to describe what the Fields and ManagedProperty implementation are from the annotation.



              • 4. Re: WriteThroughManagedPropertyImpl
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:

                Right, which is why I added the ability to describe what the Fields and ManagedProperty implementation are from the annotation.


                Ok, but I think in general people will want to "mix and match"
                the javabean stuff. e.g. flatten everything except this part
                or like on other thread, this Collection is to be exposed as a Map.

                I don't see a problem with defining a global strategy on the @ManagementObject
                but you also need to be able to override it on the @ManagementProperty

                • 5. Re: WriteThroughManagedPropertyImpl
                  Scott Stark Master

                   

                  "adrian@jboss.org" wrote:

                  Ok, but I think in general people will want to "mix and match"
                  the javabean stuff. e.g. flatten everything except this part
                  or like on other thread, this Collection is to be exposed as a Map.

                  I don't see a problem with defining a global strategy on the @ManagementObject
                  but you also need to be able to override it on the @ManagementProperty

                  Right now in fact its only supported on the @ManagementProperty. It does need to be definable globally to simplify.