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<mailto: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<mailto: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<mailto: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<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto: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<mailto: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
