From dev-return-3094-archive-asf-public=cust-asf.ponee.io@unomi.incubator.apache.org Fri Feb 1 13:36:11 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id CA572180627 for ; Fri, 1 Feb 2019 14:36:10 +0100 (CET) Received: (qmail 94062 invoked by uid 500); 1 Feb 2019 13:36:10 -0000 Mailing-List: contact dev-help@unomi.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@unomi.incubator.apache.org Delivered-To: mailing list dev@unomi.incubator.apache.org Received: (qmail 94051 invoked by uid 99); 1 Feb 2019 13:36:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2019 13:36:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 7528D181A97 for ; Fri, 1 Feb 2019 13:36:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -11 X-Spam-Level: X-Spam-Status: No, score=-11 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, WEIRD_PORT=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id NtbPluv6BNqD for ; Fri, 1 Feb 2019 13:36:07 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id D2E9460CEA for ; Fri, 1 Feb 2019 13:36:06 +0000 (UTC) Received: (qmail 94036 invoked by uid 99); 1 Feb 2019 13:36:06 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2019 13:36:06 +0000 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 613E92EB2 for ; Fri, 1 Feb 2019 13:36:05 +0000 (UTC) Received: by mail-ot1-f53.google.com with SMTP id n8so5988289otl.6 for ; Fri, 01 Feb 2019 05:36:05 -0800 (PST) X-Gm-Message-State: AJcUukcGG+b+sPsmQ7OUCpGxCuguSnzcp9BgcGP7mNG5boKzJP0P4kRW zH/MNZ5KELTd/mBeGbdmlkhld8uQZ8OkQ0MtnhApAQ== X-Google-Smtp-Source: ALg8bN7898ZukmI51d61WWnOfWqMEernFVlrSwt6yguMDT6EJixw5Cge/4vr16MiPubEFe4c2AaEw/ycLszuWaYWXsk= X-Received: by 2002:a9d:5f06:: with SMTP id f6mr29953767oti.258.1549028164761; Fri, 01 Feb 2019 05:36:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Serge Huber Date: Fri, 1 Feb 2019 14:35:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: can't remove or update a custom plugin To: dev@unomi.incubator.apache.org Content-Type: multipart/related; boundary="000000000000826aa10580d539bf" --000000000000826aa10580d539bf Content-Type: multipart/alternative; boundary="000000000000826aa00580d539be" --000000000000826aa00580d539be Content-Type: text/plain; charset="UTF-8" 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 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 > > --000000000000826aa00580d539be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realize I forgot to answer your last question. The failu= re in your bundle show not happen. I suggest you check the Karaf logs (in d= ata/log/karaf.log or by using the ld=C2=A0shell command) to see what the er= ror was on deployment.

Regards,
=C2=A0 Serge..= ..=C2=A0

On Thu, Jan 31, 2019 at 10:14 PM Thaisa Mirely <tmirely@thoughtworks.com> wrote= :
<= div dir=3D"ltr">
Hi everyone,
<= div>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 change= s are not applied. For example, if I make a=C2=A0 change in the rule condit= ion that existed in the first version of the removed plugin, the changes wi= ll not be available in the Unomi service.

:: Steps to reprodu= ce ::


Plugin version with the rule example_version01

0) create a sample plugin using the rule_version01 and ge= nerate 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 reques= t_version01). It is possible to see that a single profile was generated.=C2= =A0

3) remove the plugin from the unomi-1.4.0-incu= bating-SNAPSHOT/deploy=C2=A0folder=C2=A0

4) restar= t 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_ver= sion02

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/deplo= y folder

2) start Karaf/Unomi and make 2 requests = (payload in the file request_version02)

The behavi= or is not what was expected. In this case, the merge was made using the nam= e_a property instead of name_b (changes made in the new version of the plug= in with rule_version02)

Making 2 requests using re= quest_version01, you can see the profile being updated as if the first vers= ion of the plugin was installed.


Note:=C2=A0
When I make a bundle:list, my plugin (unomi-= segmenter.jar) shows a Failure status.
Could someone tell me if t= his status is expected?

3D"Screen

<= div>OSGI lifecycle reference:=C2=A0https://eclipsesource.com/blogs/2013/01/23/how-to-track-lifecy= cle-changes-of-osgi-bundles/

have a nice day

--000000000000826aa00580d539be-- --000000000000826aa10580d539bf--