Bug 846785 - RHQ: Unable to create ESB deployment manually for SOA-P 4.3.0
RHQ: Unable to create ESB deployment manually for SOA-P 4.3.0
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
i386 Linux
high Severity urgent (vote)
: ---
: RHQ 4.5.0
Assigned To: Stefan Negrea
Mike Foley
Depends On: 836527
Blocks: 841939
  Show dependency treegraph
Reported: 2012-08-08 12:58 EDT by Stefan Negrea
Modified: 2013-09-01 06:08 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 836527
Last Closed: 2013-09-01 06:08:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
JON 3.1.1.CR1 DEBUG logs (372.52 KB, application/x-gzip)
2012-09-04 06:14 EDT, Pavel Kralik
no flags Details

  None (edit)
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:


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 - 


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 :


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:

Full file history:

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:

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:

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

Note You need to log in before you can comment on or make changes to this bug.