Yeah I think if lastModified is not implemented, it can't really be taken into account.
I really think most of this is due to scanning the classpath - in other cases it is probably reasonable to expect it to be correct - the other alternative is to read the whole thing into a buffer, and then compare hashes (SHA-1 or MD5 would be good enough) of what it has versus what it just downloaded to see if there is a difference. That isn't really good for polling, as it is a reasonable amount of computation to do (at least that is my gut feel) and needless downloading. Hope that makes sense ! Michael. On Sat, Oct 10, 2009 at 3:35 AM, Steve Ronderos <[email protected]> wrote: > > Michael, > > I've logged the issue (https://jira.jboss.org/jira/browse/JBRULES-2293). I > agree that classpath resources should not be scanned. That would solve my > immediate problem. > > One last note, I still don't think that checking lastModified != 0 to > determine existence is ideal, there could be other scenarios where the > lastModified method is not implemented and returns 0. Is there a better way > to check for resource existence other than lastModified? > > Thanks, > > Steve Ronderos > > [email protected] wrote on 10/08/2009 05:13:17 PM: > >> [image removed] >> >> Re: [rules-dev] Issue with ResourceChangeScanner >> >> Michael Neale >> >> to: >> >> Rules Dev List >> >> 10/08/2009 05:14 PM >> >> Sent by: >> >> [email protected] >> >> Please respond to Rules Dev List >> >> Hi Steve - ok - I am leaning towards insisting that classpath >> resources are not scanned for - just loaded once. There are cases >> where you can update a classpath value on the fly, but really, I think >> using file/database/http would be better for that sort of dynamic >> changes... >> >> Please do log it as a bug, let us know and I will make it critical, as >> I think its kinda broken and not workable at the moment. >> >> On Fri, Oct 9, 2009 at 12:46 AM, Steve Ronderos <[email protected]> >> wrote: >> > >> > Michael, >> > >> > In this exact case I am not expecting the scanner to ever find an >> > updated >> > resource; however, the changeset is configured to read one resource from >> > a >> > URL and another from the classpath. The resource from the URL is >> > expected >> > to change, but the one from the classpath is not. We have a use case >> > where >> > we may need classpath resources to be scanned, but I'm not sure itwill >> > ever >> > come up. >> > >> > Unfortunately I don't think that we can reference that resource any way >> > other than the classpath at this moment, but we do have another >> > workaround. >> > Previous to Drools 5 we had a custom way of refreshing our resources >> > which >> > I think we will go back to for now. >> > >> > Should I log a feature request for this change? >> > >> > Steve Ronderos >> > >> > [email protected] wrote on 10/07/2009 05:29:56 PM: >> > >> >> [image removed] >> >> >> >> Re: [rules-dev] Issue with ResourceChangeScanner >> >> >> >> Michael Neale >> >> >> >> to: >> >> >> >> Rules Dev List >> >> >> >> 10/07/2009 05:31 PM >> >> >> >> Sent by: >> >> >> >> [email protected] >> >> >> >> Please respond to Rules Dev List >> >> >> >> Hi Steve - I have seen that issue before reported by others. But you >> >> just explained the cause ! - I don't often use the classpath scanner >> >> myself, so never thought of that. >> >> >> >> Yes the lastModified being zero is a problem... >> >> >> >> OK, well I think perhaps the solution would be if lastModified is not >> >> a valid value, to NOT use that to decide availablility. >> >> >> >> I think using a scanner on a classpath resource is a bit unusual to >> >> start with, but it is possible in various containers to dynamically >> >> change the classpath, so it kind of technically makes sense. >> >> >> >> If I had things in the classpath, I would assume they are constant - >> >> but I assume you are actually expecting the scan to pick up changes in >> >> a future ? >> >> >> >> (in the meantime, if you can avoid the classpath one that problem >> >> should go away). >> >> >> >> On Thu, Oct 8, 2009 at 5:53 AM, Steve Ronderos <[email protected]> >> >> wrote: >> >> > >> >> > Hello Dev List, >> >> > >> >> > I encountered an issue today with my KnowledgeAgent removing >> >> > resources >> >> > from >> >> > its RuleBase shortly after creating it. I have the >> >> > ResourceChangeScanner >> >> > running in my application. >> >> > >> >> > I tracked the issue back to the scan() method in >> >> > ResourceChangeScannerImpl. >> >> > It appears that the method is trying to identify resources that are >> >> > no >> >> > longer available and remove them from both the RuleBase and future >> >> > scans. >> >> > To do this it is checking lastModified on the resource and on a >> >> > result >> >> > of 0 >> >> > removing the resource. The resources that I configured in my >> >> > change-set >> >> > definitely still exist, but due to URL handler implementation >> >> > provided >> >> > by my >> >> > classloader, getLastModified always returns 0. (The resource I'm >> >> > retrieving >> >> > is coming from a jar that is in my application's classpath and the >> >> > URL >> >> > handler implementation is oracle.classloader.SharedCodeSourceURL) >> >> > >> >> > Do you think it would be possible for the scan to identify >> >> > unavailable >> >> > resources some other way than with the lastModified? and then if >> >> > lastModified is 0 maybe always or never update the resource? I'm not >> >> > sure >> >> > what the best approach to that would be, but removing resources when >> >> > their >> >> > lastModified is 0 seems incorrect to me. >> >> > >> >> > Thanks, >> >> > >> >> > Steve Ronderos >> >> > _______________________________________________ >> >> > rules-dev mailing list >> >> > [email protected] >> >> > > https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Michael D Neale >> >> home: www.michaelneale.net >> >> blog: michaelneale.blogspot.com >> >> >> >> _______________________________________________ >> >> rules-dev mailing list >> >> [email protected] >> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > >> > _______________________________________________ >> > rules-dev mailing list >> > [email protected] >> > https://lists.jboss.org/mailman/listinfo/rules-dev >> > >> > >> >> >> >> -- >> Michael D Neale >> home: www.michaelneale.net >> blog: michaelneale.blogspot.com >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
