Bug 853466

This issue is fixable in the case of an empty String, but not for a null value. Indeed the expected output in case of a null value is totally arbitrary. You wrote you'd expect:

$v2 : Value( name == "" )

while my personal expectation is:

$v2 : Value( name == null )

and actually the template engine would generate:

$v2 : Value( name == "null" )

Even worse what should happen in case of a primitive type field? Suppose that your Value object has a field named 'position' of type int and you have a template like this:

$v1 : Value( position == @{valueOne} )

Also suppose that you have no value for the parameter "valueOne" (by the way in a Java Map the complete absence of a key is not distinguishable by the presence of that key with a null value). What is your expected output in this case? Of course both: 

$v1 : Value( position == null )

and 

$v1 : Value( position == "" )

will have no sense. Probably the only reasonable expectation in this case could be something like:

$v1 : Value( position == 0 )

but to achieve this I should know that 'position' is of type int and it is not possible to obtain this information at template generation time.

If you want that I fix this issue in case of an empty String just let me know, but my advice is to avoid to do even this, because I am afraid that in some cases you could end up with a generated DRL like this:

$v1 : Value( position == )

I appreciate your input on this, I filed this bug on behalf of a client who ran into this issue. From what I understand the situation that they discovered it in was when a null value was passed into the map but the key was present (ie they were passing in a map with k:v pair someParam:null).

I did some diving to look at the issue myself and I realized the complexity of dealing with unquoting a null value when it is added in and I had not considered the situation you brought up about missing keys and/or primitive values.

With that being said, I am not sure what the expected behavior in the situations  you mentioned would be. Fixing for just an empty string would not necessarily solve the client's issue since they discovered it when passing in null. Is it indeed even a bug or is this behavior expected? I just thought it was strange that the whole line disappeared in those specific instances.

As far as it stands right now I have simply introduced some code in the client's application to work around the issue when it arises. I'd have to defer to you as to whether or not you believe this issue is high profile enough to fix.

The only way I see to fix this problem without ambiguities is to provide more information on the template's header. For example we could have something like:

template header
valueOne   : String
valueTwo   : Integer
valueThree : int

so in this way I could know that valueOne and valueTwo are nullable while I should anyway set something in valueThree in order to avoid a NPE (probably 0 even if this is totally arbitrary).

Even better it would be to give the possibility to optionally provide a default value like in:

template header
valueOne   default ""
valueTwo   default null
valueThree default 5

In this way I'd have a well defined and not ambiguous value to be used when I have no value for a given variable (once again having no value or explicitly set a null value for a given key in a map is totally undistinguishable under a Java point of view).

I discussed this with Mario today and I think there is a design issue here. A text templating engine is supposed to act as a text templating engine and should not try to step out of it's boundaries, under the risk of creating problems like the ones seen here.

Here we have a mix of decision table logic embedded into the templating engine and that is causing the problems. The decision table logic should stay in the decision table module and the template should not care about parameter types.

Lets take a step back and try to fix the larger issue. Discussing this with the team.

There is no conclusion in the discussion if this is a bug or not (the problem is still there).

I further discuss this issue with Edson and we both gave a deeper look at the code involved with it.

We think that to ask the engine to differentiate between the absence of a value and a value explicitly set to null is a good request, but as explained in the
former comments, it requires proper discussion and design decisions. It is not so much a bug fix as it is an enhancement to the original design. 

Unfortunately, the code implementing this feature is part of a community contribution and doesn't seem to be robust and flexible enough to allow the necessary changes easily and without risks. Modifying its behaviour would actually require rewriting about 20%-30% of it, so we don't think it is something that qualifies for a bug fix release.

Our recommendation is to not fix the ticket for 5.3.1 and instead have this as a feature request for future major releases.

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.