DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39296 ------- Additional Comments From [EMAIL PROTECTED] 2006-04-28 22:59 ------- Hi Darryl, I found that the problem is fixed in the 5.5.16 release; at least the testcase I had that failed on 5.5.15 worked on 5.5.16. I'm still not convinced that the code is right. The patch that fixed this did it in what seems to me to be an odd way. I found this bug in 5.5.15; before filing with bugzilla I looked at the patches from 5.5.15 to 5.5.16, and believed there was no point testing 5.5.16 because no patch seemed related to the bug I had. I was wrong, but I think that indicates that logging handling in this class is not implemented cleanly. Nevertheless, I'm unable to cause the 5.5.16 code to fail. I would agree with you about not allowing logging failures to "destabilise the container". However any invocation of a user-supplied object should be wrapped in a try-catch block. What needs to be remembered is that a Log object initialised while TCCL is set to a webapp *is* a user-supplied object. If it is treated like other user-supplied objects (ContextListeners etc) are treated then there should be no problems; wrapping use of the logger in try/catch shouldn't be necessary. Naming the object "userLog" instead of "log" might help. Of course if the webapp TCCL is left set, as indicated in bug #38795 then things will get really stuffed up! I can't refer you to a particular "code path" where Log is used after TCCL is reset; it was clear from the exception that was caused that it was happening, but I don't have a particular line of code I can point to. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
