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é* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>> (@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é* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>> (@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é* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
>
> _______________________________________________
> OSGi Developer Mail
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Christian Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
