So why isn't this just the case already? SCR processes the XML, cannot load the impl class and logs that in the log. End of story. When bundle resolves again later and can access the class, when SCR processes the XML, it can load the impl class and thus the component is good to go.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
----- Original message -----
From: Raymond Auge <raymond.a...@liferay.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] handling optional/dynamic imports in DS
Date: Tue, Apr 25, 2017 6:20 PM
On Tue, Apr 25, 2017 at 6:16 PM, Christian Schneider <ch...@die-schneider.net> wrote:Not sure if that is possible...
I think it would be awesome if the DS runtime could try to load the component class and if it fails because of an unwired package
it could simply choose to not instantiate the component. It could also report this problem when you look into the components from the shell.
When the bundle is then refreshed later it could try the same again and maybe succeed if the package is wired now.
The big advantage would be that the user would not have to code anything to make this work.
Currently handling optional imports using an Activator is quite difficult and error prone.
Does that make sense?I totally agree!
- Ray
Christian
On 26.04.2017 00:06, Raymond Auge wrote:new Thing().doSomethingFancy();e.g.However the goal of FancyProviderImpl is to deliver functionality by using fancy-lib.jar which is a second bundle.class FancyProviderImpl implements com.foo.Provider { ... }@Componentinterface com.foo.Provider {You're not far off,Let's say we have an API:
but clearly the component could not be implementing the missing package...
public void provide();}a bundle wants to provide an implementation of this API:
import fancy.lib.Thing;
@Component
class FancyProviderImpl implements com.foo.Provider {
public void provide() {}
}
I'd like for the bundle containing FancyProviderImpl to have an optional import on `fancy.lib`, and not blow up when `fancy-lib.jar` is not deployed. Exactly the same scenario you mentioned with configAdmin, metatype and SCR.
I hope that makes sense,- RayOn Tue, Apr 25, 2017 at 5:51 PM, Felix Meschberger <fmesc...@adobe.com> wrote:Hi RayI am not sure, I understand the question.Are you asking that the component dynamically decides to register as a certain service depending on the whether a certain package is wired ?I think that does not work as the component implements an interface which is the service name and the component class can only be loaded if the class object representing the interface being implemented is accessible, otherwise a Linkage error occurrs.Or may I am on the wrong track alltogether.RegardsFelixAm 25.04.2017 um 14:46 schrieb Raymond Auge <raymond.a...@liferay.com>:- RaySincerely,Thank you Felix, I agree and understand all of what you are saying.However, what I'm wondering though is if anyone has come up with a design pattern where a DS component can determine programmatically whether it (or a peer component it controls) should be provided as a service based on the check for some optional package.
______________________________On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger <fmesc...@adobe.com> wrote:HiYou mean dynamic imports due to optional dependencies ?I think the key is to limit them. If I remember correctly I have (or had) some of this in the Apache Felix SCR implementation around the Metatype and Configuration Admin dependencies.What I do is I hand-craft a DynamicImport-Package statement for the exact package along with the packages import version range. Then, unless the service is provided, the package may not be resolved.I generally also have fields, but as long as I don’t access that field other than checking for null, the dependency is not needed either.This works great, but I try to reduce such uses to the absolute minimum because it involves manual work.Hope this helpsRegardsFelixAm 25.04.2017 um 14:10 schrieb Raymond Auge <raymond.a...@liferay.com>:______________________________I'm wondering if there is a reasonable model for handling optional or dynamic package imports in DS.While optionality at the package level is not an ideal model, sometimes it can't be avoided.
I'd like to know if others have come across a "reasonable" way to model this in DS._________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--Raymond Augé (@rotty3000) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)_________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--Raymond Augé (@rotty3000) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--Raymond Augé (@rotty3000) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
