-
15. Re: JBPM 4.3 EL cannot read process property with null value
sebastian.s Feb 1, 2010 1:21 AM (in response to kukeltje)I fully agree that the behaviour should be identical in the second case where the variable exists and is null. I am not sure about the third one but from a first sight I would say treating a variable which does not exist as a null value seems strange to me. Is there anything wrong about throwing an exception telling the variable does not exist in this case? -
16. Re: JBPM 4.3 EL cannot read process property with null value
kukeltje Feb 1, 2010 4:44 AM (in response to sebastian.s)sebastian.s wrote:
Breaking backwards compatibility maybe? Otherwise, I don't think there is. I'll see how the testcases react when this behaviour is introduced (just switching one method in my local codebase)
-
17. Re: JBPM 4.3 EL cannot read process property with null value
jsobolewski Feb 1, 2010 5:21 AM (in response to kukeltje)kukeltje wrote:
I created a little patch that solves this (all unit tests still are green). If you file a jira issue about this, I'll attach the patch to it that make EL return null if the variable exists but has a value of null. It does make the last case identical (not it should, and if it should, shoud it fail? or should EL also return null?) Ask that in the Jira issue to.
Link to JIRA issue: https://jira.jboss.org/jira/browse/JBPM-2777
I think that in last case Java and EL should behave in the same way... instinct says that Java should throw exception... but like I said before - I'm new to JBPM.
-
18. Re: JBPM 4.3 EL cannot read process property with null value
kukeltje Feb 1, 2010 6:47 AM (in response to jsobolewski)My instinct says the same, but that breaks backwards compatibility -
19. Re: JBPM 4.3 EL cannot read process property with null value
jsobolewski Feb 1, 2010 7:01 AM (in response to kukeltje)Adding 2 configuration parameters that say how engine should treat non-existing variables ([null / throw] with default null for Java and throw for EL) would solve backward compatibility issue and allow new users to adjust engine to their needs. -
20. Re: JBPM 4.3 EL cannot read process property with null value
kukeltje Feb 1, 2010 7:20 AM (in response to jsobolewski)Sure, internallly that is now how I patch it, using an additional param to a method. I'm just *not* going to make this configurable and all... Unless you want to write all additional unittests, integration tests, documentation etc.... -
21. Re: JBPM 4.3 EL cannot read process property with null value
kukeltje Feb 1, 2010 7:22 AM (in response to kukeltje)Besides the time it would take... So I'd take the difference between EL and Java for none existent variables for granted and write a small line about it in the docs -
22. Re: JBPM 4.3 EL cannot read process property with null value
jsobolewski Feb 1, 2010 8:18 AM (in response to kukeltje)Actually third case with non-existing variables isn't that critical... If someone asks for non-existing variable in EL he gets exception and should do something about it (initiate it with some value or null). Returning null in Java is not a problem but it should be mentioned in javadoc... Now javadoc on ExecutionService.getVariable says only "retrieves a variable".
It's the second case that causes problems. Like in my test case where Java method can have null value parameters and I can't pass null variable from EL.
For now I use simple workaround - I created resolver class and set it in process as "resolver" variable. Now I can use it in JPDL to retrieve variables that I know can be null:
<object expr="#{resolver}" method="get">
<arg><string value="var_name_here" /></arg>
</object>
Resolver's get method just returns executionService.getVariable
-
23. Re: JBPM 4.3 EL cannot read process property with null value
kukeltje Feb 1, 2010 8:41 AM (in response to jsobolewski)Then my fix will help you. I'll attach it to the jira issue tonight. -
24. Re: JBPM 4.3 EL cannot read process property with null value
sebastian.s Feb 1, 2010 9:40 AM (in response to kukeltje)Ronald, so you don't want to change the behaviour to preserve backward compatibility? But when this was orginally implemented making a difference wasn't intented, right?