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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev