You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by Thaisa Mirely <tm...@thoughtworks.com> on 2019/01/31 21:13:49 UTC
can't remove or update a custom plugin
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
Re: can't remove or update a custom plugin
Posted by Serge Huber <sh...@apache.org>.
I realize I forgot to answer your last question. The failure in your bundle
show not happen. I suggest you check the Karaf logs (in data/log/karaf.log
or by using the ld shell command) to see what the error was on deployment.
Regards,
Serge....
On Thu, Jan 31, 2019 at 10:14 PM Thaisa Mirely <tm...@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
>
>
Re: can't remove or update a custom plugin
Posted by Serge Huber <sh...@apache.org>.
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 <tm...@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
>
>