Bug 1126779 - Name collision between Process variable and Script Task variable
Summary: Name collision between Process variable and Script Task variable
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Documentation
Version: 6.0.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 6.2.0
Assignee: brms-docs@redhat.com
QA Contact: Lukáš Petrovický
Dawn Eisner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-05 09:14 UTC by Anton Giertli
Modified: 2020-03-27 19:40 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:40:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Anton Giertli 2014-08-05 09:14:33 UTC
Description of problem:

Variable with the same name as Process Variable can't be used in the Script Task.

Version-Release number of selected component (if applicable):
 bpm 6.0.2

How reproducible:
always

Steps to Reproduce:
1. Create new process, start-->script-->end
2. Create process variable person:String
3. Add following code in the script task:

String person = "abc";
kcontext.getKieRuntime().insert(person);

4. Save the process

Actual results:

If script task includes variable with the same name as one of the process variable,following exception is displayed and process can't be saved:

"Process Compilation error Duplicate local variable person"
Expected results:

Script Task has it's own variable scope which should not interfere with any of the 'external' variables definition. The above process definition should get compiled without any issues.


Additional info:
Issue can be solved by renaming one of the variable.

Comment 2 Kris Verlaenen 2014-08-18 08:26:16 UTC
This is the result of auto-injecting variables into scripts.  The script has its own variable scope, but since known variables are auto-injected, this will still introduce a conflict if you try to redefine the same variable name locally.  Not sure what the solution should be for this, as auto-injection of variables is an important feature, maybe better validation / error messages?

Comment 3 Maciej Swiderski 2014-09-01 17:29:38 UTC
Took quick look at what we have there and not sure we can do much improvements there. In my opinion we already provide valuable and meaningful error message when same name is used for local variable within script as for process variable. 
Introducing variable scope for script task won't change much unless we start doing variable mapping to other names for process variables. That will make life of a user much more difficult while working with scripts.

To sum up, I would vote for keeping it as is now and document that local variables cannot be names same way as process variables. There is a contextual help with ctrl+z to suggest process variables so it's easy to know what names are already taken.

Opinions?

Comment 4 Jiri Svitak 2014-09-02 09:04:37 UTC
Hello Maciej,
Your comment makes sense to me. I find the current behavior satisfactory and the requested change would cause worse user experience.
However I was not aware of Ctrl+z option, so I would suggest to close this bugzilla and probably file a new documentation bugzilla to update docs if there is a missing/incomplete description of this topic.

Comment 5 Kris Verlaenen 2014-11-25 23:52:04 UTC
Making this a documentation issue, see comment 3

Comment 9 Kris Verlaenen 2015-05-07 20:13:21 UTC
Variables do exist in their own scopes.  However, to avoid users having to look up variables etc., we will automatically inject (a copy of) known variables into the local scope, so they can easily be accessed.  This however means that you then can't define another local variable in the script with the same name.


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