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=20682>. 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=20682 Generator "directory": Caching fails ------- Additional Comments From [EMAIL PROTECTED] 2003-06-23 12:40 ------- Improving getKey does not seem to solve the problems described completely (although the buggy getKey contributed to the problem reported originally). Caching, however, keeps on to be buggy. I further on believe that the implementation of getValidity is wrong: public SourceValidity getValidity() { this.validity = new DirValidity(this.refreshDelay); return this.validity; } When getValidity is called twice for a generator object (and this seems to happen regularly), two different SourceValidity objects are returned for one and the same generator object. This would not be a problem, if all those SourceValidity objects would be structurally equal, i.e., if they all would contain the same path objects. The path objects, however, are added at another point of time by the method startNode. By doing so, different SourceValidity objects may contain different path objects for one and the same generator object. And this seems not only to happen in theory but also in reality. I've noticed that under specific circumstances getValidity is called twice for one generator object. Afterwards, startNode adds all path objects to the second (current) SourceValidity object. The first object, on the other hand, contains - of course! - no path objects. When Coccon lateron for some reason uses the first SourceValidity object to check validity, isValid always returns 1 (as the path list (List files) is empty), regardless whether something has changed or not.
