Red Hat Bugzilla – Bug 1249658
Input parameters of throw event affect process variables
Last modified: 2016-01-19 01:58:29 EST
Created attachment 1058775 [details]
input parameters for escalation event
Description of problem:
If user adds EscalationThrowEvent to canvas, he can specify input parameters for this event. Input parameters are represented by two parts: From and To.
In part From user specifies some process variable, which will be used for initialization.
In part To user specifies new (inner) variable, which will be initialized by process variable defined in part From.
Problem is with specification of data type for variable in part To.
Version-Release number of selected component (if applicable):
bpmn2 modeler 1.1.3.Final
Steps to Reproduce:
1. Create any process. Need not to be valid.
2. Define variable varOne:Object in process
3. Define escalation customEscalation:java.lang.RuntimeException in process
4. Add throw escalation event to process
5. Double click on event from previous step
6. Fill shown popup form like in the attachment
7. Save process
Data type of variable varOne is changed to String
Data type of variable varOne is still Object
Sorry, this was me trying to be too smart ;)
The idea behind this was to maintain data type consistency between data inputs/outputs and their mapped data objects (i.e. "process variables").
Imagine a scenario where a process variable (e.g. "applicant") is defined as some arbitrary structure (e.g. "Person") and I then try to map that into an Activity's DataInput that has a data type of "Integer", this will likely cause a runtime Class Cast Exception.
Data type consistency errors should probably be reported during validation, but for now (just to get past this bug) I will disable this data type coercion. I'm thinking of adding a user preference to the BPMN2 Editor Behavior page to turn this feature on/off, and augment that with validation.
See eclipse Bug 481768 - Allow user to enable/disable data type coercion of DataInputs/Outputs.
Verified on jbdsis-8.0.5, BPMN2 Modeler 1.1.4.Final