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=28724>. 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=28724 FragmentExtractor always returns same fragment ------- Additional Comments From [EMAIL PROTECTED] 2004-05-01 15:11 ------- That's the problem: String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + fragmentID) The store key/fragment id is only based on the request URI. Both Sarah and Derek used request params, which are not "seen". The SAXFragment is stored using this key, which leads probably to an update on the store if the key is used a second time: store.store(id, this.serializer.getSAXFragment()); This is probably ok until the FragmentExtractorGenerator comes into play: The caching key of the generator is based on the fragment id. So the same id leads to validity of the old fragment, the store is not asked at all. Anybody with a clever proposal? 1. The simplest one would be to make the generator not cacheable. 2. The correct solution would probably be to ask the store for the validity of the fragment, i.e. getValidity() must not return NOPValidity.SHARED_INSTANCE, but the fragment's validity. Don't know how to do this. 3. Letting influence more pseudo options (e.g. request params) the fragment id is IMO no option, the difference might be only time-based (e.g. "generated at ..."), the former component should decide on that caching. 4. If it is possible to base the hashcode on the SAXFragment, this would be also a good solution, but it does not "invalidate" the former SAXFragment. Any suggestion?
