[rules-dev] Issue with ResourceChangeScanner

Sun Oct 11 18:03:27 EDT 2009

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 <steve.ronderos at ni.com> 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
>
> rules-dev-bounces at lists.jboss.org 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:
>>
>> rules-dev-bounces at lists.jboss.org
>>
>> 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 <steve.ronderos at ni.com>
>> 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
>> >
>> > rules-dev-bounces at lists.jboss.org 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:
>> >>
>> >> rules-dev-bounces at lists.jboss.org
>> >>
>> >> 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 <steve.ronderos at ni.com>
>> >> 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
>> >> > rules-dev at lists.jboss.org
>> >> >
> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Michael D Neale
>> >> home: www.michaelneale.net
>> >> blog: michaelneale.blogspot.com
>> >>
>> >> _______________________________________________
>> >> rules-dev mailing list
>> >> rules-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>> > _______________________________________________
>> > rules-dev mailing list
>> > rules-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>> >
>>
>>
>>
>> --
>> Michael D Neale
>> home: www.michaelneale.net
>> blog: michaelneale.blogspot.com
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com