Hello Thaisa, Thank you for your detailed post and all the data you provided.
The version number that you use in your Maven project is important here, please see: http://unomi.apache.org/manual/1_3_x/index.html#_deployment_and_custom_definition Also, there are shell commands that might also help you can find them here: http://unomi.apache.org/manual/1_3_x/index.html#_runtime_commands As for removing rules when undeploying a plugin, this is by design for the moment, as you might be replacing it or just deactivating it temporarily. But maybe it could be improved to remove them in certain conditions. You can, however, use the REST API to remove rules if you need to. Regards, Serge. On Thu, Jan 31, 2019 at 10:14 PM Thaisa Mirely <tmir...@thoughtworks.com> wrote: > Hi everyone, > I found a critical problem during some manual tests. > > The first problem is when I remove a custom plugin, it is impossible to > remove the rules associated with Karaf / Unomi. > > The second scenario is, when I add a new version of the plugin, my changes > are not applied. For example, if I make a change in the rule condition > that existed in the first version of the removed plugin, the changes will > not be available in the Unomi service. > > *:: Steps to reproduce ::* > > > - *Unomi version:* build generated from this commit > > https://github.com/apache/incubator-unomi/commit/26ce3c1746632ff2180f490e1f2b32b0e588af94 > - *running an instance of Unomi / ES locally* > - inside the plugin we are using a rule with the profile merge action > (attached in the email) > > > Plugin version with the rule example_version01 > > 0) create a sample plugin using the rule_version01 and generate a jar > > 1) install the plugin version copying the jar to > unomi-1.4.0-incubating-SNAPSHOT/deploy folder > > 2) start Karaf/Unomi and make 2 request (payload in the file > request_version01). It is possible to see that a single profile was > generated. > > 3) remove the plugin from the > unomi-1.4.0-incubating-SNAPSHOT/deploy folder > > 4) restart the cluster (system:shutdown -r) > > When we make a request to check the rules (http://localhost:8181/cxs/rules), > it is possible to see that the rules of the plugin that was removed are > still available. > > 5) the step 2 must be repeated > and the behavior is the same from when the plugin was present. > > > Plugin version with the rule example_version02 > > 0) generate a new plugin by updating the rule with the file rule_version02 > > 1) install the plugin version copying the jar to > unomi-1.4.0-incubating-SNAPSHOT/deploy folder > > 2) start Karaf/Unomi and make 2 requests (payload in the file > request_version02) > > The behavior is not what was expected. In this case, the merge was made > using the name_a property instead of name_b (changes made in the new > version of the plugin with rule_version02) > > Making 2 requests using request_version01, you can see the profile being > updated as if the first version of the plugin was installed. > > > Note: > When I make a *bundle:list*, my plugin (unomi-segmenter.jar) shows a > Failure status. > Could someone tell me if this status is expected? > > [image: Screen Shot 2019-01-31 at 14.41.53.png] > > *OSGI lifecycle reference:* > https://eclipsesource.com/blogs/2013/01/23/how-to-track-lifecycle-changes-of-osgi-bundles/ > > have a nice day > >
