unomi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shu...@apache.org>
Subject Re: can't remove or update a custom plugin
Date Fri, 01 Feb 2019 13:35:53 GMT
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 <tmirely@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
>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message