Bug 1278596 - Signal subprocess is never invoked
Signal subprocess is never invoked
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
high Severity high
: CR2
: 6.2.0
Assigned To: Maciej Swiderski
Ivo Bek
Depends On:
Blocks: 1278598 1280525
  Show dependency treegraph
Reported: 2015-11-05 17:36 EST by William Antônio
Modified: 2015-12-01 07:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1278598 1280525 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A reproducer process and a possible diff with the fix for this issue (3.60 KB, application/zip)
2015-11-05 17:36 EST, William Antônio
no flags Details

  None (edit)
Description William Antônio 2015-11-05 17:36:13 EST
Created attachment 1090408 [details]
A reproducer process and a possible diff with the fix for this issue

Description of problem:

A signal subprocess in a process is not invoked. Signals send to the process aimed to invoke the subprocess are ignored.

Version-Release number of selected component (if applicable):
Update 3

How reproducible:

Steps to Reproduce:
1. Create a process and add a signal subprocess to it;
2. Inside the subprocess, add the signal itself, a script task to print some message to indicate that the subprocess was invoked and then an end event;
3. Use a script task to signal the process in the main process flow;

Actual results:
The process is finished without entering the subprocess;

Expected results:
It should invoke th subprocess.

Additional info:

Between update 2 and 3, the engine was updated to invoke process using the signal name, instead the id. The editor still looks for a signal with a given ID instead looking for its name. Further local tests using the branch 6.2.x seems to have solved the issue. 

Attached you can find a simple process that can be used to reproduce this issue and also the diff file of the changes I made locally.
Comment 1 Tihomir Surdilovic 2015-11-10 10:44:59 EST
Not sure why you need custom diff when we have the commit on github https://github.com/droolsjbpm/jbpm-designer/commit/feb4a2a2b71a7f0be09ffe4a059925ce9b23cf42

also if it is not possible to patch the actual engine parser part (because lookup by id is the correct way to go anyways rather than the signal name) then i would even rather add backwards compatibility code into master and propagate to branches than use some custom diff. wdyt?
Comment 2 William Antônio 2015-11-11 19:51:26 EST
Hello Tihomir,

Thanks for your feedback on this BZ. Further discussion showed that this should be solved at the jbpm API level, hence I changing the component of this BZ to be jbpm core instead the designer.
Comment 5 Maciej Swiderski 2015-11-25 08:34:07 EST
moving to modified as it was fixed on master/6.3.x before, to double check all is good let's retest instead of closing
Comment 6 Ivo Bek 2015-12-01 07:23:33 EST
Verified in BPM Suite 6.2.0.CR2

Output of the reproducer: [see the signal is caught]

13:20:12,349 INFO  [stdout] (http-localhost.localdomain/ Starting proc
13:20:12,353 INFO  [stdout] (http-localhost.localdomain/ sending signal
13:20:12,360 INFO  [stdout] (http-localhost.localdomain/ CATCHING SIGNAL

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