On 30 November 2011 17:11, henrib <hen...@apache.org> wrote:
>
> About Was: Dear #{p} Doe; Now: Dear ${p} Doe;
> As stated, the issue was that preparing a deferred expression must always
> return an immediate (even composite) expression. When preparing "Dear #{p}
> ${name};" , the immediate ${name} will be evaluated - 'name' is the set of
> variables - and the preparation of the inner-deferred #{p} leads to another
> immediate ${p} thus the expression "Dear ${p} Doe; " - where the set of
> variables is 'p'.
> Since asString() must return the stringified form of the expression, it's
> pretty essential that this behavior remains as is which is correct.
Just to confirm: are you are saying that the previous behaviour of
asString was incorrect?
> About JEXL-83 - which is an issue you reported - and its fix which lead to
> the JexlThreadedArithmetic, the behavior is documented in the Javadoc @
> setLenient():
> * <p>This method is <em>not</em> thread safe; it should be called as an
> optional step of the JexlEngine initialization code before expression
> creation & evaluation.</p>
That's fine (but see below).
> * <p>As of 2.1, you need a JexlThreadedArithmetic instance for this
> call to also modify the JexlArithmetic
> * leniency behavior.</p>
That's the part I find problematic.
Yes, the method is not thread-safe, but under some circumstances that
was not an issue.
The method was conditionally thread-safe.
For example, creating an engine which is used in a single thread, or
even an engine which is then passed to one or more newly created
threads (and not subsequently modified). In both cases the lack of
thread-safety is not a problem with the 2.0.1 code.
> The rationale is pretty well documented in the issue itself.
> I'd vote for throwing an UnsupportedOperationException with the same message
> (or log an error if silent?) and document the change explicitly in the
> release notes.
Unfortunately this will break some applications.
The alternative (for a 2.1 release) would be to make the field
volatile. [Not sure why I did not put this in the JIRA originally].
This will be safe for use in multiple threads, with the caveat that
the behaviour is undefined if the setting is changed whilst when the
engine is busy. But that is no worse than before.
This would be sufficient for any existing use-cases, and would fix
some potential edge cases where the setting is not correctly published
to all threads.
If the user really wants to change the settings on a per-thread basis,
they they can use the new Threaded Arithmetic implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
