DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14578>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14578 potential race condition ------- Additional Comments From [EMAIL PROTECTED] 2002-11-15 00:37 ------- I believe another potential race condition exists in the StylesheetHandler class. Member m_XSLMessages is static. Several methods on class XSLMessages are not thread-safe (eg createWarning). So here is a scenario: * thread 1 calls warn on an instance of StylesheetHandler, which calls the createWarning method on class member m_XSLMessages, which suspends * thread 2 calls warn on a separate instance of StylesheetHander, which calls the createWarning method on class member m_XSLMessages. There are now 2 threads active in non-thread-safe method XSLMessages.createWarning. Suggested fixes: (a) make m_XSLMessage an instance member of StylesheetHandler not a static (class) member, (b) wrap all calls to m_XSLMessage methods from StylesheetHandler in synchronized(m_XSLMessage) {...}, or (c) make relevant public methods on XSLMessage class thread-safe by inserting relevant locking code, or (d) cause XSLMessage class to initialize itself early (eg in constructor) so that its methods like createWarning can then be thread-safe without any locking required. Method Method warn is not synchronized
