Bug 57309

Summary: Custom type conversion sometimes bypassed
Product: Tomcat 8 Reporter: Mark Thomas <markt>
Component: ELAssignee: Tomcat Developers Mailing List <dev>
Severity: normal CC: mauromol
Priority: P2    
Version: 8.0.x-trunk   
Target Milestone: ----   
Hardware: All   
OS: All   

Description Mark Thomas 2014-12-04 14:14:44 UTC
As per section 1.23 of the EL spec, the current ELResolver should be given an opportunity to apply custom type conversion before falling back on the standard rules.

See also http://tomcat.markmail.org/thread/utk3nsn4aakjl4gj
Comment 1 Mark Thomas 2014-12-04 15:07:40 UTC
Proposed fix:

I plan to commit this to trunk and back-port to 8.0.x once svn returns to read-write.
Comment 2 Mark Thomas 2014-12-05 17:39:18 UTC
This has been fixed in trunk and 8.0.x (for 8.0.16 onwards).
Comment 3 Konstantin Kolinko 2014-12-06 16:43:04 UTC
Reviewing r1643367
Reviewing ELSupport.compare(Object, Object) and coerceToNumber(ctx, Object, BigDecimal.class) calls there:

1. The first branch in compare() method:
        if (isBigDecimalOp(obj0, obj1)) {
            BigDecimal bd0 = (BigDecimal) coerceToNumber(ctx, obj0, BigDecimal.class);
            BigDecimal bd1 = (BigDecimal) coerceToNumber(ctx, obj1, BigDecimal.class);
            return bd0.compareTo(bd1);

In this branch isBigDecimalOp check returned true, so one of operands is already a BigDecimal.

QUESTION: Does coerceToNumber() need to call ELResolver to convert it? Can it skip conversion if the object is already of the expected type.

2. Minor
                if (ctx.isPropertyResolved()) {
                    return (Number) result;
It could be type.cast(result).