7 Replies Latest reply on Feb 27, 2008 11:19 PM by Scott Stark

    Stats issue

    Scott Stark Master

      The issue with stats not being returned is that the property values are not being taken from the runtime component. When the ManagedComponent is built and the runtime stats merged into it, we need to be pulling in the current runtime property values. Right now we only pass new values back to the runtime component.

        • 1. Re: Stats issue
          Scott Stark Master

          I just committed a fix for this along with the duplicate DefaultDS ManagedComponent issue.

          • 2. Re: Stats issue
            Mark Spritzler Apprentice

            Thanks, It is very cool, I am now getting DS Stats, and I am also seeing only one DefaultDS returned from managementView.getComponentsForType(ComponentType).

            But did something change in the api for ManagementView?
            calling ManagementView.getTemplate(String templateName) is giving me a NoSuchMethodError.

            I am going to check the checkins and the UnitTestCase to see if it has changed to what it was changed to, so I can call it.

            Thanks

            • 3. Re: Stats issue
              Scott Stark Master

               

              "bytor99999" wrote:

              But did something change in the api for ManagementView?
              calling ManagementView.getTemplate(String templateName) is giving me a NoSuchMethodError.

              No, should not have. I did not make any api changes in the ProfileServiceUnitTestCase. My current trunk workspace is a mess, so I'll rebuild trunk on another box to see if the ProfileServiceUnitTestCase is working as expected there. Should only be 2 errors related to the generic connection factory deployments.


              • 4. Re: Stats issue
                Mark Spritzler Apprentice

                 

                "scott.stark@jboss.org" wrote:
                "bytor99999" wrote:

                But did something change in the api for ManagementView?
                calling ManagementView.getTemplate(String templateName) is giving me a NoSuchMethodError.

                No, should not have. I did not make any api changes in the ProfileServiceUnitTestCase. My current trunk workspace is a mess, so I'll rebuild trunk on another box to see if the ProfileServiceUnitTestCase is working as expected there. Should only be 2 errors related to the generic connection factory deployments.


                I svn'd up and the ManagementViewImpl class still has getTemplate method in it. Hmm, it compiles for me too.

                Now is it possible the String name for a template changed for local TX Datasource?

                Weird.

                thanks

                • 5. Re: Stats issue
                  Mark Spritzler Apprentice

                  It might be a red herring. In the console log it shows a different exception, that I think is a call on my end that I need to change now.

                  • 6. Re: Stats issue
                    Mark Spritzler Apprentice

                     

                    "bytor99999" wrote:
                    It might be a red herring. In the console log it shows a different exception, that I think is a call on my end that I need to change now.


                    No, that wasn't it, still get

                    java.lang.NoSuchMethodError: org.jboss.deployers.spi.management.ManagementView.getTemplate(Ljava/lang/String;)Lorg/jboss/deployers/spi/management/DeploymentTemplateInfo; at org.rhq.plugins.jbossas5.ProfileJBossServerComponent.createResource(ProfileJBossServerComponent.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.rhq.core.pc.inventory.ResourceContainer$LockedFacetInvocationHandler.invoke(ResourceContainer.java:248) at $Proxy178.createResource(Unknown Source) at org.rhq.core.pc.inventory.CreateResourceRunner.call(CreateResourceRunner.java:107) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595)

                    In this line in our code

                    deploymentTemplateInfo = profileView.getTemplate(templateName);

                    I can't even step into that method, and I have a module in my IDE that has that code to step into.

                    Thanks



                    • 7. Re: Stats issue
                      Scott Stark Master

                      Oh, ok. I thought that change was made a few revisions ago, but perhaps not. The issue was there were duplicate DeploymentTemplateInfo interfaces. It needs to be coming from the jboss-managed project, so org.jboss.managed.api.DeploymentTemplateInfo is the correct class.

                      There is no org.jboss.deployers.spi.management.DeploymentTemplateInfo any longer, so the return value of getTemplate has changed.