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 4212917D2D for ; Thu, 16 Oct 2014 08:11:18 +0000 (UTC) Received: (qmail 48416 invoked by uid 500); 16 Oct 2014 08:11:17 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 48351 invoked by uid 500); 16 Oct 2014 08:11:17 -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 48340 invoked by uid 99); 16 Oct 2014 08:11:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 08:11:17 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.145.109.42] (HELO smtp1romandie.alinto.net) (83.145.109.42) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 08:10:50 +0000 X-Virus-Scanned: amavisd-new at alinto.net Received: from [192.168.18.51] (62-2-128-54.static.cablecom.ch [62.2.128.54]) (Authenticated sender: philipp.buluschek@romandie.com) by smtp1romandie.alinto.net (Postfix) with ESMTPA id 4CF4831C65A for ; Thu, 16 Oct 2014 10:10:48 +0200 (CEST) Message-ID: <543F7D9F.4040705@romandie.com> Date: Thu, 16 Oct 2014 10:11:11 +0200 From: Bulu User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: users@felix.apache.org Subject: Re: DependencyManager: notify third party object of changed adaptee properties References: <29FBA46A464316449BF990BA4D74D578052FECF7D89E@HE113607.emea1.cds.t-internal.com> <95CA7681-E8A9-4E2A-BD27-E297D407FCAC@adobe.com> <29FBA46A464316449BF990BA4D74D578052FECF7DB80@HE113607.emea1.cds.t-internal.com> <29FBA46A464316449BF990BA4D74D578052FECF7DC4E@HE113607.emea1.cds.t-internal.com> <542ADF46.9070209@romandie.com> <542AEC8C.2070708@romandie.com> <542BAEA2.5080405@romandie.com> <543E6496.1040000@romandie.com> <543E6E0A.4080309@romandie.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hello Pierre Thanks for coming up with this solution. I will try it out. The only downside I see, is that bundle-internal objects (the adapters) are published on the framework, so we lose a bit of encapsulation, but I can live with that. About the usage of the DeviceManager: I want to show devices with their properties in a Vaadin GUI, for this, they must be collected in a Container which is linked to the Widget (a Tree). So two things need to happen: 1. for each Device appearing, create a DeviceAdapter which is of a convenient form (a Bean) for the Vaadin framework to use, and which forwards calls to the actual Device 2. for each DeviceAdapter created, add it to the Container (and remove when disappearing...). The DeviceManager holds the Container and adds/removes the adapters in it. For separation of concerns, I didn't want the DeviceAdapters to directly hold a reference to the deviceManager/container (ie. they should not add/remove themselves). Now I also want to track changes in the properties (which do not destroy the adapter, its filter is still met), so that I can update the container (a typical property which might change is the "parent" node in the tree widget). So it is also the DeviceManager which needs to get these property change notifications. I will file a Jira request. I guess the difficulty might lie in the fact that you will have to distinguish two case: 1. adaptee property change which make the adapter disappear (filter no longer met) 2. adaptee property change but adapter is kept - so call callbacks on itself or third party object Regards Philipp On 16.10.2014 08:50, Pierre De Rop wrote: > Hello Philipp, > > I think that currently, it is not possible to specify a third party > callback object to be notified when the adaptee services properties are > changed, and only your adapter will be notified. > > One possible alternative could consist in letting the adapter impl provide > an adapted interface and you could then track the adapted interface itself, > because when the adaptee (Device) service properties are changed, the > Device changed properties are then also propagated to the service > properties provided by the adapter (if the adapter provides an adapted > service). > > For example, when you create your adapter, you can manage to let it provide > a service (like 'DeviceAdapter' service): > > mgr.add(createAdapterService(Device.class,null) > .setImplementation(DeviceAdapter.class) > .setInterface(DeviceAdapter.class, null) > .setCallbacks("init", "start", "stop", "destroy")); > > Then you could manage to define your "DeviceManager" as a DM component, and > that component could listen to all DeviceAdapter services, including > propagated service properties change events: > > mgr.add(createComponent() > .setImplementation(DeviceManager.class) > .add(createServiceDependency(DeviceAdapter.class).setRequired(true) > .setCallbacks("added", "changed", "removed))); > > then your DeviceManager could be called back it its changed method when a > DeviceAdapter propagates its adapted Device service properties change > events. > > This should work, but I don't know if this would be compatible with your > current application design ? > (maybe you could describe a but what is doing your DeviceManager ?) > > Now unfortunately, regarding your last question, I think that the work > around won't work, because when the adaptee services comes up, the first > dependency (the one that your work around has modified) is removed and > replaced by another dependency (see the AdapterServiceImpl. > AdapterImpl.createService() method()). > > Now, if you really need to be able to specify a callback instance to be > called when the adaptee service properties are changed (Device), then can > you please create a Jira issue for it, and I will add a > createAdapterService signature allowing to specify a callbackObject, > similar to what is currently done int the createResourceAdapterService > methods. > (Marcel, would you be OK for this new feature ?) > > kind regards; > /Pierre > > On Wed, Oct 15, 2014 at 2:52 PM, Bulu wrote: > >> Addition to my own question: >> I came up with the following, but the callbacks seem not to get called on >> the deviceManager... >> >> Component adapter = createAdapterService(Device.class,null) >> .setImplementation(DeviceAdapter.class) >> .setCallbacks(deviceManager, INIT_METHOD, START_METHOD, STOP_METHOD, >> DESTROY_METHOD); >> >> // Ugly: supposing the adapter has always the adaptee as first service >> dependency >> ServiceDependency dep = (ServiceDependency) adapter.getDependencies().get( >> 0); >> logger.debug("Dependency is {}", dep); // OK, in my tests it's the right >> dependency >> dep.setCallbacks(deviceManager, BIND_METHOD, CHANGED_METHOD, >> UNBIND_METHOD); >> mgr.add(adapter); >> >> Is this the right way? >> >> Regards Philipp >> >> >> On 15.10.2014 14:12, Bulu wrote: >> >>> Hello All >>> >>> Using Dependency Manager, I declare adapters like this: >>> mgr.add(createAdapterService(Device.class,null) >>> .setImplementation(DeviceAdapter.class) >>> .setCallbacks(deviceManager, "init", "start", "stop", "destroy")); >>> >>> So deviceManager gets notified when the adapters appear. Now I also want >>> deviceManager to be notified when the properties of any of the adaptees >>> (Device.class) change (need to update the UI). >>> >>> For normal ServiceDependency I can specify callbacks to be called on a >>> third party object with >>> ServiceDependency.setCallbacks(Object instance, String added, String >>> changed, String removed); >>> >>> For adapters and I can specify the callbacks, but only calling the >>> adapter itself: >>> createAdapterService(Device.class.name, null, "add", "change", >>> "remove") >>> >>> How can I tell the adapter to use callbacks on a third party object >>> (deviceManager) when the adaptee's properties change? >>> >>> Thanks & regards >>> Philipp >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org >> For additional commands, e-mail: users-help@felix.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org