Description of problem:
Project setup with full configuration of external maven repo (/tmp/maven-repo) here:

https://github.com/jbossdemocentral/brms-coolstore-demo/tree/v2.7

In project/brms-cool-store/* is web app with BRMSUtils class setting up KieScanner for watching maven repo for dynamic rule updates.

In support/* you will find standalone.xml with system property for customer maven configuration. This settings.xml file is found also in support/* and copied to installation, it points to /tmp/maven-repo and has profile to be able to set this repo to 'updatePolicy' as 'always'.

The web app is built during installation on developers .m2 repo and settings, deployed into brms server.

Start brms server, login (erics / jbossbrms1!), build & deploy project to see version 2.0.0 appear in /tmp/maven-repo/com/redhat/coolstore/2.0.0/*

Start web app at http://localhost:8080/brms-cool-store, note starting KieScanner in logs.

Add item less than $25 to cart and should see shipping cost $2.99.

Back in business-central, update decision table pricing tier 1 from 2.99 to 1.99, save, build and deploy project (either as version 2.0.0 again, or as  2.1.0 or as 3.0.0, does not matter), watch logs as KieScanner is set to scan after 10 seconds. 

Check web app, tier 1 pricing stays 2.99.

Note: if not using custom maven settings with repo in /tmp/maven-repo, will see the scanner appear for .m2 repository, but no updates done in the web app. tier 1 pricing remains 2.99.

PS. With 6.1.CR2 updates I will test this project and report finding here too.


Version-Release number of selected component (if applicable):
JBoss BRMS 6.0.3

How reproducible:
Install project as above, add brms 6.0.3 installer jar to installs directory and run init.sh. Follow steps to reproduce above.

Steps to Reproduce:
1.see above.
2.
3.

Actual results:
KieScanner not scanning custom maven repo. Also not updating dynamic rule changes when deployed to web app using scanner.

Expected results:
KieScanner showing in log 10s after deployment a scan and picking up the rule changes in next run of the web app without re-deployment of web app.


Additional info:
This is a business use case, thus the complete project setup instead of a unit test reproducer. Mario requested assignment of this task.

--- Additional comment from JBoss Product and Program Management on 2015-04-02 05:40:17 EDT ---

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Eric D. Schabell on 2015-04-02 08:22:03 EDT ---

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.

--- Additional comment from Marek Winkler on 2015-04-03 03:50:23 EDT ---

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!

--- Additional comment from Marek Winkler on 2015-04-03 03:55:50 EDT ---

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

--- Additional comment from Eric D. Schabell on 2015-04-08 09:59:16 EDT ---

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

--- Additional comment from Mario Fusco on 2015-04-10 14:29:41 EDT ---

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

--- Additional comment from  on 2015-04-13 06:55:03 EDT ---

Mario and I had a chat and the issue is suspected to relate to KieContainer's use of KieRepo.getKieModule( currentReleaseId ). Mario proposed changing KieContainer to hold a reference to it's active KieModule(s) rather than look it up.

--- Additional comment from Mario Fusco on 2015-04-13 08:40:46 EDT ---

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