Uploaded image for project: '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").

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            adrian.brock 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 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
            ccrouch 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
            ccrouch 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 Jason Greene added a comment -

            Moving to 5.1.1

            Show
            jason.greene Jason Greene added a comment - Moving to 5.1.1
            Hide
            jason.greene Jason Greene added a comment -

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

            Show
            jason.greene Jason Greene added a comment - There will not be a 5.1.1, moving to 5.2 for now
            Hide
            ips 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
            ips 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
            starksm64 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
            starksm64 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:
                starksm64 Scott Stark
                Reporter:
                ips Ian Springer
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development