Application Server 3  4  5 and 6
  1. Application Server 3 4 5 and 6
  2. JBAS-5246 Open console support
  3. JBAS-6242

invoke() for "listFormattedSubPoolStatistics" ManagedOperation on datasources and connection factory ManagedComponents returns a MetaValue with the wrong MetaType

    Details

    • Similar Issues:
      Show 10 results 

      Description

      This is another case of the data not matching the metadata.

      operation.getReturnType() returns a MutableCompositeMetaType w/ typeName java.lang.Object. However, invoke() is returning a SimpleMetaType.STRING (with value e.g. "Sub Pool Statistics: \nSub Pool Count: 0\n------------------------------------------------------\n").

        Issue Links

          Activity

          Hide
          Adrian Brock
          added a comment -

          In my opinion, what it is doing is correct.

          The format of the statistics is determined by the statistics formatter.
          Which by default returns a String, but it could return anything.
          A collection of JBossSubPoolStatistics would be the most obvious alternative
          which would map to a collection of composite types for the same.

          You need to be able handle the return type dynamically,
          Its called polymorphism which is an integral part of any object orientated language.

          i.e. MetaValue returnValue = invoke(...)
          MetaType type = returnValue.getMetaType();
          // etc.

          If you can't handle that, then I'd suggest we add a new method which hardwires the String formatter
          with a String return type and only annotate that as a ManagedOperation.
          But this issue will come up elsewhere where the return type cannot be constrained so easily.

          Show
          Adrian Brock
          added a comment - In my opinion, what it is doing is correct. The format of the statistics is determined by the statistics formatter. Which by default returns a String, but it could return anything. A collection of JBossSubPoolStatistics would be the most obvious alternative which would map to a collection of composite types for the same. You need to be able handle the return type dynamically, Its called polymorphism which is an integral part of any object orientated language. i.e. MetaValue returnValue = invoke(...) MetaType type = returnValue.getMetaType(); // etc. If you can't handle that, then I'd suggest we add a new method which hardwires the String formatter with a String return type and only annotate that as a ManagedOperation. But this issue will come up elsewhere where the return type cannot be constrained so easily.
          Hide
          Charles Crouch
          added a comment -

          We need to know at compile time the full signature of the operation (return value and arguments) so that we can render the UI correctly. The UI is rendered from the operation definition not the runtime results.

          At runtime when we invoke the operation we can try and be clever about converting the type we actually get back to the type we expect. In fact this is what it looks like we are doing anyway since the listFormattedSubPoolStatistics operation is correctly returning a result which we display as a string in the console.

          Given the operation appears to be working now, I think we can drop the priority on this and revisit at a later date.

          From todays discussion one solution to this general problem would be to define managed operations in terms of specific arguments and results. So you would have one managed operation that specified the String based statistics formatter and another that passed in the JBossSubPoolStatistics, and each would have a different return type.

          Show
          Charles Crouch
          added a comment - We need to know at compile time the full signature of the operation (return value and arguments) so that we can render the UI correctly. The UI is rendered from the operation definition not the runtime results. At runtime when we invoke the operation we can try and be clever about converting the type we actually get back to the type we expect. In fact this is what it looks like we are doing anyway since the listFormattedSubPoolStatistics operation is correctly returning a result which we display as a string in the console. Given the operation appears to be working now, I think we can drop the priority on this and revisit at a later date. From todays discussion one solution to this general problem would be to define managed operations in terms of specific arguments and results. So you would have one managed operation that specified the String based statistics formatter and another that passed in the JBossSubPoolStatistics, and each would have a different return type.
          Hide
          Jason Greene
          added a comment -

          Moving to 5.1.1

          Show
          Jason Greene
          added a comment - Moving to 5.1.1
          Hide
          Jason Greene
          added a comment -

          There will not be a 5.1.1, moving to 5.2 for now

          Show
          Jason Greene
          added a comment - There will not be a 5.1.1, moving to 5.2 for now
          Hide
          Ian Springer
          added a comment -

          I'm not sure if this is still an issue. We need to try to reproduce it w/ the latest bits.

          Show
          Ian Springer
          added a comment - I'm not sure if this is still an issue. We need to try to reproduce it w/ the latest bits.
          Hide
          Scott Stark
          added a comment -

          I'm marking this resolved with deferred status as it essentially is an issue of documenting how the managed object layer needs to be configured to use a meta mapper to enforce a consistent metatype. See the associated discussion forum thread.

          Show
          Scott Stark
          added a comment - I'm marking this resolved with deferred status as it essentially is an issue of documenting how the managed object layer needs to be configured to use a meta mapper to enforce a consistent metatype. See the associated discussion forum thread.

            People

            • Assignee:
              Scott Stark
              Reporter:
              Ian Springer
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: