Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

Good points BJ! I'll put an App Note together for this.

- Ray

On Mon, May 1, 2017 at 2:07 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:

> Also, the controller component should not register a service.
> "@Component(service={})". If you say "service={}" then you are
> "immediate=true".
>
> Maybe you should make an enroute app note for this?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> <(386)%20848-1781>
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> <(386)%20848-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: Mon, May 1, 2017 2:04 PM
>
> Good one Tim!
>
> Oh, and I forgot to show that the "controller" component should be
> immediate otherwise it will never activate since nothing should "use" it.
>
> - Ray
>
> On Mon, May 1, 2017 at 1:31 PM, Tim Ward <tim.w...@paremus.com> wrote:
>
> For a dynamic import your controller could register a listener so that
> when a suitable package appears in the runtime your disabled component gets
> activated without needing to restart the controller.
>
> Tim
>
> Sent from my iPhone
>
> On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote:
>
>
> Hey All,
> I managed to find a relatively elegant solution to this with pure DS.
>
> Given a component using an optional/dynamic package(s):
>
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable so that DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
>
> A controller is created which does the classloader check:
>
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
>
> componentContext.enableComponent(OptionalPackageConsumer.
> class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
>
> If successful, the component is enabled, otherwise, don't!
>
> - Ray
>
>
>
> On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <
> dirk.fa...@de.bosch.com> wrote:
>
> I totally agree that a clean solution would be to extract the service in
> another bundle with a non optional dependency, as this avoids any runtime
> issues at the beginning by not starting the bundle. Will think about that
> for the Platform Runtime after Oxygen, as such a change is not allowed at
> the current state of the development.
>
>
>
> Nevertheless I created https://bugs.eclipse.org/bugs/
> show_bug.cgi?id=515873 because the NPE is misleading. Whether an
> exception should be shown or not is discussable. Felix is not showing
> anything at all, which also makes it hard to find the reason why the
> service is not activated. Therefore logging the exception is perfectly fine
> in my opinion. But the NPE when using the field strategy looks incorrect to
> me. It doesn’t help anyway to find the real cause.
>
>
>
> Mit freundlichen Grüßen / Best regards
>
> *Dirk Fauth*
>
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49(7153)666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
>
> *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.
> osgi.org] *Im Auftrag von *Thomas Watson
> *Gesendet:* Mittwoch, 26. April 2017 14:38
> *An:* osgi-dev@mail.osgi.org
>
> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>
>
>
>
>
> By Private-Package Peter means he packages the optional package internally
> in the bundle but also optionally imports it so that if it is resolved to
> an external provider then that will be used over the internal copy.  The
> Private-Package header in bnd will instruct bnd to package the package
> internally in the jar.

Re: [osgi-dev] handling optional/dynamic imports in DS

[BJ Hargrave]

Also, the controller component should not register a service. "@Component(service={})". If you say "service={}" then you are "immediate=true".
 
Maybe you should make an enroute app note for this?
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Raymond Auge <raymond.a...@liferay.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] handling optional/dynamic imports in DSDate: Mon, May 1, 2017 2:04 PM 
Good one Tim!
Oh, and I forgot to show that the "controller" component should be immediate otherwise it will never activate since nothing should "use" it. 
- Ray
 
On Mon, May 1, 2017 at 1:31 PM, Tim Ward <tim.w...@paremus.com> wrote:

For a dynamic import your controller could register a listener so that when a suitable package appears in the runtime your disabled component gets activated without needing to restart the controller.
 
Tim
Sent from my iPhone
On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote: 
Hey All,I managed to find a relatively elegant solution to this with pure DS. Given a component using an optional/dynamic package(s):import com.liferay.demo.foo.Foo; // The optional package@Component(    enabled = false // disable so that DS ignores it)public class OptionalPackageConsumer implements Foo {...} A controller is created which does the classloader check:@Componentpublic class OptionalPackageConsumerStarter {   @Activate    void activate(ComponentContext componentContext) {        try {            Class.forName(com.liferay.demo.foo.Foo.class.getName());            componentContext.enableComponent(OptionalPackageConsumer.class.getName());        }        catch (Throwable t) {            _log.warn("Could not find {}", t.getMessage());        }    }} If successful, the component is enabled, otherwise, don't! - Ray

 
 
On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <dirk.fa...@de.bosch.com> wrote:

I totally agree that a clean solution would be to extract the service in another bundle with a non optional dependency, as this avoids any runtime issues at the beginning by not starting the bundle. Will think about that for the Platform Runtime after Oxygen, as such a change is not allowed at the current state of the development.
 
Nevertheless I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=515873 because the NPE is misleading. Whether an exception should be shown or not is discussable. Felix is not showing anything at all, which also makes it hard to find the reason why the service is not activated. Therefore logging the exception is perfectly fine in my opinion. But the NPE when using the field strategy looks incorrect to me. It doesn’t help anyway to find the real cause.
 
Mit freundlichen Grüßen / Best regardsDirk FauthAutomotive Service Solutions, ESI application (AA-AS/EIS2-EU)Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen |  GERMANY |  www.bosch.comTel. +49(7153)666-1155 | dirk.fa...@de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,Christoph Kübel, Uwe Raschke, Peter Tyroller  
Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.osgi.org] Im Auftrag von Thomas WatsonGesendet: Mittwoch, 26. April 2017 14:38An: osgi-dev@mail.osgi.org
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS
 
 
By Private-Package Peter means he packages the optional package internally in the bundle but also optionally imports it so that if it is resolved to an external provider then that will be used over the internal copy.  The Private-Package header in bnd will instruct bnd to package the package internally in the jar.
 
Personally, if I had this scenario I would extract the service component out to a new bundle that has a non-optional import for the package and be done with the magic of dynamic or optional imports.  Or if that is not what you want I would make it a fragment the that has a non-optional import.  That way the bundle with the service component cannot possibly provide its service component until it is resolved.
 
I'm not sure I follow your example that is failing in equinox, but open a bug if you find it is an Equinox bug.
Tom 
 
 
- Original message -From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] handling optional/dynamic imports in DSDate: Wed, Apr 26, 2017 3:02 AM 
Interestingly this works fine when running from Bndtools with Felix.
 

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

Good one Tim!

Oh, and I forgot to show that the "controller" component should be
immediate otherwise it will never activate since nothing should "use" it.

- Ray

On Mon, May 1, 2017 at 1:31 PM, Tim Ward <tim.w...@paremus.com> wrote:

> For a dynamic import your controller could register a listener so that
> when a suitable package appears in the runtime your disabled component gets
> activated without needing to restart the controller.
>
> Tim
>
> Sent from my iPhone
>
> On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Hey All,
> I managed to find a relatively elegant solution to this with pure DS.
>
> Given a component using an optional/dynamic package(s):
>
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable so that DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
>
> A controller is created which does the classloader check:
>
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
>
> componentContext.enableComponent(
> OptionalPackageConsumer.class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
>
> If successful, the component is enabled, otherwise, don't!
>
> - Ray
>
>
>
> On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <
> dirk.fa...@de.bosch.com> wrote:
>
>> I totally agree that a clean solution would be to extract the service in
>> another bundle with a non optional dependency, as this avoids any runtime
>> issues at the beginning by not starting the bundle. Will think about that
>> for the Platform Runtime after Oxygen, as such a change is not allowed at
>> the current state of the development.
>>
>>
>>
>> Nevertheless I created https://bugs.eclipse.org/bugs/
>> show_bug.cgi?id=515873 because the NPE is misleading. Whether an
>> exception should be shown or not is discussable. Felix is not showing
>> anything at all, which also makes it hard to find the reason why the
>> service is not activated. Therefore logging the exception is perfectly fine
>> in my opinion. But the NPE when using the field strategy looks incorrect to
>> me. It doesn’t help anyway to find the real cause.
>>
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>>
>> *Dirk Fauth *
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
>> www.bosch.com
>> Tel. +49(7153)666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com
>>
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr.
>> Volkmar Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
>> Dr. Markus Heyn, Dr. Dirk Hoheisel,
>> Christoph Kübel, Uwe Raschke, Peter Tyroller
>>
>>
>> *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.
>> osgi.org] *Im Auftrag von *Thomas Watson
>> *Gesendet:* Mittwoch, 26. April 2017 14:38
>> *An:* osgi-dev@mail.osgi.org
>>
>> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>>
>>
>>
>> By Private-Package Peter means he packages the optional package
>> internally in the bundle but also optionally imports it so that if it is
>> resolved to an external provider then that will be used over the internal
>> copy.  The Private-Package header in bnd will instruct bnd to package the
>> package internally in the jar.
>>
>>
>>
>> Personally, if I had this scenario I would extract the service component
>> out to a new bundle that has a non-optional import for the package and be
>> done with the magic of dynamic or optional imports.  Or if that is not what
>> you want I would make it a fragment the that has a non-optional import.
>> That way the bundle with the service component cannot possibly provide its
>> service component until it is resolved.
>>
>>
>>
>> I'm not sure I follow your example that is failing in equinox, but open a
>> bug if you find it is an Equinox bug.
>>
>>
>> Tom
>>
>>
>>
>>
>>
>>
>> - Original message -
>> From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bo

Re: [osgi-dev] handling optional/dynamic imports in DS

[Tim Ward]

For a dynamic import your controller could register a listener so that when a 
suitable package appears in the runtime your disabled component gets activated 
without needing to restart the controller.

Tim

Sent from my iPhone

> On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote:
> 
> Hey All,
> I managed to find a relatively elegant solution to this with pure DS.
> 
> Given a component using an optional/dynamic package(s):
> 
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable so that DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
> 
> A controller is created which does the classloader check:
> 
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
> 
> 
> componentContext.enableComponent(OptionalPackageConsumer.class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
> 
> If successful, the component is enabled, otherwise, don't!
> 
> - Ray
> 
> 
> 
>> On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) 
>> <dirk.fa...@de.bosch.com> wrote:
>> I totally agree that a clean solution would be to extract the service in 
>> another bundle with a non optional dependency, as this avoids any runtime 
>> issues at the beginning by not starting the bundle. Will think about that 
>> for the Platform Runtime after Oxygen, as such a change is not allowed at 
>> the current state of the development.
>> 
>>  
>> 
>> Nevertheless I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=515873 
>> because the NPE is misleading. Whether an exception should be shown or not 
>> is discussable. Felix is not showing anything at all, which also makes it 
>> hard to find the reason why the service is not activated. Therefore logging 
>> the exception is perfectly fine in my opinion. But the NPE when using the 
>> field strategy looks incorrect to me. It doesn’t help anyway to find the 
>> real cause.
>> 
>>  
>> 
>> Mit freundlichen Grüßen / Best regards 
>> 
>> Dirk Fauth
>> 
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
>> www.bosch.com 
>> Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com 
>> 
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
>> Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, 
>> Dr. Markus Heyn, Dr. Dirk Hoheisel,
>> Christoph Kübel, Uwe Raschke, Peter Tyroller 
>> 
>> 
>> 
>> Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
>> Im Auftrag von Thomas Watson
>> Gesendet: Mittwoch, 26. April 2017 14:38
>> An: osgi-dev@mail.osgi.org
>> 
>> 
>> Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS
>>  
>> 
>> By Private-Package Peter means he packages the optional package internally 
>> in the bundle but also optionally imports it so that if it is resolved to an 
>> external provider then that will be used over the internal copy.  The 
>> Private-Package header in bnd will instruct bnd to package the package 
>> internally in the jar.
>> 
>>  
>> 
>> Personally, if I had this scenario I would extract the service component out 
>> to a new bundle that has a non-optional import for the package and be done 
>> with the magic of dynamic or optional imports.  Or if that is not what you 
>> want I would make it a fragment the that has a non-optional import.  That 
>> way the bundle with the service component cannot possibly provide its 
>> service component until it is resolved.
>> 
>>  
>> 
>> I'm not sure I follow your example that is failing in equinox, but open a 
>> bug if you find it is an Equinox bug.
>> 
>> 
>> Tom
>>  
>> 
>>  
>> 
>>  
>> 
>> - Original message -
>> From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.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/dyn

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

Hey All,
I managed to find a relatively elegant solution to this with pure DS.

Given a component using an optional/dynamic package(s):

import com.liferay.demo.foo.Foo; // The optional package
@Component(
enabled = false // disable so that DS ignores it
)
public class OptionalPackageConsumer implements Foo {...}

A controller is created which does the classloader check:

@Component
public class OptionalPackageConsumerStarter {
   @Activate
void activate(ComponentContext componentContext) {
try {
Class.forName(com.liferay.demo.foo.Foo.class.getName());


componentContext.enableComponent(OptionalPackageConsumer.class.getName());
}
catch (Throwable t) {
_log.warn("Could not find {}", t.getMessage());
}
}
}

If successful, the component is enabled, otherwise, don't!

- Ray



On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <
dirk.fa...@de.bosch.com> wrote:

> I totally agree that a clean solution would be to extract the service in
> another bundle with a non optional dependency, as this avoids any runtime
> issues at the beginning by not starting the bundle. Will think about that
> for the Platform Runtime after Oxygen, as such a change is not allowed at
> the current state of the development.
>
>
>
> Nevertheless I created https://bugs.eclipse.org/bugs/
> show_bug.cgi?id=515873 because the NPE is misleading. Whether an
> exception should be shown or not is discussable. Felix is not showing
> anything at all, which also makes it hard to find the reason why the
> service is not activated. Therefore logging the exception is perfectly fine
> in my opinion. But the NPE when using the field strategy looks incorrect to
> me. It doesn’t help anyway to find the real cause.
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dirk Fauth *
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49(7153)666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
> *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.
> osgi.org] *Im Auftrag von *Thomas Watson
> *Gesendet:* Mittwoch, 26. April 2017 14:38
> *An:* osgi-dev@mail.osgi.org
>
> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>
>
>
> By Private-Package Peter means he packages the optional package internally
> in the bundle but also optionally imports it so that if it is resolved to
> an external provider then that will be used over the internal copy.  The
> Private-Package header in bnd will instruct bnd to package the package
> internally in the jar.
>
>
>
> Personally, if I had this scenario I would extract the service component
> out to a new bundle that has a non-optional import for the package and be
> done with the magic of dynamic or optional imports.  Or if that is not what
> you want I would make it a fragment the that has a non-optional import.
> That way the bundle with the service component cannot possibly provide its
> service component until it is resolved.
>
>
>
> I'm not sure I follow your example that is failing in equinox, but open a
> bug if you find it is an Equinox bug.
>
>
> Tom
>
>
>
>
>
>
> - Original message -
> From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.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: Wed, Apr 26, 2017 3:02 AM
>
>
> Interestingly this works fine when running from Bndtools with Felix.
>
>
>
> If I try the same with Equinox for projects created with PDE I get a
> NullPointerException. IIRC Private-Package is something special to Bnd. Is
> that correct? I wonder if that exception is caused by some PDE flaws or if
> it is an issue in Equinox Oxygen. In both cases Apache Felix SCR 2.0 is
> used. (in Oxygen 2.0.8 and in Bndtools 2.0.2)
>
>
>
> *org.osgi.framework.ServiceException*: Exception in
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
>
>at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.
> factoryGetService(*ServiceFactoryUse.java:222*)
>
>at org.eclipse.osgi.internal.serviceregistry.
> ServiceFactoryUse.getService(*ServiceFacto

Re: [osgi-dev] handling optional/dynamic imports in DS

[Fauth Dirk (AA-AS/EIS2-EU)]

I totally agree that a clean solution would be to extract the service in 
another bundle with a non optional dependency, as this avoids any runtime 
issues at the beginning by not starting the bundle. Will think about that for 
the Platform Runtime after Oxygen, as such a change is not allowed at the 
current state of the development.

Nevertheless I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=515873 
because the NPE is misleading. Whether an exception should be shown or not is 
discussable. Felix is not showing anything at all, which also makes it hard to 
find the reason why the service is not activated. Therefore logging the 
exception is perfectly fine in my opinion. But the NPE when using the field 
strategy looks incorrect to me. It doesn’t help anyway to find the real cause.

Mit freundlichen Grüßen / Best regards

Dirk Fauth

Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
www.bosch.com<http://www.bosch.com>
Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im 
Auftrag von Thomas Watson
Gesendet: Mittwoch, 26. April 2017 14:38
An: osgi-dev@mail.osgi.org
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS

By Private-Package Peter means he packages the optional package internally in 
the bundle but also optionally imports it so that if it is resolved to an 
external provider then that will be used over the internal copy.  The 
Private-Package header in bnd will instruct bnd to package the package 
internally in the jar.

Personally, if I had this scenario I would extract the service component out to 
a new bundle that has a non-optional import for the package and be done with 
the magic of dynamic or optional imports.  Or if that is not what you want I 
would make it a fragment the that has a non-optional import.  That way the 
bundle with the service component cannot possibly provide its service component 
until it is resolved.

I'm not sure I follow your example that is failing in equinox, but open a bug 
if you find it is an Equinox bug.

Tom



- Original message -
From: "Fauth Dirk (AA-AS/EIS2-EU)" 
<dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>>
Sent by: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org>
To: OSGi Developer Mail List 
<osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>>
Cc:
Subject: Re: [osgi-dev] handling optional/dynamic imports in DS
Date: Wed, Apr 26, 2017 3:02 AM


Interestingly this works fine when running from Bndtools with Felix.



If I try the same with Equinox for projects created with PDE I get a 
NullPointerException. IIRC Private-Package is something special to Bnd. Is that 
correct? I wonder if that exception is caused by some PDE flaws or if it is an 
issue in Equinox Oxygen. In both cases Apache Felix SCR 2.0 is used. (in Oxygen 
2.0.8 and in Bndtools 2.0.2)



org.osgi.framework.ServiceException: Exception in 
org.apache.felix.scr.impl.manager.SingleComponentManager.getService()

   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222)

   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)

   at 
org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)

   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)

   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)

   at 
org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)

   at 
org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)

   at 
org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985)

   at 
org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201)

   at 
org.apache.felix.scr.impl.manager.DependencyManager$MultipleStaticReluctantCustomizer.prebind(DependencyManager.java:699)

   at 
org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520)

   at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006)

   at 
org.apache.felix.scr.impl.manager.SingleComponentManage

Re: [osgi-dev] handling optional/dynamic imports in DS

[Fauth Dirk (AA-AS/EIS2-EU)]

Looks like that was the misunderstanding on my side how Private-Package works. 
Actually I don’t know how to include packages from other bundles in another 
bundle with PDE. Not even sure if there is an easy way.

Thanks for the pointer. I learned something new on Bndtools. ☺

But I also noticed that there is no exception when removing the Private-Package 
statement. The service in charge is simply not activated.

Mit freundlichen Grüßen / Best regards

Dirk Fauth

Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
www.bosch.com<http://www.bosch.com>
Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im 
Auftrag von Peter Kriens
Gesendet: Mittwoch, 26. April 2017 15:19
An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS

How do you include the org.osgi.service.cm package? This is trivial in bnd but 
I recall it was tricky in PDE?

Did you verify that the package is inside the bundle?

Kind regards,

Peter Kriens

On 26 Apr 2017, at 10:02, Fauth Dirk (AA-AS/EIS2-EU) 
<dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>> wrote:

Interestingly this works fine when running from Bndtools with Felix.

If I try the same with Equinox for projects created with PDE I get a 
NullPointerException. IIRC Private-Package is something special to Bnd. Is that 
correct? I wonder if that exception is caused by some PDE flaws or if it is an 
issue in Equinox Oxygen. In both cases Apache Felix SCR 2.0 is used. (in Oxygen 
2.0.8 and in Bndtools 2.0.2)

org.osgi.framework.ServiceException: Exception in 
org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
   at 
org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)
   at 
org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)
   at 
org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985)
   at 
org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201)
   at 
org.apache.felix.scr.impl.manager.DependencyManager$MultipleStaticReluctantCustomizer.prebind(DependencyManager.java:699)
   at 
org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520)
   at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
   at 
org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)
   at 
org.apache.felix.gogo.runtime.CommandProxy.getTarget(CommandProxy.java:50)
   at 
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:72)
   at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
   at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
   at org.apache.felix.gogo.

Re: [osgi-dev] handling optional/dynamic imports in DS

[Peter Kriens]

Proxy.java:82)
>at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
>at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>at 
> org.apache.felix.scr.impl.inject.FieldHandler.validateField(FieldHandler.java:279)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler.access$500(FieldHandler.java:51)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.resolve(FieldHandler.java:839)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.fieldExists(FieldHandler.java:864)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler.fieldExists(FieldHandler.java:918)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler$3.init(FieldHandler.java:1018)
>at 
> org.apache.felix.scr.impl.manager.DependencyManager.invokeInitMethod(DependencyManager.java:1657)
>at 
> org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1533)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:261)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
>at java.security.AccessController.doPrivileged(Native Method)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
>... 46 more
>  
> Mit freundlichen Grüßen / Best regards 
> 
> Dirk Fauth
> 
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
> www.bosch.com <http://www.bosch.com/> 
> Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com 
> <mailto:dirk.fa...@de.bosch.com> 
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
> Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller 
> 
> 
> Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> Im Auftrag von Peter Kriens
> Gesendet: Mittwoch, 26. April 2017 09:14
> An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS
>  
> I used to import the package optional and then provide it as an internal 
> Private-Package. The import has priority but the internal package is used 
> when the import fails to resolve. Since you’re then always wired to a package 
> you can handle dependencies on the place they should be handled: services.
>  
> This keeps everybody happy internally for very little cost. I’ve included a 
> bndtools/enRoute example.
>  
> Kind regards,
>  
> Peter Kriens
>  
>  
> — bnd.bnd
> Private-Package: \
> org.osgi.service.cm,\
> com.foo.provider
>  
> Import-Package: \
> org.osgi.service.cm;resolution:=optional,\
> *
>  
> -buildpath: \
> osgi.enroute.base.api
> -runrequires: \
> osgi.identity;filter:='(osgi.identity=com.foo.provider)',\
> 
> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\
> 
> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
> 
> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'
> -runbundles: \
> com.foo.provider;version=snapshot,\
> org.apache.felix.log;version='[1.0.1,1.0.2)',\
> org.apache.felix.scr;version='[2.0.2,2.0.3)',\
> org.a

Re: [osgi-dev] handling optional/dynamic imports in DS

[Thomas Watson]

.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
   at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
   at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
   at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
   at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
   at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
   at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
   at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
   at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
   at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
   at org.apache.felix.scr.impl.inject.FieldHandler.validateField(FieldHandler.java:279)
   at org.apache.felix.scr.impl.inject.FieldHandler.access$500(FieldHandler.java:51)
   at org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.resolve(FieldHandler.java:839)
   at org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.fieldExists(FieldHandler.java:864)
   at org.apache.felix.scr.impl.inject.FieldHandler.fieldExists(FieldHandler.java:918)
   at org.apache.felix.scr.impl.inject.FieldHandler$3.init(FieldHandler.java:1018)
   at org.apache.felix.scr.impl.manager.DependencyManager.invokeInitMethod(DependencyManager.java:1657)
   at org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1533)
   at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:261)
   at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109)
   at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)
   at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)
   at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
   at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
   ... 46 more
 
Mit freundlichen Grüßen / Best regards Dirk FauthAutomotive Service Solutions, ESI application (AA-AS/EIS2-EU)Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen |  GERMANY |  www.bosch.comTel. +49(7153)666-1155 | dirk.fa...@de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,Christoph Kübel, Uwe Raschke, Peter Tyroller 
Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Peter KriensGesendet: Mittwoch, 26. April 2017 09:14An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS
 
I used to import the package optional and then provide it as an internal Private-Package. The import has priority but the internal package is used when the import fails to resolve. Since you’re then always wired to a package you can handle dependencies on the place they should be handled: services.
 
This keeps everybody happy internally for very little cost. I’ve included a bndtools/enRoute example.
 
Kind regards,
 
    Peter Kriens
 
 
— bnd.bnd
Private-Package: \
    org.osgi.service.cm,\
    com.foo.provider
 
Import-Package: \
    org.osgi.service.cm;resolution:=optional,\
    *
 
-buildpath: \
    osgi.enroute.base.api
-runrequires: \
    osgi.identity;filter:='(osgi.identity=com.foo.provider)',\
    osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\
    osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
    osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'
-runbundles: \
    com.foo.provider;version=snapshot,\
    org.apache.felix.log;version='[1.0.1,1.0.2)',\
    org.apache.felix.scr;version='[2.0.2,2.0.3)',\
    org.apache.felix.gogo.runtime,\
    org.apache.felix.gogo.shell;version=0.16
 
— com.foo.provider.Optional
@Component
public class Optional
{
   @Reference(cardinality=ReferenceCardinality.OPT

Re: [osgi-dev] handling optional/dynamic imports in DS

[Fauth Dirk (AA-AS/EIS2-EU)]

)
   at 
org.apache.felix.scr.impl.inject.FieldHandler.access$500(FieldHandler.java:51)
   at 
org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.resolve(FieldHandler.java:839)
   at 
org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.fieldExists(FieldHandler.java:864)
   at 
org.apache.felix.scr.impl.inject.FieldHandler.fieldExists(FieldHandler.java:918)
   at 
org.apache.felix.scr.impl.inject.FieldHandler$3.init(FieldHandler.java:1018)
   at 
org.apache.felix.scr.impl.manager.DependencyManager.invokeInitMethod(DependencyManager.java:1657)
   at 
org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1533)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:261)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)
   at 
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
   ... 46 more

Mit freundlichen Grüßen / Best regards

Dirk Fauth

Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
www.bosch.com<http://www.bosch.com>
Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im 
Auftrag von Peter Kriens
Gesendet: Mittwoch, 26. April 2017 09:14
An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS

I used to import the package optional and then provide it as an internal 
Private-Package. The import has priority but the internal package is used when 
the import fails to resolve. Since you’re then always wired to a package you 
can handle dependencies on the place they should be handled: services.

This keeps everybody happy internally for very little cost. I’ve included a 
bndtools/enRoute example.

Kind regards,

Peter Kriens


— bnd.bnd
Private-Package: \
org.osgi.service.cm,\
com.foo.provider

Import-Package: \
org.osgi.service.cm;resolution:=optional,\
*

-buildpath: \
osgi.enroute.base.api
-runrequires: \
osgi.identity;filter:='(osgi.identity=com.foo.provider)',\

osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\

osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\

osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'
-runbundles: \
com.foo.provider;version=snapshot,\
org.apache.felix.log;version='[1.0.1,1.0.2)',\
org.apache.felix.scr;version='[2.0.2,2.0.3)',\
org.apache.felix.gogo.runtime,\
org.apache.felix.gogo.shell;version=0.16

— com.foo.provider.Optional
@Component
public class Optional
{
   @Reference(cardinality=ReferenceCardinality.OPTIONAL)
   ConfigurationAdmin admin;

   @Activate
   void activate() {
  System.out.println("activate " + admin);
   }
}

On 25 Apr 2017, at 23:10, Raymond Auge 
<raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote:

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

___

Re: [osgi-dev] handling optional/dynamic imports in DS

[Fauth Dirk (AA-AS/EIS2-EU)]

After thinking about class loading I modified the SimpleServiceImpl so the not 
available class is loaded at instantiation time (sometimes I need to remember 
classloading mechanics)

@Component
public class SimpleServiceImpl implements SimpleService {

   SimpleHelper helper = new SimpleHelper();

   @Override
   public String calculateSomething(String input) {
 helper.doSomething();
 return "SimpleServiceImpl calculated something with " + input;
   }

}

This leads to a ClassNotFoundException at activation time. But the command is 
executing with the one correct service. Consecutive calls to the command lead 
to a NoClassDefFoundError.

So in that case the command execution is not avoided and the runtime does not 
stop. Only thing that is not nice is that the exception is raised all the time. 
But probably that could be avoided with a proper design.

Mit freundlichen Grüßen / Best regards

Dirk Fauth

Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
www.bosch.com<http://www.bosch.com>
Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im 
Auftrag von Fauth Dirk (AA-AS/EIS2-EU)
Gesendet: Mittwoch, 26. April 2017 08:47
An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS

Hi,

not sure if this answers your question, but actually I thought of something 
similar for the Eclipse Platform Runtime.

The issue I am seeing there is probably an incorrect bundle design where 
service interfaces and default implementations of the services are in one 
bundle. Well, it could be discussed if this is sometimes ok, but that should 
not be part of this discussion. In the end it would not be an issue when the 
services are referenced dynamic greedy so one could simple register a service 
with a higher ranking to override the default.

The bad thing at the moment is that some of these service implementations are 
dependent on Equinox, as they use classes from the org.eclipse.osgi.service.* 
packages. With non-optional Import-Package statements that means the Eclipse 
Platform Runtime needs Equinox OSGi to run. From my point of view that 
dependency is too strict for that project and it should be possible to also 
start it with another OSGi implementation.

Therefore I was thinking about making these imports optional, so the bundles at 
least start without throwing wiring errors. It would of course mean on the 
other hand that those default service implementations are not getting activated 
because the required classes are not found. But that could be solved afterwards 
by adaptors that want to run on a different OSGi implementation.

But even a simple test turned out that this is not working as intended. SCR 
loads the XML and even activates the component. At execution time of the 
service there is a NoClassDefFoundError. The expectation (even from BJ’s 
answer) would be that SCR does not even activate the service implementation 
because the class cannot be loaded.

I created the following test scenario:

Bundle: org.fipro.test.helper
Public Package: org.fipro.test.helper
Helper-Class:
public class SimpleHelper {

   public static void doSomething() {
 System.out.println("do something");
   }
}

Bundle: org.fipro.test.service
Private Package: org.fipro.test.service
Import-Package: org.fipro.test.helper (optional)

public interface SimpleService {

   String calculateSomething(String input);
}

@Component
public class SimpleServiceImpl implements SimpleService {

   @Override
   public String calculateSomething(String input) {
 SimpleHelper.doSomething();
 return "SimpleServiceImpl calculated something with " + input;
   }

}

@Component
public class TestServiceImpl implements SimpleService {

   @Override
   public String calculateSomething(String input) {
 return "TestServiceImpl calculated something with " + input;
   }

}

@Component(
 property= {
   "osgi.command.scope:String=fipro",
   "osgi.command.function:String=simple"
},
service=SimpleServiceCommand.class)
public class SimpleServiceCommand {

   @Reference
   List services;

   public void simple(String input) {
 System.out.println("number of services: " + services.size());
   

Re: [osgi-dev] handling optional/dynamic imports in DS

[Peter Kriens]

I used to import the package optional and then provide it as an internal 
Private-Package. The import has priority but the internal package is used when 
the import fails to resolve. Since you’re then always wired to a package you 
can handle dependencies on the place they should be handled: services.

This keeps everybody happy internally for very little cost. I’ve included a 
bndtools/enRoute example.

Kind regards,

Peter Kriens


— bnd.bnd
Private-Package: \
org.osgi.service.cm,\
com.foo.provider

Import-Package: \
org.osgi.service.cm;resolution:=optional,\
*

-buildpath: \
osgi.enroute.base.api
-runrequires: \
osgi.identity;filter:='(osgi.identity=com.foo.provider)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'
-runbundles: \
com.foo.provider;version=snapshot,\
org.apache.felix.log;version='[1.0.1,1.0.2)',\
org.apache.felix.scr;version='[2.0.2,2.0.3)',\
org.apache.felix.gogo.runtime,\
org.apache.felix.gogo.shell;version=0.16

— com.foo.provider.Optional
@Component
public class Optional
{
   @Reference(cardinality=ReferenceCardinality.OPTIONAL)
   ConfigurationAdmin admin;

   @Activate
   void activate() {
  System.out.println("activate " + admin);
   }
}

> On 25 Apr 2017, at 23:10, Raymond Auge  wrote:
> 
> 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

Re: [osgi-dev] handling optional/dynamic imports in DS

[Fauth Dirk (AA-AS/EIS2-EU)]

<mailto:dirk.fa...@de.bosch.com>

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im 
Auftrag von Felix Meschberger
Gesendet: Mittwoch, 26. April 2017 04:14
An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS

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<mailto: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<mailto:hargr...@us.ibm.com>


- Original message -
From: Raymond Auge <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>>
Sent by: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org>
To: OSGi Developer Mail List 
<osgi-dev@mail.osgi.org<mailto: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<mailto: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<mailto: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<mailto:raymond.a...@liferay.com>>:

Thank you Felix, I agree and understand all of what you are saying.

However, what I'm wonder

Re: [osgi-dev] handling optional/dynamic imports in DS

[Felix Meschberger]

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 

Re: [osgi-dev] handling optional/dynamic imports in DS

[BJ Hargrave]

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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Raymond Auge Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: Re: [osgi-dev] handling optional/dynamic imports in DSDate: Tue, Apr 25, 2017 6:20 PM 
 
 
On Tue, Apr 25, 2017 at 6:16 PM, Christian Schneider  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 packageit 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: @Componentclass 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;@Componentclass 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  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 : 

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   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 :
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 Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev--
Raymond Augé (@rotty3000)
Senior Software 

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

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 
> 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 :
>>
>> 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 
>> 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 :
>>>
>>> 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 

Re: [osgi-dev] handling optional/dynamic imports in DS

[Christian Schneider]

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?

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 > 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
>:

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
> 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
>:

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

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

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 
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 :
>
> 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 
> 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 :
>>
>> 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

Re: [osgi-dev] handling optional/dynamic imports in DS

[Felix Meschberger]

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 
>:

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 
> 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 
>:

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

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

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 
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 :
>
> 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

Re: [osgi-dev] handling optional/dynamic imports in DS

[Felix Meschberger]

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 
>:

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