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 <[email protected]>
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 <[email protected]>:
>
> 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 <[email protected]>
> 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 <[email protected]>:
>>
>> 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
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> 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
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> 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
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
