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 it will 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
