Follow up testing on this, tried two cases:

1. setup as project is currently, custom maven configuration with repo in /tmp/maven-repo

2. remove custom maven settings from standalone.xml (single system property), run with .m2 settings and default local maven repsository.


Results:
1. scanner does not show in logs beyond starting up, never scans the custom repository.

2. scanner works for initial 2.0.0 artifact, so changing rules and re-deploy as 2.0.0 new artifact, scanner picks this up in the log file and the web app works with the new rule settings. Bump the project artifact to any higher number (example, 2.1.0 or 3.0.0) then scanner show picking up the new number in the log, but web app not picking up rule changes in new artifact.

Eric,

I see that you have the following repository declaration in settings.xml:

<id>jboss-bpm-suite-repo</id>
<name>JBoss BPM Suite Maven Repository</name>
<url>file://tmp/maven-repo</url>
...

Could you please try with the url pointing to business-central Maven repo servlet, such as:

<url>http://localhost:8080/business-central/maven2</url>

Your original approach is using business-central's local maven repository (i.e. a place where business-central does something like 'mvn install'), but you should be downloading artifacts from the "remote" repository provided by business-central (i.e. where business-central does 'mvn deploy').

You might also need to setup credentials for that server in settings.xml, such as:

  <servers>
    <server>
      <id>kie-wb-m2-repo</id>
      <username>someUser</username>
      <password>somePassword123</password>
      <!-- the configuration below might not be required -->
      <configuration>
        <wagonProvider>httpclient</wagonProvider>
        <httpConfiguration>
          <all>
            <usePreemptive>true</usePreemptive>
          </all>
        </httpConfiguration>
      </configuration>
    </server>
  </servers>

I am not completely sure if this can cause the problems that you reported, but we can at least eliminate possible cause.

Moreover, a few KieScanner bugs have been fixed in 6.1, so if you could try with 6.1, it would be great. I;ll try to verify your scenario as well, but I might not be able to get to it until Monday.

Thanks!

Eric,

just a quick note about [1]. I think that you should not start KieScanner in the bean constructor, as the bean lifecycle is managed by the container (and the constructor might be actually called multiple times). 

I'd recommend using a @PostConstruct method for doing the initialization, and also not to forget stopping KieScanner in a @PreDestroy method to avoid KieScanner starting a background thread which is not properly disposed.


[1] https://github.com/jbossdemocentral/brms-coolstore-demo/blob/v2.7/projects/brms-coolstore-demo/src/main/java/com/redhat/coolstore/util/BRMSUtil.java

(In reply to Marek Winkler from comment #4)
> Eric,
> 
> just a quick note about [1]. I think that you should not start KieScanner in
> the bean constructor, as the bean lifecycle is managed by the container (and
> the constructor might be actually called multiple times). 
> 
> I'd recommend using a @PostConstruct method for doing the initialization,
> and also not to forget stopping KieScanner in a @PreDestroy method to avoid
> KieScanner starting a background thread which is not properly disposed.
> 
> 
> [1]
> https://github.com/jbossdemocentral/brms-coolstore-demo/blob/v2.7/projects/
> brms-coolstore-demo/src/main/java/com/redhat/coolstore/util/BRMSUtil.java
>
Giving this a try... thanks!

I have reproduced this issue and found what is causing it. The problem is not in the KieScanner, it is working as expected and indeed when a new version of the kjar is deployed it correctly finds and installs it and prints something like:

16:26:05,129 INFO  [org.kie.api.builder.KieScanner] (Timer-1) The following artifacts have been updated: {com.redhat:coolstore:2.2.0=com.redhat:coolstore:jar:2.3.0}

The problem is that (at least in the reproducer provided by Eric) when a file is changed inside business-central (I tried with a decision table, but suspect it happens the same also for other types of file) it is written directly in the MemoryFileSystem of the KieModule stored in the KieContainer.

On 6.0.3 this is done by the org.guvnor.common.services.builder.Builder.visitPaths() method on line 557.

That implies that when the new jar is downloaded from the maven repo and compared with what is stored in the FileSystem of the running KieProject it finds them identical since they've been changed in the same way in both places and then the incremental compilation just doesn't do anything.

Michael, at the moment I don't know how limited this issue is, but I think that this is happening in Eric's example because business-central and his webapp are running inside the same application server. Also I didn't try with more recent version but I suspect that we have the same problem also on master. Finally it is not clear to me if the bug is in guvnor or in drools (or more probably in how they interact). Could you please give a try to Eric's use case and then ping me so we could figure out together how to fix this?

Thanks,
Mario

I was wrong when I wrote that when a file is changed inside business-central it is written directly in the same MemoryFileSystem used by the project installed into the KieContainer.

Conversely the problem was caused by the fact that every time a file is saved inside business-central it performs an incremental compilation of the project to notify the user if the modified file eventually caused some compilation failure. This incremental compilation also installs the modified project inside the KieRepository that is a singleton inside the running JVM and then shared by business-central and the webapp. 

When the KieScanner triggered a project update, the kmodule considered as the current one (and then compared to the other newly installed in the maven repository) is taken from the KieRepository, but for what said before the incremental compilation made by business-central already changed it in the meanwhile. For this reason the comparison between the 2 kmodules didn't find any difference and then terminated without doing anything.

Fixed on master by https://github.com/droolsjbpm/drools/commit/ee7dd7c91

Verified with BRMS 6.2.0.ER3.

I have tried Eric's use case and it works: 

- I have started BRMS business-central and brms-coolstore application, 

- added an item less than $25 to the cart,

- updated the rule in Guided Decision Table in Business-central, increased project version to 2.0.1, and built the project

- added an item less than $25 to the cart, the shipping cost has been updated according to the rule change,

- repeated once again to verify KieScanner won't stop scanning.