My understanding is as well that this is exactly how DS works.
But I think Rays question goes further into supporting situations in a way
that a component activates and registers dynamically depending on what service
interface is actually available.
I think this does not work with plain DS but requires additional logic to check
for wires and/or trying to load classes. The Apache Felix
ScrServiceServiceFactory does this being registered as a ServiceFactory by the
BundleActivator ScrConfiguration. The latter could be a component (here it is a
BundleActivator because this is the DS implementation itself).
Yet this is really a special case of a situation which is not covered by DS and
which probably is outside of the scope of DS' charter.
Regards
Felix
--
Creative typing support courtesy of my iPhone
> Am 25.04.2017 um 15:47 schrieb BJ Hargrave <hargr...@us.ibm.com>:
>
> 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
>
>
> ----- 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:
>> You're not far off,
>>
>> but clearly the component could not be implementing the missing package...
>>
>> Let's say we have an API:
>>
>> interface com.foo.Provider {
>> public void provide();
>> }
>>
>> a bundle wants to provide an implementation of this API:
>>
>> @Component
>> class FancyProviderImpl implements com.foo.Provider { ... }
>>
>> However the goal of FancyProviderImpl is to deliver functionality by using
>> fancy-lib.jar which is a second bundle.
>>
>> e.g.
>>
>> import fancy.lib.Thing;
>> @Component
>> class FancyProviderImpl implements com.foo.Provider {
>> public void provide() {
>> new Thing().doSomethingFancy();
>> }
>> }
>>
>> 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,
>> - Ray
>>
>>
>> On Tue, Apr 25, 2017 at 5:51 PM, Felix Meschberger <fmesc...@adobe.com>
>> wrote:
>> Hi Ray
>>
>> I 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.
>>
>> Regards
>> Felix
>>
>>> Am 25.04.2017 um 14:46 schrieb Raymond Auge <raymond.a...@liferay.com>:
>>>
>>> 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.
>>>
>>> Sincerely,
>>> - Ray
>>>
>>> On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger <fmesc...@adobe.com>
>>> wrote:
>>> Hi
>>>
>>> You 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 helps
>>>
>>> Regards
>>> Felix
>>>
>>>> Am 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.
>>>>
>>>> Sincerely,
>>>> --
>>>> Raymond Augé (@rotty3000)
>>>> Senior Software Architect Liferay, Inc. (@Liferay)
>>>> 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)
>>> Senior Software Architect Liferay, Inc. (@Liferay)
>>> 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)
>> Senior Software Architect Liferay, Inc. (@Liferay)
>> 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)
> Senior Software Architect Liferay, Inc. (@Liferay)
> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
