[rules-dev] Issue with ResourceChangeScanner

[Michael Neale]

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