[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838517#comment-13838517 ] Ate Douma commented on SCXML-177: - Hi Woonsan, I looked into the JexlEngine silent mode and it does make a difference with regards to behavior. If (silent==false) (the default) it will throw a JexlException, which then is re-thrown by the (SCXML) JexlEvaluator as SCXMLExpressionException, which is good. If (silent==true) Jexl will only log a WARN message and return null (within its invocation context). So IMO sticking to the default silent==false for the JexlEngine should be fine, probably without need to also configure/override this through the SCXMLReader. The (strict==true) setting for JexlEngine should IMO also be preferred, as default, but has a most important caveat or consequence that undefined/null variables result in an exception. This will thus require somewhat more verbose scripting, e.g. like requiring '!empty(foo) and foo.booleanMethod' instead of more lenient 'foo and foo.booleanMethod'. Nonetheless, I'd prefer using (strict==true) for both the JexlEngine and SCXMLReader as default, and providing SCXMLReader.setLenient(boolean) method to override this. > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (VALIDATOR-325) IBAN validation not calculated correctly
[ https://issues.apache.org/jira/browse/VALIDATOR-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-325: -- Attachment: IBANValidator.java It is pretty straight forward to combine the regular expression validator with the IBAN checkdigit to create a validator that caters for all country formats. The biggest effort is defining all the regular expression formats for each country. I'm attaching an IBANValidator that does this. This needs a proper test case to verify all the formats (I've only tested it with your Belgian example). > IBAN validation not calculated correctly > > > Key: VALIDATOR-325 > URL: https://issues.apache.org/jira/browse/VALIDATOR-325 > Project: Commons Validator > Issue Type: Bug >Reporter: Wim Vleugels > Fix For: 1.4.0 Release > > Attachments: IBANValidator.java > > > When I try to validate an incorrect belgian IBAN code "BE7436302152834", than > it passes the validation without any problem although even the length of the > code is invalid. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MATH-1070) Incorrect rounding of float
[ https://issues.apache.org/jira/browse/MATH-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1070. --- Resolution: Fixed Fix Version/s: 3.3 Fixed in r1547649. According to BigDecimal.ROUND_UP, the value shall only be rounded up if the discarded fraction is non-zero. > Incorrect rounding of float > --- > > Key: MATH-1070 > URL: https://issues.apache.org/jira/browse/MATH-1070 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: Windows 7, IntelliJ IDEA 10.5.4. >Reporter: Oleksandr Muliarevych >Priority: Critical > Fix For: 3.3 > > > package org.apache.commons.math3.util > example of usage of round functions of Precision class: > Precision.round(0.0f, 2, BigDecimal.ROUND_UP) = 0.01 > Precision.round((float)0.0, 2, BigDecimal.ROUND_UP) = 0.01 > Precision.round((float) 0.0, 2) = 0.0 > Precision.round(0.0, 2, BigDecimal.ROUND_UP) = 0.0 > Seems the reason is usage of extending float to double inside round functions > and getting influence of memory trash as value. > I think, same problem will be found at usage of other round modes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MATH-1059) Use FastMath instead of Math within CM
[ https://issues.apache.org/jira/browse/MATH-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1059. --- Resolution: Fixed Fix Version/s: 3.3 Finished changes in r1547633. Remaining uses of Math: * PI * ulp * for FastMath validation and performance tests > Use FastMath instead of Math within CM > -- > > Key: MATH-1059 > URL: https://issues.apache.org/jira/browse/MATH-1059 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Thomas Neidhart > Fix For: 3.3 > > > Some code in CM still uses Math.xxx instead of the counterparts in FastMath. > This could lead to subtle differences with different jvms as could be seen in > MATH-1057. > All calls to Math shall be replaced by calls to FastMath. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-504) CompositeMap should support compositing of maps of derived types
[
https://issues.apache.org/jira/browse/COLLECTIONS-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838246#comment-13838246
]
Thomas Neidhart commented on COLLECTIONS-504:
-
Unfortunately this would only be possible for an immutable CompositeMap. If
there is a mutator defined, it would be possible that an unexpected type may
appear in a composited map, e.g.
{noformat}
Map map1 = new HashMap();
Map map2 = new HashMap();
map1.put("key1", "value1");
map2.put("key2", Integer.valueOf(1));
CompositeMap composite =
new CompositeMap(map1, map2, new
CompositeMap.MapMutator() {
public Object put(CompositeMap map,
Map[] composited, String key,
Object value) {
return composited[1].put(key, value);
}
});
composite.put("key3", Integer.valueOf(2));
for (Map.Entry entry : map1.entrySet()) {
System.out.println(entry.getValue());
}
{noformat}
will result in
{noformat}
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer
{noformat}
So I do not think that this is a good idea unless we add Immutable versions of
various collection types similar to what guava does.
> CompositeMap should support compositing of maps of derived types
>
>
> Key: COLLECTIONS-504
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-504
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.0
>Reporter: Peter Cooper Jr.
>Priority: Minor
>
> I'm attempting to composite two maps, one of which is a {{Map String>}} and the other of which is a {{Map}}. I would have
> expected that I could composite them into a {{CompositeMap}},
> but the constructors of CompositeMap expect all of the maps being composited
> to have exactly the same type arguments.
> That is, I think the constructors should take arguments of {{Map ? extends V>}} instead of what they currently have of {{Map}}, much
> like most collection methods, since there shouldn't be a problem accepting
> type arguments that are subtypes of the composite map types.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (COLLECTIONS-504) CompositeMap should support compositing of maps of derived types
Peter Cooper Jr. created COLLECTIONS-504:
Summary: CompositeMap should support compositing of maps of
derived types
Key: COLLECTIONS-504
URL: https://issues.apache.org/jira/browse/COLLECTIONS-504
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 4.0
Reporter: Peter Cooper Jr.
Priority: Minor
I'm attempting to composite two maps, one of which is a {{Map}}
and the other of which is a {{Map}}. I would have expected that
I could composite them into a {{CompositeMap}}, but the
constructors of CompositeMap expect all of the maps being composited to have
exactly the same type arguments.
That is, I think the constructors should take arguments of {{Map}} instead of what they currently have of {{Map}}, much like
most collection methods, since there shouldn't be a problem accepting type
arguments that are subtypes of the composite map types.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (SCXML-182) Support error event raising to comply the spec "3.12.2 Errors"
[
https://issues.apache.org/jira/browse/SCXML-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated SCXML-182:
-
Description:
According to the spec [1], "if a conditional expression cannot be evaluated as
a boolean value ('true' or 'false') or if its evaluation causes an error, the
SCXML Processor MUST treat the expression as if it evaluated to 'false' and
MUST place the error 'error.execution' in the internal event queue."
I couldn't find any source location caring about 'error..' events when error
occurs to comply with the specification (3.12.2 Errors). This should be
improved to comply with the spec.
[1] http://www.w3.org/TR/scxml/#ConditionalExpressions
> Support error event raising to comply the spec "3.12.2 Errors"
> --
>
> Key: SCXML-182
> URL: https://issues.apache.org/jira/browse/SCXML-182
> Project: Commons SCXML
> Issue Type: New Feature
>Reporter: Woonsan Ko
>
> According to the spec [1], "if a conditional expression cannot be evaluated
> as a boolean value ('true' or 'false') or if its evaluation causes an error,
> the SCXML Processor MUST treat the expression as if it evaluated to 'false'
> and MUST place the error 'error.execution' in the internal event queue."
> I couldn't find any source location caring about 'error..' events when error
> occurs to comply with the specification (3.12.2 Errors). This should be
> improved to comply with the spec.
> [1] http://www.w3.org/TR/scxml/#ConditionalExpressions
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-180) Prevent NPEs for possible null value returned from Evaluator.eval* methods
[
https://issues.apache.org/jira/browse/SCXML-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837938#comment-13837938
]
Woonsan Ko commented on SCXML-180:
--
According to the spec [1], "if a conditional expression cannot be evaluated as
a boolean value ('true' or 'false') or if its evaluation causes an error, the
SCXML Processor MUST treat the expression as if it evaluated to 'false' and
MUST place the error 'error.execution' in the internal event queue."
So, the current #evalCond() implementation should be improved to return false
when the evaluation result is null or non Boolean object or any exception
occurs at least.
By the way, I couldn't find any source location caring about 'error..' events
when error occurs to comply with the specification (3.12.2 Errors). That can be
a good improvement and there seems to be no jira issue for that yet. I'll
create a separate issue for that improvement.
[1] http://www.w3.org/TR/scxml/#ConditionalExpressions
> Prevent NPEs for possible null value returned from Evaluator.eval* methods
> --
>
> Key: SCXML-180
> URL: https://issues.apache.org/jira/browse/SCXML-180
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ate Douma
>Assignee: Woonsan Ko
> Fix For: 2.0
>
>
> I just encountered the following NPE:
> java.lang.NullPointerException
> at
> org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415)
> at
> org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124)
> at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256)
> at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349)
> This turned out to be caused by an transition condition (evaluated through
> Jexl) resulting in, and thus also returning, a null value.
> A quick scan through the usages of Evaluator.eval* method shows several
> locations within SCXML where it always assumes an non-null value (Boolean or
> otherwise) to be returned. All possible sources for unexpected NPEs.
> I think that for at least the Evaluator#evalCond method, which is assumed to
> return a Boolean, either an error should be catched/returned or maybe even
> assume null == Boolean.FALSE.
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (SCXML-182) Support error event raising to comply the spec "3.12.2 Errors"
Woonsan Ko created SCXML-182: Summary: Support error event raising to comply the spec "3.12.2 Errors" Key: SCXML-182 URL: https://issues.apache.org/jira/browse/SCXML-182 Project: Commons SCXML Issue Type: New Feature Reporter: Woonsan Ko -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[
https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837906#comment-13837906
]
Woonsan Ko edited comment on SCXML-177 at 12/3/13 5:10 PM:
---
Thanks for the suggestions!
I've looked up how JEXL is doing with that kind of options as an example. It
has strict/lenient option to determine whether or not it is an error to throw
an exeption, and silent option to determine whether or not it should leave
warning logs. [1]
So, I think we can add the following in SCXMLReader:
+ boolean isStrict();
+ void setStrict(boolean strict);
+ boolean isLenient();
+ void setLenient(boolean lenient); // { this.strict = !lenient; }
+ boolean isSilent();
+ void setSilent(boolean silent);
The default options can be ( !strict && !silent ), which gives warning logs by
default.
[1]
http://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl2/JexlEngine.html
(The javadoc was not precise about 'silent' option. It only determine
whether or not the exception should be logged as WARN level. It doesn't force
to throw an exception.)
was (Author: woon_san):
Thanks for the suggestions!
I've looked up how JEXL is doing with that kind of options as an example. It
has strict/lenient option to determine whether or not it is an error, and
silent option to determine whether or not it should leave warning logs. [1]
So, I think we can add the following in SCXMLReader:
+ boolean isStrict();
+ void setStrict(boolean strict);
+ boolean isLenient();
+ void setLenient(boolean lenient); // { this.strict = !lenient; }
+ boolean isSilent();
+ void setSilent(boolean silent);
The default options can be ( !strict && !silent ), which gives warning logs by
default.
[1]
http://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl2/JexlEngine.html
(The javadoc was not precise about 'silent' option. It only determine
whether or not the exception should be logged as WARN level. It doesn't force
to throw an exception.)
> Correct error/warning messages in SCXML reading to be up-to-date
>
>
> Key: SCXML-177
> URL: https://issues.apache.org/jira/browse/SCXML-177
> Project: Commons SCXML
> Issue Type: Bug
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Trivial
> Fix For: 2.0
>
>
> Some error/warning logs are outdated against the newest spec.
> For example,
> org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID
> "null" found; illegal initialstate for SCXML document
> at
> org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297)
> It should inform of 'initial', not 'initialstate' and check if it is not set.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[
https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837906#comment-13837906
]
Woonsan Ko commented on SCXML-177:
--
Thanks for the suggestions!
I've looked up how JEXL is doing with that kind of options as an example. It
has strict/lenient option to determine whether or not it is an error, and
silent option to determine whether or not it should leave warning logs. [1]
So, I think we can add the following in SCXMLReader:
+ boolean isStrict();
+ void setStrict(boolean strict);
+ boolean isLenient();
+ void setLenient(boolean lenient); // { this.strict = !lenient; }
+ boolean isSilent();
+ void setSilent(boolean silent);
The default options can be ( !strict && !silent ), which gives warning logs by
default.
[1]
http://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl2/JexlEngine.html
(The javadoc was not precise about 'silent' option. It only determine
whether or not the exception should be logged as WARN level. It doesn't force
to throw an exception.)
> Correct error/warning messages in SCXML reading to be up-to-date
>
>
> Key: SCXML-177
> URL: https://issues.apache.org/jira/browse/SCXML-177
> Project: Commons SCXML
> Issue Type: Bug
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Trivial
> Fix For: 2.0
>
>
> Some error/warning logs are outdated against the newest spec.
> For example,
> org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID
> "null" found; illegal initialstate for SCXML document
> at
> org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297)
> It should inform of 'initial', not 'initialstate' and check if it is not set.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837829#comment-13837829 ] Ate Douma commented on SCXML-177: - Ah, that makes sense, I agree for some cases it might be needed to support lenient configurations. Thanks for chiming in Rahul! > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837820#comment-13837820 ] Rahul Akolkar commented on SCXML-177: - +1 to having a strict and lenient configuration for the SCXMLReader. I suggest not changing behavior to throw a ModelException in all cases. Besides the compatibility aspect of doing this, leniency is appropriate or even desired in certain usecases involving compound namespace documents where not all parts of the document may relate to (or be generated for) the purposes of the document controller or state machine. > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837818#comment-13837818 ] Woonsan Ko commented on SCXML-177: -- Sounds like a plan! It's a good idea to have a flag to use 'strict' mode in SCXMLReader with keeping the backward compatibility. > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SCXML-181) Provide SCXML source location info when logging warnings or errors
Woonsan Ko created SCXML-181:
Summary: Provide SCXML source location info when logging warnings
or errors
Key: SCXML-181
URL: https://issues.apache.org/jira/browse/SCXML-181
Project: Commons SCXML
Issue Type: Improvement
Reporter: Woonsan Ko
Currently, SCXML model objects do not have source location information for
debugging purpose.
For this reason, if there's any error (e.g, JEXL script error), then we get the
following log:
EXPRESSION_ERROR (evalScript('
unknownObject.invoke();
'):org.apache.commons.scxml2.env.jexl.JexlEvaluator.evalScript@161![14,22]:
'unknownObject.invoke();' attempting to call method on null): Expression error
inside /hello/world
The reason is that SCXML JexlEvaluator doesn't give a source location
information to the JexlEngine for itself and so JEXL engine just tries to make
a debugging information by itself (by finding the caller class (JexlEvaluator
in this case) and its line number (161) as well as more debugging purpose
parsed JEXL node information ([14,22])).
In order to give a precise source location information of SCXML, we have to
provide that kind of information in commons-scxml when invoking JEXL Engine.
For example, JexlEvaluator#evalScript() invokes
getJexlEngine().createScript(script) currently.
If we want to give source location info, then we'd better change it to
getJexlEngine().createScript(script, JexlInfo, null), where JexlInfo contains
the debugging information.
However, the current SCXML model objects do not have source location
information at all unfortunately.
It can be a good improvement to add that kind of information in SCXML model
objects in the future.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-179) Leave more context (location) information when failing to execute JEXL scripts
[
https://issues.apache.org/jira/browse/SCXML-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837798#comment-13837798
]
Ate Douma commented on SCXML-179:
-
Sounds good Woonsan, thanks!
> Leave more context (location) information when failing to execute JEXL scripts
> --
>
> Key: SCXML-179
> URL: https://issues.apache.org/jira/browse/SCXML-179
> Project: Commons SCXML
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Minor
> Fix For: 2.0
>
>
> Currently, it doesn't give enough context (location) information in warning
> logs when there are script errors (e.g, undefined object usages) like the
> following:
> EXPRESSION_ERROR (evalScript('
> unknownObject.invoke();
>
> '):org.apache.commons.scxml2.env.jexl.JexlEvaluator.evalScript@161![14,22]:
> 'unknownObject.invoke();' attempting to call method on null):
> The line number above (161) is from JexlEvaluator, not from SCXML source.
> It would be better if it gave more information somehow about the SCXML
> location and element location, for instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837794#comment-13837794 ] Ate Douma commented on SCXML-177: - Logging as ERROR is an improvement, but shouldn't this better result in a ModelException instead (too)? IMO such a SCXML definition cannot be regarded as valid when elements are 'dropped' silently. >From this regard the SCXMLReader#reportIgnoredElement method is questionable >itself. Maybe we could/should introduce a 'strict' SCXMLReader flag, which when true (default) would fail with ModelExceptions in such cases? For backwards compatibility this 'strict' flag then could be set to false if so desired. WDYT? > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-179) Leave more context (location) information when failing to execute JEXL scripts
[
https://issues.apache.org/jira/browse/SCXML-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837791#comment-13837791
]
Woonsan Ko commented on SCXML-179:
--
Hi Ate,
The reason why JEXL prints out the debugging info like
'org.apache.commons.scxml2.env.jexl.JexlEvaluator.evalScript@161![14,22]' is
that SCXML JexlEvaluator doesn't give a source location information to the
JexlEngine for itself and so JEXL engine just tries to make a debugging
information by itself (by finding the caller class (JexlEvaluator in this case)
and its line number (161) as well as more debugging purpose parsed JEXL node
information ([14,22])).
In order to give a precise source location information of SCXML, we have to
provide that kind of information in commons-scxml when invoking JEXL Engine.
For example, JexlEvaluator#evalScript() invokes
getJexlEngine().createScript(script) currently.
If we want to give source location info, then we'd better change it to
getJexlEngine().createScript(script, JexlInfo, null), where JexlInfo contains
the debugging information.
However, the current SCXML model objects do not have source location
information at all unfortunately.
It can be a good improvement to add that kind of information in SCXML model
objects in the future.
Therefore, I wanted to stop there with the state path information for now. I'll
create a separate issue for it.
Regards,
Woonsan
> Leave more context (location) information when failing to execute JEXL scripts
> --
>
> Key: SCXML-179
> URL: https://issues.apache.org/jira/browse/SCXML-179
> Project: Commons SCXML
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Minor
> Fix For: 2.0
>
>
> Currently, it doesn't give enough context (location) information in warning
> logs when there are script errors (e.g, undefined object usages) like the
> following:
> EXPRESSION_ERROR (evalScript('
> unknownObject.invoke();
>
> '):org.apache.commons.scxml2.env.jexl.JexlEvaluator.evalScript@161![14,22]:
> 'unknownObject.invoke();' attempting to call method on null):
> The line number above (161) is from JexlEvaluator, not from SCXML source.
> It would be better if it gave more information somehow about the SCXML
> location and element location, for instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837770#comment-13837770 ] Woonsan Ko commented on SCXML-177: -- I couldn't find any statement specifying that. And I agree that it should've been logged as ERROR level. SCXMLReader invokes #reportIgnoredElement() and it leaves a warning log and invokes XMLReporter#report() in the end. The current warnings in #reportIgnoredElement() are logged when there are unexpected or invalid elements inside an SCXML element (e.g, no 'data' element inside 'datamodel'). So, I think this warning should be logged as ERROR level. In that way, users can be informed of the error more clearly. > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DBCP-407) PoolablePreparedStatement invalidated because of non cleared batch
Steeve Beroard created DBCP-407: --- Summary: PoolablePreparedStatement invalidated because of non cleared batch Key: DBCP-407 URL: https://issues.apache.org/jira/browse/DBCP-407 Project: Commons Dbcp Issue Type: Bug Reporter: Steeve Beroard Priority: Minor In PoolablePreparedStatement, passivate() method: The first thing in this method is to consider the statement as closed. But then, if a batch has been added, the clearBatch() method is called. That call is delegated to DelegatingStatement that send an SQLException because Statement is already considered as closed. Then the statement is removed from the pool cache because of this so the cache is useless. Maybe it should be better to get the innermost delegate in passivate() and then call clearBatch() on the underlying statement? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DBCP-406) Support for caching statements with autogenerated keys
[ https://issues.apache.org/jira/browse/DBCP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steeve Beroard updated DBCP-406: Attachment: patchAutoGeneratedKeys.txt > Support for caching statements with autogenerated keys > -- > > Key: DBCP-406 > URL: https://issues.apache.org/jira/browse/DBCP-406 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Steeve Beroard >Priority: Minor > Attachments: patchAutoGeneratedKeys.txt > > > I would like to submit a patch to enable caching for statement with > autogenerated keys. My original version was on version 1.3 but i did the > change for the current version in the trunk -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SCXML-180) Prevent NPEs for possible null value returned from Evaluator.eval* methods
Ate Douma created SCXML-180: --- Summary: Prevent NPEs for possible null value returned from Evaluator.eval* methods Key: SCXML-180 URL: https://issues.apache.org/jira/browse/SCXML-180 Project: Commons SCXML Issue Type: Bug Affects Versions: 2.0 Reporter: Ate Douma Fix For: 2.0 I just encountered the following NPE: java.lang.NullPointerException at org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415) at org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124) at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256) at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349) This turned out to be caused by an transition condition (evaluated through Jexl) resulting in and thus returning a null value. A quick scan through the usages of Evaluator.eval* method shows several locations within SCXML where it always assumes an non-null value (Boolean or otherwise) to be returned. All possible sources for unexpected NPEs. I think that for at least the Evaluator#evalCond method, which is assumed to return a Boolean, either an error should be catched/returned or maybe even assume null == Boolean.FALSE. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DBCP-406) Support for caching statements with autogenerated keys
Steeve Beroard created DBCP-406: --- Summary: Support for caching statements with autogenerated keys Key: DBCP-406 URL: https://issues.apache.org/jira/browse/DBCP-406 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.0 Reporter: Steeve Beroard Priority: Minor I would like to submit a patch to enable caching for statement with autogenerated keys. My original version was on version 1.3 but i did the change for the current version in the trunk -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SCXML-180) Prevent NPEs for possible null value returned from Evaluator.eval* methods
[ https://issues.apache.org/jira/browse/SCXML-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma updated SCXML-180: Description: I just encountered the following NPE: java.lang.NullPointerException at org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415) at org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124) at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256) at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349) This turned out to be caused by an transition condition (evaluated through Jexl) resulting in, and thus also returning, a null value. A quick scan through the usages of Evaluator.eval* method shows several locations within SCXML where it always assumes an non-null value (Boolean or otherwise) to be returned. All possible sources for unexpected NPEs. I think that for at least the Evaluator#evalCond method, which is assumed to return a Boolean, either an error should be catched/returned or maybe even assume null == Boolean.FALSE. was: I just encountered the following NPE: java.lang.NullPointerException at org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415) at org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124) at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256) at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349) This turned out to be caused by an transition condition (evaluated through Jexl) resulting in and thus returning a null value. A quick scan through the usages of Evaluator.eval* method shows several locations within SCXML where it always assumes an non-null value (Boolean or otherwise) to be returned. All possible sources for unexpected NPEs. I think that for at least the Evaluator#evalCond method, which is assumed to return a Boolean, either an error should be catched/returned or maybe even assume null == Boolean.FALSE. > Prevent NPEs for possible null value returned from Evaluator.eval* methods > -- > > Key: SCXML-180 > URL: https://issues.apache.org/jira/browse/SCXML-180 > Project: Commons SCXML > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Ate Douma > Fix For: 2.0 > > > I just encountered the following NPE: > java.lang.NullPointerException > at > org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415) > at > org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124) > at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256) > at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349) > This turned out to be caused by an transition condition (evaluated through > Jexl) resulting in, and thus also returning, a null value. > A quick scan through the usages of Evaluator.eval* method shows several > locations within SCXML where it always assumes an non-null value (Boolean or > otherwise) to be returned. All possible sources for unexpected NPEs. > I think that for at least the Evaluator#evalCond method, which is assumed to > return a Boolean, either an error should be catched/returned or maybe even > assume null == Boolean.FALSE. > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DBUTILS-117) Error in control the use of ParameterMetaData
Vadim Smirnov created DBUTILS-117: - Summary: Error in control the use of ParameterMetaData Key: DBUTILS-117 URL: https://issues.apache.org/jira/browse/DBUTILS-117 Project: Commons DbUtils Issue Type: Bug Affects Versions: 1.5 Reporter: Vadim Smirnov Priority: Minor Error in fillStatement method of AbstractQueryRunner class. There is no try...catch statement near pmd = stmt.getParameterMetaData(); So method fails instead of automaticallye turning pmdKnownBroken to true. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1070) Incorrect rounding of float
Oleksandr created MATH-1070: --- Summary: Incorrect rounding of float Key: MATH-1070 URL: https://issues.apache.org/jira/browse/MATH-1070 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Windows 7, IntelliJ IDEA 10.5.4. Reporter: Oleksandr Priority: Critical package org.apache.commons.math3.util example of usage of round functions of Precision class: Precision.round(0.0f, 2, BigDecimal.ROUND_UP) = 0.01 Precision.round((float)0.0, 2, BigDecimal.ROUND_UP) = 0.01 Precision.round((float) 0.0, 2) = 0.0 Precision.round(0.0, 2, BigDecimal.ROUND_UP) = 0.0 Seems the reason is usage of extending float to double inside round functions and getting influence of memory trash as value. I think, same problem will be found at usage of other round modes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-366) Getting Exception when trying to get the PrepareStatement from Connection From DBCP Pool
[
https://issues.apache.org/jira/browse/DBCP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DBCP-366.
--
Resolution: Invalid
You are continuing to try and use the connection after you have closed it. That
is not allowed.
> Getting Exception when trying to get the PrepareStatement from Connection
> From DBCP Pool
>
>
> Key: DBCP-366
> URL: https://issues.apache.org/jira/browse/DBCP-366
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.2
> Environment: Linux machine
>Reporter: saroj kumar balusu
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Using commons-dbcp-1.2.2.jar version with Tomcat version 6.0.29.
> Getting the following exception when trying to get the
> java.sql.PrepareStatement using a Connection from DBCP Pool:
> {noformat}
> java.sql.SQLException: Connection is closed.
> at
> org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.checkOpen(PoolingDriver.java:263)
> at
> org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.prepareStatement(PoolingDriver.java:366)
> {noformat}
> This is the configuration we are using for creating Connection Pool from DBCP:
> {code:java}
> public static void setupDriver(String connectURI, String userName,
> String dbPassword, String maxActive, String minIdle,
> String maxWait, String poolName) throws Exception {
> GenericObjectPool.Config config = new
> GenericObjectPool.Config();
> config.maxActive = Integer.parseInt(maxActive);
> config.minIdle = Integer.parseInt(minIdle);
> config.maxWait = Integer.parseInt(maxWait);
> config.whenExhaustedAction = 2;
> config.minEvictableIdleTimeMillis = 180;
> config.timeBetweenEvictionRunsMillis = 180;
> config.numTestsPerEvictionRun = 3;
> config.testOnBorrow = true;
> config.testOnReturn = true;
> config.testWhileIdle = true;
> ObjectPool connectionPool = new GenericObjectPool(null, config);
> ConnectionFactory connectionFactory = new
> DriverManagerConnectionFactory(
> connectURI, userName, dbPassword);
> PoolableConnectionFactory poolableConnectionFactory = new
> PoolableConnectionFactory(
> connectionFactory, connectionPool, null, null,
> false, true);
> poolableConnectionFactory.setValidationQuery("select 1 from
> dual");
> driver = new PoolingDriver();
> driver.registerPool(poolName, connectionPool);
> driver.setAccessToUnderlyingConnectionAllowed(true);
> // PoolingDataSource dataSource = new
> PoolingDataSource(connectionPool);
> // return dataSource;
> }
> {code}
> The following code is used to get the Connection:
> {code:java}
> public java.sql.Connection getConnection(poolName) {
> Connection con =
> DriverManager.getConnection("jdbc:apache:commons:dbcp:"+poolName);
> return con;
> }
> {code}
> The following code is used to release the connection:
> {code:java}
> public void release(Connection conn) throws DBException {
> try {
> conn.close();
> } catch (Exception e) {
> throw new Exception(e.getMessage(), e);
> }
> }
> {code}
> Can you let us know what might be the exact reason for the following
> exception?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (DBCP-366) Getting Exception when trying to get the PrepareStatement from Connection From DBCP Pool
[
https://issues.apache.org/jira/browse/DBCP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DBCP-366:
-
Description:
Using commons-dbcp-1.2.2.jar version with Tomcat version 6.0.29.
Getting the following exception when trying to get the
java.sql.PrepareStatement using a Connection from DBCP Pool:
{noformat}
java.sql.SQLException: Connection is closed.
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.checkOpen(PoolingDriver.java:263)
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.prepareStatement(PoolingDriver.java:366)
{noformat}
This is the configuration we are using for creating Connection Pool from DBCP:
{code:java}
public static void setupDriver(String connectURI, String userName,
String dbPassword, String maxActive, String minIdle,
String maxWait, String poolName) throws Exception {
GenericObjectPool.Config config = new
GenericObjectPool.Config();
config.maxActive = Integer.parseInt(maxActive);
config.minIdle = Integer.parseInt(minIdle);
config.maxWait = Integer.parseInt(maxWait);
config.whenExhaustedAction = 2;
config.minEvictableIdleTimeMillis = 180;
config.timeBetweenEvictionRunsMillis = 180;
config.numTestsPerEvictionRun = 3;
config.testOnBorrow = true;
config.testOnReturn = true;
config.testWhileIdle = true;
ObjectPool connectionPool = new GenericObjectPool(null, config);
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(
connectURI, userName, dbPassword);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(
connectionFactory, connectionPool, null, null,
false, true);
poolableConnectionFactory.setValidationQuery("select 1 from
dual");
driver = new PoolingDriver();
driver.registerPool(poolName, connectionPool);
driver.setAccessToUnderlyingConnectionAllowed(true);
// PoolingDataSource dataSource = new
PoolingDataSource(connectionPool);
// return dataSource;
}
{code}
The following code is used to get the Connection:
{code:java}
public java.sql.Connection getConnection(poolName) {
Connection con =
DriverManager.getConnection("jdbc:apache:commons:dbcp:"+poolName);
return con;
}
{code}
The following code is used to release the connection:
{code:java}
public void release(Connection conn) throws DBException {
try {
conn.close();
} catch (Exception e) {
throw new Exception(e.getMessage(), e);
}
}
{code}
Can you let us know what might be the exact reason for the following exception?
was:
Using :commons-dbcp-1.2.2.jar version with Tomcat version 6.0.29
Geting the following exception when trying to get the java.sql.PrepareStatement
using a Connection from DBCP Pool.
java.sql.SQLException: Connection is closed.
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.checkOpen(PoolingDriver.java:263)
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.prepareStatement(PoolingDriver.java:366)
This is the configuration we are using for creating Connection Pool from DBCP
--
public static void setupDriver(String connectURI, String userName,
String dbPassword, String maxActive, String minIdle,
String maxWait, String poolName) throws Exception {
GenericObjectPool.Config config = new
GenericObjectPool.Config();
config.maxActive = Integer.parseInt(maxActive);
config.minIdle = Integer.parseInt(minIdle);
config.maxWait = Integer.parseInt(maxWait);
config.whenExhaustedAction = 2;
config.minEvictableIdleTimeMillis = 180;
config.timeBetweenEvictionRunsMillis = 180;
config.numTestsPerEvictionRun = 3;
config.testOnBorrow = true;
config.testOnReturn = true;
config.testWhileIdle = true;
ObjectPool connectionPool = new GenericObjectPool(null, config);
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(
connectURI, userName, dbPassword);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(
connectionFactory, connectionPool, null, null,
false, true
[jira] [Commented] (CODEC-174) Improve performance of Beider Morse encoder
[ https://issues.apache.org/jira/browse/CODEC-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837556#comment-13837556 ] Thomas Champagne commented on CODEC-174: It's all good for me :-) I'm waiting the new release of commons-codec. So I will be able to create a new issue for Solr project for updating his dependencies. > Improve performance of Beider Morse encoder > --- > > Key: CODEC-174 > URL: https://issues.apache.org/jira/browse/CODEC-174 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.6, 1.7 >Reporter: Thomas Champagne > Labels: patch, performance > Attachments: CODEC-174-change-rules-storage-to-Map.patch, > CODEC-174-convert-set-to-list-in-apply-method.patch, > CODEC-174-delete-subsequence-cache-and-use-String.patch, > CODEC-174-delete-subsequence-cache.patch, > CODEC-174-refactor-join-method-in-Phoneme.patch, > CODEC-174-refactor-restrictTo-method-in-SomeLanguages.patch, > CODEC-174-reuse-set-in-PhonemeBuilder.patch, CODEC_174_cleanup.patch, > TestCacheSubSequence.java, test-commons-codec-test-bm.zip > > > I use Beider Morse encoder with Solr. When it indexes a lot of documents > using this encoder, the import time is multiplied by 30. So, I have decided > to optimize the current implementation in the commons-codec. > Currently, I have created two patch. The first patch delete a "performance > hack" about a subsequence cache. This cache doesn't optimize performance and > after deleting it, you can win some milliseconds. > The second patch changes the storage of the rules in memory using a Map > instead of List. With it, you can access to a rule directly with the > beginning of pattern. This patch divide the encoding time by 2. > I will try to find more improvement. If you have any idea, please tell me it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-396) AbandonedConfig.setLogWriter() never used
[ https://issues.apache.org/jira/browse/DBCP-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-396. -- Resolution: Fixed Fix Version/s: 2.0 1.5.1 1.4.1 1.3.1 > AbandonedConfig.setLogWriter() never used > - > > Key: DBCP-396 > URL: https://issues.apache.org/jira/browse/DBCP-396 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Seweryn Hejnowicz > Fix For: 1.3.1, 1.4.1, 1.5.1, 2.0 > > > In my scenario I need to set custom PrintWriter to the AbandonedConfig, but I > can't see possibility to do that. All AbandonedConfig properties can be set > through a BasicDataSource except logWriter. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-392) Remove Occurrences of Multiple Statements on One Line
[ https://issues.apache.org/jira/browse/DBCP-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-392. -- Resolution: Fixed Fix Version/s: 2.0 1.5.1 1.4.1 1.3.1 > Remove Occurrences of Multiple Statements on One Line > - > > Key: DBCP-392 > URL: https://issues.apache.org/jira/browse/DBCP-392 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: James Carman >Priority: Minor > Fix For: 1.3.1, 1.4.1, 1.5.1, 2.0 > > > The DelegatingConnection class has many methods that are one-liners, but it's > actually multiple statements. When debugging, it can make it appear as if > the code is being executed twice (it did to me) at first glance. If it's > multiple statements, we should use multiple lines of code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-384) PoolingDriver.accessToUnderlyingConnectionAllowed is thread-hostile
[ https://issues.apache.org/jira/browse/DBCP-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-384. -- Resolution: Fixed Fix Version/s: 2.0 API changed so this will only be fixed in 2.0 onwards. > PoolingDriver.accessToUnderlyingConnectionAllowed is thread-hostile > --- > > Key: DBCP-384 > URL: https://issues.apache.org/jira/browse/DBCP-384 > Project: Commons Dbcp > Issue Type: Bug >Reporter: Sebb > Fix For: 2.0 > > > The field PoolingDriver.accessToUnderlyingConnectionAllowed is static but > mutable; this is inherently thread-hostile. > It seems completely unnecessary for the field to be static; surely it could > be an instance variable? > Better yet, drop the setter/getter and make the field final, set by the ctor. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-177) Correct error/warning messages in SCXML reading to be up-to-date
[ https://issues.apache.org/jira/browse/SCXML-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837507#comment-13837507 ] Ate Douma commented on SCXML-177: - I find it odd the SCXMLReader ignores and only warns about unknown custom actions (within a known namespace). Seems to me the SCXML document cannot be properly executed then, so why not reporting it as an error? Is there anything in the spec saying such errors should be ignored? If not, I would suggest hardening the behavior and make it an error instead. > Correct error/warning messages in SCXML reading to be up-to-date > > > Key: SCXML-177 > URL: https://issues.apache.org/jira/browse/SCXML-177 > Project: Commons SCXML > Issue Type: Bug >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Trivial > Fix For: 2.0 > > > Some error/warning logs are outdated against the newest spec. > For example, > org.apache.commons.scxml2.model.ModelException: No SCXML child state with ID > "null" found; illegal initialstate for SCXML document > at > org.apache.commons.scxml2.io.ModelUpdater.logAndThrowModelError(ModelUpdater.java:297) > It should inform of 'initial', not 'initialstate' and check if it is not set. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-179) Leave more context (location) information when failing to execute JEXL scripts
[
https://issues.apache.org/jira/browse/SCXML-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837505#comment-13837505
]
Ate Douma commented on SCXML-179:
-
Hi Woonsan, nice improvement.
However I'm still puzzled by the Jexl error location (161![14,22]) which seems
weird, as those line numbers(161 AND 14?) don't add up or match with the source.
This is probably more of an Jexl issue I guess, but it would be nice if somehow
this could be improved as well, ideally of course with exact line/column info
within the SCXML source document.
I'm not saying this should be fixed or further improved right now, but maybe
something to look into at a later time?
> Leave more context (location) information when failing to execute JEXL scripts
> --
>
> Key: SCXML-179
> URL: https://issues.apache.org/jira/browse/SCXML-179
> Project: Commons SCXML
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Minor
> Fix For: 2.0
>
>
> Currently, it doesn't give enough context (location) information in warning
> logs when there are script errors (e.g, undefined object usages) like the
> following:
> EXPRESSION_ERROR (evalScript('
> unknownObject.invoke();
>
> '):org.apache.commons.scxml2.env.jexl.JexlEvaluator.evalScript@161![14,22]:
> 'unknownObject.invoke();' attempting to call method on null):
> The line number above (161) is from JexlEvaluator, not from SCXML source.
> It would be better if it gave more information somehow about the SCXML
> location and element location, for instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
