On 13 Dec 2013, at 13:51, lbilger <lars.bilger(a)lhsystems.com> wrote:
I thought that was what the KieScanner did?
KieScanner
re-resolves the pom and it’s dependencies, and checks against what is currently deployed.
If any of the versions have changed, it updates the current KieContainer.
I spent some time trying to get
it to work as I would expect it to, but ran into several problems that made
me go back to 5.5 for now.
Here's what I did:
I created two maven projects, one to contain the rules ("drools6:rules") and
one to use them ("drools6:drools6").
In "drools6:drools6" I created a Main class and method in which I initialize
the KieContainer and KieScanner as follows:
KieServices kieServices = KieServices.Factory.get();
ReleaseId releaseId = kieServices.newReleaseId("drools6",
"rules",
"1.0.0-SNAPSHOT");
final KieContainer kieContainer =
kieServices.newKieContainer(releaseId);
KieScanner kieScanner = kieServices.newKieScanner(kieContainer);
kieScanner.start(1000);
// Some code to see when rules were changed
System.in.read(); // Keep the VM running while waiting for rule
changes
Now I would expect the rules to be automatically picked up if I change them
in "drools6:rules" and "mvn install" it. But no changes are detected.
There is a limitation in 6.0.0 - fixed in master. Once you pass in the initial root
releaseId - it resolves it to real version, and uses that for all scanNows. So only
dependencies in the pom.xml will have their -SNAPSHOT re-resolved. The work around was to
create a wrapper project.
A previous email "Re: [rules-users] Drools 6 and dynamic update”:
"On a side note, on master, there is a change to ensure that the Maven syntax for
scanNow (with using the KieScanner) is obeyed. see
https://issues.jboss.org/browse/DROOLS-356"
I
debugged the KieScanner and it seems that it compares the version number of
the releaseId to the one from the repository, which is "1.0.0-SNAPSHOT" in
both cases, so the new jar is not considered newer.
So I thought, "OK, so I need to change the version number". I changed the
version of the "drools6:rules" project to 1.0.1-SNAPSHOT. This didn't help
either, because the releaseId explicitly requests 1.0.0-SNAPSHOT, so the
newer version is never loaded.
My next idea was to use "LATEST" in the releaseId instead of an explicit
version. At first this did not work for my local repository, but after
manually editing the maven metadata file and adding a <latest> tag, it found
the new version. But now, the KieScanner found a change every time it looked
because it compared the version string "LATEST" to "1.0.1-SNAPSHOT"
and
always considered the "real" version newer. With a certain amount of rules
and a short polling interval this caused the KieContainer to be busy
rebuilding all the time and a very high CPU load.
I also tried deploying to a real maven repository instead of just installing
to local, but with no success.
What am I missing here? Or isn't this how the KieScanner is supposed to
work?
Try the latest snapshot, that has the above issue, in 356, fixed.
http://downloads.jboss.org/drools/release/snapshot/6.0.x/
Thanks
Lars
Mark Proctor wrote
> We do not have any file change listeners. You, or the workbench, needs to
> build the jar.
>
> What is automatic is the role of change sets before. You no longer need to
> compute them, build the jar, have the client consume the jar (with
> different ReleaseID) - that’s it. Drools diffs the current and target jar,
> and upgrades accordingly.
>
> Mark
--
View this message in context:
http://drools.46999.n3.nabble.com/Drools-6-support-for-changeset-tp402713...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users