[jira] [Commented] (DIGESTER-161) Document thread-safety in javadoc of Rule class
[ https://issues.apache.org/jira/browse/DIGESTER-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197058#comment-13197058 ] Eduard Papa commented on DIGESTER-161: -- Can someone commit the new javadoc I attached, assign it to a version, and mark it as resolved. Thanks Document thread-safety in javadoc of Rule class Key: DIGESTER-161 URL: https://issues.apache.org/jira/browse/DIGESTER-161 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.1 Reporter: Eduard Papa Priority: Trivial Labels: rule, thread-safe Attachments: RuleJavadoc.txt Original Estimate: 1h Remaining Estimate: 1h I discovered a problem today with some code that was reusing a custom Rule in multiple threads, even though each thread was creating its own digester. It seems that Digester.addRule is calling rule.setDigester and if the rule is shared across multiple threads, the calls to begin/end can get tangled across threads. It is obvious that Rules are not meant to be shared, but the javadoc http://commons.apache.org/digester/apidocs/org/apache/commons/digester3/Rule.html seems to be implying the opposite and is confusing at best. It talks about the rules being stateless, even though the framework itself is changing its state with rule.setDigester(digester). It further states that since all state is part of the digester, the rule is safe under all cases, which is very misleading. ... Rule objects should be stateless, ie they should not update any instance member during the parsing process. A rule instance that changes state will encounter problems if invoked in a nested manner; this can happen if the same instance is added to digester multiple times or if a wildcard pattern is used which can match both an element and a child of the same element. The digester object stack and named stacks should be used to store any state that a rule requires, making the rule class safe under all possible uses. ... I think the statement above should be reworded to be more correct and avoid confusion. Down the line, maybe the digester accessed by the rule should be a ThreadLocal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-161) Document thread-safety in javadoc of Rule class
[ https://issues.apache.org/jira/browse/DIGESTER-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13167834#comment-13167834 ] Eduard Papa commented on DIGESTER-161: -- The code I was referring to was actually using digester 2.x, so I don't think the provider method is there. It was just creating digester and adding all the rules. The rule that was causing the problem was a static final...hence the thread-safety issue. I would have liked someone who knows more about Digester to update the javadoc but I'll give a trytomorrow hopefully. Document thread-safety in javadoc of Rule class Key: DIGESTER-161 URL: https://issues.apache.org/jira/browse/DIGESTER-161 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.1 Reporter: Eduard Papa Priority: Trivial Labels: rule, thread-safe Original Estimate: 1h Remaining Estimate: 1h I discovered a problem today with some code that was reusing a custom Rule in multiple threads, even though each thread was creating its own digester. It seems that Digester.addRule is calling rule.setDigester and if the rule is shared across multiple threads, the calls to begin/end can get tangled across threads. It is obvious that Rules are not meant to be shared, but the javadoc http://commons.apache.org/digester/apidocs/org/apache/commons/digester3/Rule.html seems to be implying the opposite and is confusing at best. It talks about the rules being stateless, even though the framework itself is changing its state with rule.setDigester(digester). It further states that since all state is part of the digester, the rule is safe under all cases, which is very misleading. ... Rule objects should be stateless, ie they should not update any instance member during the parsing process. A rule instance that changes state will encounter problems if invoked in a nested manner; this can happen if the same instance is added to digester multiple times or if a wildcard pattern is used which can match both an element and a child of the same element. The digester object stack and named stacks should be used to store any state that a rule requires, making the rule class safe under all possible uses. ... I think the statement above should be reworded to be more correct and avoid confusion. Down the line, maybe the digester accessed by the rule should be a ThreadLocal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
