On 30 November 2011 15:34, henrib <hen...@apache.org> wrote:
> About Test org.apache.commons.jexl2.UnifiedJEXLTest that failed, the code had
> bugs and was fixed.
> 1187458 Fri Oct 21 18:40:17 CEST 2011 henrib
> Added getVariables method (similar to JexlEngine) to extract all references
> variables from an UJEXL expression;
> Fixed issue where preparing a deferred expression would not always return an
> immediate expression;
> Updated test accordingly
Yes, but I'm not clear why the asString method changes output.
Was: Dear #{p} Doe; Now: Dear ${p} Doe;
Is that essential?
If so, what happens to ${p} input?
> About Test org.apache.commons.jexl2.IssuesTest FAILED - test73, some changes
> were made on error reporting and the 2.0.1 test was weakly checking the
> exception message:
> 1182807 Thu Oct 13 14:38:05 CEST 2011 henrib
> Added JexlException.Property exception to more accurately report errors due
> to unknown or inaccessible object properties
Yes, found that out myself; not a real problem
> About Test org.apache.commons.jexl2.ArithmeticTest FAILED, these fail
> against 2.1 due to JEXL-83 fix which needs a JexlThreadedArithmetic instance
> to change the strict mode through the engine.
However, this is a big behavioural change, which does not seem to be
explicitly mentioned in the release notes.
The call to setLenient() appears to work, but no longer has the same affect.
(Does it have any affect?)
Would it not be possible to keep the old behaviour?
Or if not, perhaps the code should throw UsupportedOperationException
if the user request cannot be granted (e.g. cannot change setting).
It looks like the additional methods in the Script interface are
unlikely to cause binary compatibility problems in normal use - though
of course they will cause source incompatibility if any code tries to
implement the interface, and introspection will reveal differences.
If we can get the other compatibility issues fixed, I think it might
be OK to release 2.1 with changes to the Script interface.
Many users won't notice the difference, and if a problem is found, it
would be useful to know for an eventual 3.0 release.
However, perhaps it should be released as BETA initially.
Let's have that discussion when the other incompatibilities are sorted out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
