[tbee]

"kukeltje" wrote:

I assume more people do this.

If I find the time (remember, I do not work for JBoss/RH and only do this in my free time) I'll try to make a unit test without scripting and see what happens then.

I know and it is highly appriciated. Personally I also contribute at times to open source projects, but at the moment I'm not feet-solid on jBPM yet. Still feeling my way around.

But if this is indeed not working, I assume there are JBoss developers interested in such a IMHO serious bug. since JBPM is used by a lot of also commercial applications.

[kukeltje]

Well... Since I think not many people use it this way, I'd not qualify the 'bug' as serious. The risk is that if this is changed, some other things fall over. Things that might be more used

[tbee]

"kukeltje" wrote:
Well... Since I think not many people use it this way, I'd not qualify the 'bug' as serious. The risk is that if this is changed, some other things fall over. Things that might be more used

I do not agree: the documentation is very specific about that variables have contexts and that value can be assigned to tokens or the roottoken per default. The documentation is based on the concept / specification of jBMP.

If the actual code behaves differently from its specification, I would consider that a major bug.

[mputz]

There is a test case that covers this scenario:
http://fisheye.jboss.org/browse/JBPM/jbpm.3/jpdl/jar/src/test/java/org/jbpm/context/exe/VariableScopingTest.java?r=1.1

Looking at testScopeOverriding(), this works properly if the createVariable(String name, Object value, Token token) is used.

The results are different if setVariable(String name, Object value, Token token) is used, which is also documented in the javadocs:

/**
 * sets a variable. If a variable exists in the scope given by the token, that
 * variable is updated. Otherwise, the variable is created on the root token
 * (=process instance scope).
 */
 public void setVariable(String name, Object value, Token token) {

In order to use setVariable on different tokens, the variables have to be created first with createVariable, otherwise they will all end up being referenced by the root token.

[tbee]

"mputz" wrote:

/**
 * sets a variable. If a variable exists in the scope given by the token, that
 * variable is updated. Otherwise, the variable is created on the root token
 * (=process instance scope).
 */
 public void setVariable(String name, Object value, Token token) {

In order to use setVariable on different tokens, the variables have to be created first with createVariable, otherwise they will all end up being referenced by the root token.

Create variable works indeed. It also works to update an already existing variable. So my problem is solved, thank you!

However, IMHO, I find the behavior strange:
- Even though a token is explicitely provided, setVariable elects to ignore it. Rather throw an exception stating the variable does not exist, but do not ignore that parameter; there is a two-parameter method for a more "agile" behavior.
- createVariable can be used to create and update a variable. However "create" is much more specific about what is going to happen than "set", and I had not expected it to update also.

Personally I find the following behavior more logical:
- createVariable: create only but not update, exception if variable exists
- updateVariable: update only, exception if not exist
- setVariable: create if not exist, otherwise update

Thanks!

Tom

[kukeltje]

Martin, Tom,

That is precisely the reason I was kind of amazed and thought there was some strange behaviour in the source. I was adapting the unit test locally to match this more expected behaviour. but changing it might create a problem for other users that 'use' the current behaviour.

Tom, ok sorry I did not make myself clear enough, the bug could be major major, but with low priority then since not a lot of users (you seem to be the only one) encounter it) The impact could even be major for the reason I mentioned before. Could you create a jira issue? I'll change the priority then ;-)

[tbee]

"kukeltje" wrote:
Could you create a jira issue? I'll change the priority then ;-)

https://jira.jboss.org/jira/browse/JBPM-1889

I think I added a nice suggestion how this can cleanly be resolved: add a setVariable method to token, which behaves as the createVariable on ContextInstance.