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=27249>. 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=27249 disposed ComponentLocator exception (when sitemap has timestamp in the future?) [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Critical ------- Additional Comments From [EMAIL PROTECTED] 2004-05-25 12:58 ------- I confirm this on my side. The weird exceptions have gone. Now, I simply suppose that a modification timestamp in the future triggers continuous reloads of the subsitemaps, so, I believe that this bug hides something slightly more serious in the release/dispose cycle of the Excalibur pool implementation. For sure I've already found a bug that throws a ConcurrentModificationException in the sitemap. See the attached patch which should solve the problem in the immediate. In no whatsoever case the patch is a "FINAL" fix for the problem. What I think happens is that either the released/disposed component is returned by lookup calls while it's being released/disposed. Therefore the order of the disallocation from the pool is wrong (first the component is disposed, and THEN it is removed from the pool). Someone with Excalibur experience should seriously look into this one.
