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