Return-Path: X-Original-To: apmail-felix-users-archive@minotaur.apache.org Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F3D9B18C1A for ; Wed, 13 Jan 2016 12:57:16 +0000 (UTC) Received: (qmail 47652 invoked by uid 500); 13 Jan 2016 12:57:16 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 47600 invoked by uid 500); 13 Jan 2016 12:57:16 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 47587 invoked by uid 99); 13 Jan 2016 12:57:15 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jan 2016 12:57:15 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 546A5C1796 for ; Wed, 13 Jan 2016 12:57:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.65 X-Spam-Level: *** X-Spam-Status: No, score=3.65 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, KAM_INFOUSMEBIZ=0.75, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id F1qGnYYB3CDr for ; Wed, 13 Jan 2016 12:57:07 +0000 (UTC) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 49B31258C7 for ; Wed, 13 Jan 2016 12:57:07 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id f206so293084181wmf.0 for ; Wed, 13 Jan 2016 04:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hLurkmgobyQM8JPsJnJuh+jGTPIW3D02G9/ePBpFJHM=; b=nJTtYAhGBKY5ePXW4mVDeNZb7NCIamrQB402fLuAJtzUmi3rlI62mlTKjOmK0VgRmg NCguCYsMaNSdCanvTiJThAH3VkN5ohnxVHHRuIMmX9wtuVslzQBYePOTpAyvTdOu30Ti 5+aXa2J2mQvFUh4kUzdnJt1zE6YtBbjaCWuwJGG5qyW9M03us1nOgUWSUHPvPaDS7sub r2QM0KaTi1Ng8krqRQv3pbuxwe2z7eJ/ijEeCUadQFDEjgbdzzSmf3MRegVYMkx2An41 O7VqG8NazcvX4CmBssg8ui7iZxtflxyTq//OYLI8VXt4utgJFAJqVy2WyUMtxY6KqmHO THVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hLurkmgobyQM8JPsJnJuh+jGTPIW3D02G9/ePBpFJHM=; b=Wm0wjzIN7S20vFYWzMkYHAtdxDSZl7KGwdsqMbSYGvMFQKh6Q4BlDlcxLoVNnUmaWY ziJlrIncCQs+rQBOL+iQAPT55pIExvLdA+MSp7PB3GpSRRTrlmsVi06q1X6t7hHOAMPI X+mfpbhCSzj08mS1Hd4Z6b3nRG4zfuH0ajuSuxfpKHnfOGc+q31ZAstJvnNP9oc9I+nY F0J2aHjAA4uso/sp3kLNHCQMztyhmJxJuO6DeJXz13cOz8dGVw/jEBwfV7wFK/ygz9Ah AAqx02pa6xauIAgVwbpWCZYJa+gFOCwM9ibR9JfCVIVauaULByMee3Am45amYMXs+5lF CCeQ== X-Gm-Message-State: ALoCoQmnYCX9aNuoV6JJ4VwzFcV1EZt9tSpjAiOjx/aBeLzl1g5fCr3k6Yf9NgNbBVgIcjz7O9f9jnp/wyOmXDQB7EHkFF4Rtw== MIME-Version: 1.0 X-Received: by 10.28.90.133 with SMTP id o127mr24827218wmb.101.1452689827007; Wed, 13 Jan 2016 04:57:07 -0800 (PST) Received: by 10.28.100.5 with HTTP; Wed, 13 Jan 2016 04:57:06 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Jan 2016 13:57:06 +0100 Message-ID: Subject: Re: Specifying dependency between a bundle and a fragment bundle From: Milen Dyankov To: users@felix.apache.org Content-Type: multipart/alternative; boundary=001a114545d61b9516052936b551 --001a114545d61b9516052936b551 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your thoughts regarding replacing the service. However that is not really my concern. There are 2 aspects in the picture - the service itself and the UI to communicate with it. In traditional layered architecture one would refer to those as service layer an UI layer. Both are developed independenty and in more complex scenarios there could be N bundles providing UIs for working with M bundles providing services. In non-OSGi environment if I start application having correct modules (jar files and resources on the classpath) at runtime, I am kind of guaranteed to have a consistent change in both layers. In OSGi (or any dynamic modular system I guess) one change can be applied and the other one not (due to configuration, resolve issues, removed dependencies, ...) which can lead to UI functionality not matching the actual underlying services providing it. So what I'm struggling with is finding a way to keep the changes consistent across both layers. As in this particular case the changes to the UI layer are applied via fragment bundles and the changes to the service layer are applied by providing "regular" bundles, I'm looking for a way to express the relationship between those. I guess using Requirements and Capabilities would be perfect but to my understanding you can not use it for fragments. On Wed, Jan 13, 2016 at 1:24 PM, CLEMENT Jean-Philippe < jean-philippe.clement@fr.thalesgroup.com> wrote: > I'm not too sure what you need, but I would say first that you consider > what you have (a text file) rather than what you need (a service or > services). It seems you see things through the provider instead of the > consumer. > > So, you have a button which calls a service S. Fine. Then you want S to b= e > the best service. So you just have to implement a service S which is a > proxy to T services and which will forward calls to the best T service. > > You can even reuse S instead of another T service. So, S is a proxy to > other S services. The proxy has the better ranking in order the button to > "find it". The proxy has to exclude itself from S service candidates. > > ...just a quick thought... > > JP > > [@@ OPEN @@] > > -----Message d'origine----- > De : Milen Dyankov [mailto:milendyankov@gmail.com] > Envoy=C3=A9 : mercredi 13 janvier 2016 11:10 > =C3=80 : users@felix.apache.org > Objet : Specifying dependency between a bundle and a fragment bundle > > Lets say I have a UI bundle that renders a button from template. The > template is just a text file(s) inside UI bundle. Clicking the button cal= ls > a service (for the purpose of this example say one with the highest rank)= . > > The requirement is: change both the service that is called and the button > in consistent manner. > > The first part is easy: > - To change the service one can simply provide a new bundle (call it S) > containing the new service implementation (with higher rank or whatever > else it takes to make it the one that service registry will give to the U= I > bundle). > - To change the button (or even replace it with something else) one can > provide a fragment bundle (call it FB) with updated template file(s). > > The question is, how to keep those consistent? That is, make sure that > either both S and FB are applied or none of them (lets assume S will > somehow ensure the service is registered or stop itself if it can't do so= )! > > It seams one needs to somehow declare a bidirectional dependency (I hate > the way it sounds, but that's what it in fact is, isn't it) between a > bundle and a fragment bundle. AFAIK this is not really possible as anythi= ng > specified in fragment is applied to the host! Has anyone faced similar > challenge before? > > > -- > http://about.me/milen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > --=20 http://about.me/milen --001a114545d61b9516052936b551--