[jira] [Resolved] (JEXL-203) JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one

["Henri Biestro (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JEXL-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Biestro resolved JEXL-203.
--------------------------------
    Resolution: Fixed

Simplified the process; user-defined arithmetic should override 'createWithOptions(...)'
{code}
    /**
     * Creates a JexlArithmetic instance.
     * Called by options(...) method when another instance of the same class of arithmetic is required.
     * @see #options(org.apache.commons.jexl3.JexlEngine.Options)
     *
     * @param astrict     whether this arithmetic is lenient or strict
     * @param bigdContext the math context instance to use for +,-,/,*,% operations on big decimals.
     * @param bigdScale   the scale used for big decimals.
     * @return default is a new JexlArithmetic instance
     */
    protected JexlArithmetic createWithOptions(boolean astrict, MathContext bigdContext, int bigdScale) {
        return new JexlArithmetic(astrict, bigdContext, bigdScale);
    }
{code}

> JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JEXL-203
>                 URL: https://issues.apache.org/jira/browse/JEXL-203
>             Project: Commons JEXL
>          Issue Type: Bug
>            Reporter: Dmitri Blinov
>            Assignee: Henri Biestro
>             Fix For: 3.0.1
>
>
> If JexlContext implements JexlEngine.Options and it provides values for strictness, scale and MathContext that are different from what was specified during creation of JexlArithmetics, then instance of wrong JexlArithmetic class is created instead of custom class previously used. Apparently the JexlArithmetic.options() method could then be overloaded in custom class, but I don't like the idea of copying all that code from version to version, so may be more robust solution could be found to this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)