Created attachment 595288 [details] Sample ESB deployment Description of problem: I am not able to create ESB deployment child Version-Release number of selected component (if applicable): JON 3.1.0.GA SOA-P 4.3.0.GA_CP5 How reproducible:always Steps to Reproduce: 1.import SOA-P server running in default profile 2.you must uncomment admin=admin line in soa-users.properties 3.create new deployment under ESB subsystem Actual results: child creation fails UI error: java.lang.NoSuchMethodError:org.rhq.plugins.jbossas.util.FileContentDelegate.createContent(Lorg/rhq/core/domain/content/PackageDetails;Ljava/io/InputStream;ZZ)V Agent error: 2012-06-28 10:05:41,370 ERROR [ResourceContainer.invoker.nonDaemon-1] (org.rhq.plugins.jmx.MBeanResourceComponent)- Error deploying application for report: CreateResourceReport: ResourceType=[{JBossESB}Deployment], ResourceKey=[null] java.lang.NoSuchMethodError: org.rhq.plugins.jbossas.util.FileContentDelegate.createContent(Lorg/rhq/core/domain/content/PackageDetails;Ljava/io/InputStream;ZZ)V at org.jbosson.plugins.jbossesb.ESBComponent.esbCreate(ESBComponent.java:91) at org.jbosson.plugins.jbossesb.ESBComponent.createResource(ESBComponent.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Expected results:deployment is created Additional info:
Created attachment 595290 [details] Error while ESB deployment
Created attachment 595292 [details] RHQ server/agent log files
*** Bug 841939 has been marked as a duplicate of this bug. ***
This looks like a method is missing in JON - java.lang.NoSuchMethodError:org.rhq.plugins.jbossas.util.FileContentDelegate.createContent(Lorg/rhq/core/domain/content/PackageDetails;Ljava/io/InputStream;ZZ)V Was this removed? Can is be added back?
there is a lot of fragility in the way this plugin is written .... that makes it dependent on more than the public plugin API ... but also on the implementation in core JON we test that the plugin API does not change unexpectedly and cause breakage. however, we don't test that rhq/core remains constant from build to build
is this the same sort of regression as this : http://pad.engineering.redhat.com/RCA-828191-828464 we should do something about this ... to prevent this sort of regression from happening over and over ....
The method referenced in comment #4 does not have that particular signature since 02/12/2009. I would be more than glad to add it back but I need to see the calling source code to understand what that last parameter is. It could be related to unzipping or backing up the deployment. Change from 3 to 4 arguments: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/modules/plugins/jboss-as/src/main/java/org/rhq/plugins/jbossas/util/FileContentDelegate.java?id=f19c1987bfb9c54ea3a5c2f37c3c4b8ed06a5cf7 Full file history: http://git.fedorahosted.org/cgit/rhq/rhq.git/log/modules/plugins/jboss-as/src/main/java/org/rhq/plugins/jbossas/util/FileContentDelegate.java Could you please post a link with the source for org.jbosson.plugins.jbossesb.ESBComponent class of the plugin?
After additional investigation (with the help of the plugin development team), I discovered that SOA-P plugin is using a somewhat newer version of the FileContentDelegate#createContent method that takes 4 parameters but the second one is an InputStream rather than a File (as seen in the current version). The method referenced in the SOA-P plugin was removed from the code (and replaced with a different version) on 05/25/2010. Commit for the change from 4 arguments (the version matching SOA-P plugin) to 5 arguments: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/modules/plugins/jboss-as/src/main/java/org/rhq/plugins/jbossas/util/FileContentDelegate.java?id=5db6f43e511700a4de58dace6461a81b308ecc70 The code fix is somewhat simple, just add back the method expected by the plugin and compute the SHA256 for exploded content based on the files unzipped on disk. This new method will be deprecated because it does not follow the typical SHA256 computation procedure for exploded content that relies on calculating it based on the zipped version of the file even for exploded content. It is highly encouraged to migrate in future versions of the SOA-P plugin to the new method signature.
release/jon3.1.x branch commit: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.1.x&id=288295bd2dc0d244f98fb16dcb11c206e10bc8d8
Moving to ON_QA since JON 3.1.1 ER2 build is availble - https://brewweb.devel.redhat.com/buildinfo?buildID=228250
SOA-P 4.3.0.GA_CP5 and JON 3.1.1.ER2: https://brewweb.devel.redhat.com/buildinfo?buildID=228250 There is not an exception in the agent log anymore, but the ESB archive is not in the SOA-P and JON deployed.
Hi Pavel Can you include DEBUG logs from the JON agent and server when you try to deploy the archive. Thanks
Please test again with ER3 and attach logs in case it does not work as expected. Also, if there are no errors but the new resource does not show up in the amount of time you expect, please run a manual forced discovery (discovery -f) from the agent prompt. I do not have all the details regarding how SOA-P plugin works but I think it discovers all deployed resources as services. The service discovery runs once every 24 hours and it is possible that the resource does not get discovered for another 24 hours. If the original test instance is still around and has been running for more than 24 hours, you could try to see if the resource has been discovered there.
Pavel will restest with JON 3.1.1 CR1
JON 3.1.1.CR1: https://brewweb.devel.redhat.com/buildinfo?buildID=231258 did not fix the bug for SOA-P 4.3.0. Adding JON debug logs.
Created attachment 609652 [details] JON 3.1.1.CR1 DEBUG logs for SOA-P 4.3.0
Please use comment #13 to augment the replication steps from the bug description. That is, after you run all the replication from the bug description, please wait 10 minutes, run discovery manually, wait another 10 minutes, and then check to see if the SOA-P resource was discovered. The 10 minutes wait between tasks is a good practice given the fact that most of the work is done by the content system. The fact that there are no errors in the logs is an indication that deployment and resource creation succeeded.
Tested this with 3.1.1 CR1 and I didn't see any problems - and I saw the ESB archive both within the SOA-P server and displayed within JON.
Retested with JON 3.1.1.CR1 and one running instance of soa-4.3.0.GA_CP05. The Sample ESB deployment displayed in JON in 10 minutes. I will have to investigate JON 3.1.1.CR1 with soa-4.3.0.GA_CP05 and SOA-P 5.2.0/5.3.0 running at the same machine too - previously tested configuration.
JON 3.1.1.CR2: https://brewweb.devel.redhat.com/buildinfo?buildID=232185 fixes the bug for SOA-P 4.3.