Bug 846785

Summary: RHQ: Unable to create ESB deployment manually for SOA-P 4.3.0
Product: [Other] RHQ Project Reporter: Stefan Negrea <snegrea>
Component: ContentAssignee: Stefan Negrea <snegrea>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: urgent Docs Contact:
Priority: high    
Version: 4.4CC: hrupp, ldimaggi, mvecera, tcunning
Target Milestone: ---   
Target Release: RHQ 4.5.0   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 836527 Environment:
Last Closed: 2013-09-01 06:08:15 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 836527    
Bug Blocks: 841939    
Attachments:
Description Flags
JON 3.1.1.CR1 DEBUG logs none

Description Stefan Negrea 2012-08-08 12:58:53 EDT
+++ This bug was initially created as a clone of Bug #836527 +++

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:

--- Additional comment from pkralik@redhat.com on 2012-06-29 08:18:51 EDT ---

Created attachment 595290 [details]
Error while ESB deployment

--- Additional comment from pkralik@redhat.com on 2012-06-29 08:21:08 EDT ---

Created attachment 595292 [details]
RHQ server/agent log files

--- Additional comment from ldimaggi@redhat.com on 2012-07-20 12:12:32 EDT ---

*** Bug 841939 has been marked as a duplicate of this bug. ***

--- Additional comment from ldimaggi@redhat.com on 2012-07-20 12:14:51 EDT ---

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?

--- Additional comment from mfoley@redhat.com on 2012-07-20 13:11:16 EDT ---

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

--- Additional comment from mfoley@redhat.com on 2012-07-20 13:22:57 EDT ---

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 ....

--- Additional comment from snegrea@redhat.com on 2012-08-07 18:13:12 EDT ---

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?

--- Additional comment from snegrea@redhat.com on 2012-08-08 12:54:49 EDT ---

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.
Comment 2 Pavel Kralik 2012-08-22 09:22:58 EDT
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.
Comment 3 Pavel Kralik 2012-09-04 06:14:04 EDT
Created attachment 609616 [details]
JON 3.1.1.CR1 DEBUG logs

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.
Comment 4 Stefan Negrea 2012-09-04 14:23:30 EDT
This bug is applicable to RHQ only. Please retest with the latest version of RHQ to verify that the issue has been resolved.

Also, please augment the replication steps from the bug description with a manual discovery. 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.
Comment 5 tcunning 2012-09-04 14:26:38 EDT
From what I can see using 3.1.1 CR1, this does work.     I see the ESB archive in both SOA-P 4.3.0 and in JON after hitting refresh in the child resources a few times.
Comment 6 Heiko W. Rupp 2013-09-01 06:08:15 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.