EL1072E when evaluating compiled null-safe expression [SPR-16489]

[spring-projects-issues]

Juan Domínguez González opened SPR-16489 and commented

When evaluating an expression involving a null-safe access to a field it fails when using the bytecode compiled expression.

Can be reproduced using the attached test case.

The problem could reside in class PropertyOrFieldReference. Its readProperty method (used when evaluating in interpreted mode), takes into account the nullSafe field, however its generateCode method doesn't use the nullSafe field. It seems that generateCode method could append bytecodes for null-checking the context object, as in the interpreted version.

---

Affects: 4.3.14

Attachments:

• NullSafeTestBean.java (2.06 kB)

Referenced from: commits 1db7e02, d3acf45

Backported to: 4.3.16

[spring-projects-issues]

Andy Clement commented

I think Juan is right about where the changes are needed but as usual when issues arise with the expression compilation I like to explore all related corner cases. This also needs addressing for nullsafe method references, with a similar fix. But the fix isn't just a couple of lines because we have to take into account that the method/property/field may result in a primitive and in that case we have to do a few extra gymnastics to handle the nullsafe case. We want it to give the same result as an interpreted case.

[spring-projects-issues]

Juan Domínguez González commented

Just a suggestion: since a null-check can be expressed with a ternary operator, I'd seek "inspiration" in class org.springframework.expression.spel.ast.Ternary.

Its generateCode method also takes into account primitives; I don't know if its handling is suitable for the nullsafe case.

[spring-projects-issues]

Andy Clement commented

Pushed changes for this to work, with new testcases for the property and method cases.

[spring-projects-issues]

Juergen Hoeller commented

Thanks, Andy - I'll mark this as resolved then...

[spring-projects-issues]

Juan Domínguez González commented

Hi.

I've downloaded version 4.3.15 of spring-expression.

Seems that the fix for this bug has'n been included in that version. Should'n have been included?

[spring-projects-issues]

Andy Clement commented

It was fixed in 5.0 line, not sure the change was pulled across to the 4.3.x line though, looks like we missed doing that.

[spring-projects-issues]

Andy Clement commented

Backported to 4.3.x branch for 4.3.16 inclusion.

[spring-projects-issues]

Juan Domínguez González commented

I've seen that version 4.3.16 was released just yesterday. Didn't expect it so soon.

Thanks!

[spring-projects-issues]

Juergen Hoeller commented

Neither did we... but since we missed another backport as well, unfortunately part of a CVE resolution, we escalated the release.

[spring-projects-issues]

Juan Domínguez González commented

We've been lucky, then. Thanks, anyway!