Re: [osgi-dev] Declarative services and optional imports

[Bernd Eckenfels via osgi-dev]

Is BarService part of that optional (implementation) bundle? I don’t  think 
that is supposed to work. It needs to be a import resolved from an always 
present (API) bundle.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> on behalf 
of Robert Munteanu via osgi-dev <osgi-dev@mail.osgi.org>
Sent: Tuesday, November 21, 2017 2:28:16 PM
To: OSGi Developer Mail List
Subject: [osgi-dev] Declarative services and optional imports

Hi,

I have an SCR component that references a service, with 0...1
cardinality. That service is part of an optional import. The aim is
that if the package is available at runtime, the reference is bound,
otherwise not, but the component functions without it, e.g.


@Component public class SomeComponent {

@Reference private FooService foo;

@Reference(cardinality = OPTIONAL_UNARY ) private BarService bar;

}

The result though is that the component bind method lookups fail, e.g.:

Failure loooking up method
bindFoo(org.osgi.framework.ServiceReference) in class
com.example.SomeComponent. Assuming no such method.
(java.lang.NoClassDefFoundError: com/example/optional/BarService)

What's interesting is that the 'foo' reference is not part of an
optional import, the class is visible and the reference is there.
Obviously in this scenario the optional import for BarService is not
satisfied and the class it not available.

I'm running org.apache.felix.scr from the latest OSGi-r7 folder -
https://svn.apache.org/repos/asf/felix/trunk/osgi-r7/scr/ .

So my questions are:

1. Is this scenario something that SCR can support?
2. If the answer above is no, what is the best way of achieving the
result? Splitting the bundle is unfortunately quite tedious so I'd
like to avoid that.

Thanks,

Robert

--
http://robert.muntea.nu/
___
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] Declarative services and optional imports

[Robert Munteanu via osgi-dev]

Hi Ray,

On Tue, Nov 21, 2017 at 4:34 PM, Raymond Auge  wrote:
> Hey Robert,
>
> We had the same use case and solved it the following way:
>
> Given your component which has the optional import package (doesn't matter
> how it's used):
>
> import com.liferay.demo.foo.Foo; // The optional package
>
> @Component(
> enabled = false // disable by default so DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
>
>
> Make sure the component is disabled by default. This will prevent SCR from
> classloading the component class.
>
> Second, you construct a "starter" component who's job it is to check for the
> available package:
>
> @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());
> }
> }
> }
>
> Sure, it's more work and the logic above is not perfect because you may not
> want the "starter" component to start when the package is unavailable. But
> this basic idea has worked for us.

That's a very cool solution, and does exactly what I want.

Thanks!

Robert
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Raymond Auge via osgi-dev]

Hey Robert,

We had the same use case and solved it the following way:

Given your component which has the optional import package (doesn't matter
how it's used):

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

Make sure the component is *disabled* by default. This will prevent
SCR from classloading the component class.

Second, you construct a "starter" component who's job it is to check
for the available package:

@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());
}
}
}

Sure, it's more work and the logic above is not perfect because you
may not want the "starter" component to start when the package is
unavailable. But this basic idea has worked for us.

- Ray


On Tue, Nov 21, 2017 at 9:16 AM, Robert Munteanu via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> On Tue, Nov 21, 2017 at 4:00 PM, Christian Schneider
>  wrote:
> > I think it can not work with a simple optional import. What could work
> is a
> > separate component that has
> > the optional class as a mandatory reference.
> >
> > This component could then be injected into your component with an
> optional
> > reference and with an interface that is independent of the optional
> import.
>
> That's a good point. Sadly I can't use this approach since it's going
> to generate a warning in the logs and we have a strict policy against
> that.
>
> > I think declarative services do not yet support this but it would be a
> very
> > valuable feature as it allows to handle optional imports without any
> class
> > loading magic on the user side.
>
> +1
>
> Robert
> >
> > Christian
> >
> > 2017-11-21 14:53 GMT+01:00 Robert Munteanu via osgi-dev
> > :
> >>
> >> Hi Carsten,
> >>
> >> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler  >
> >> wrote:
> >> > Hi,
> >> >
> >> > if I understand you correctly you have an optional package import to
> the
> >> > package providing BarService?
> >>
> >> Yes, that is correct.
> >>
> >> > In that case your class SomeComponent can't be loaded if that package
> is
> >> > not available and there is no magic to get around this.
> >>
> >> I was afraid of that. I'll try using a ServiceTracker, guess that's
> >> the next best thing.
> >>
> >> Thanks,
> >>
> >> Robert
> >> ___
> >> OSGi Developer Mail List
> >> osgi-dev@mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
>
>
> --
> http://robert.muntea.nu/
> ___
> 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] Declarative services and optional imports

[Robert Munteanu via osgi-dev]

On Tue, Nov 21, 2017 at 4:00 PM, Christian Schneider
 wrote:
> I think it can not work with a simple optional import. What could work is a
> separate component that has
> the optional class as a mandatory reference.
>
> This component could then be injected into your component with an optional
> reference and with an interface that is independent of the optional import.

That's a good point. Sadly I can't use this approach since it's going
to generate a warning in the logs and we have a strict policy against
that.

> I think declarative services do not yet support this but it would be a very
> valuable feature as it allows to handle optional imports without any class
> loading magic on the user side.

+1

Robert
>
> Christian
>
> 2017-11-21 14:53 GMT+01:00 Robert Munteanu via osgi-dev
> :
>>
>> Hi Carsten,
>>
>> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler 
>> wrote:
>> > Hi,
>> >
>> > if I understand you correctly you have an optional package import to the
>> > package providing BarService?
>>
>> Yes, that is correct.
>>
>> > In that case your class SomeComponent can't be loaded if that package is
>> > not available and there is no magic to get around this.
>>
>> I was afraid of that. I'll try using a ServiceTracker, guess that's
>> the next best thing.
>>
>> Thanks,
>>
>> Robert
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>



-- 
http://robert.muntea.nu/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Carsten Ziegeler via osgi-dev]

Well this has nothing to do with DS - how should Java load this class if
a needed class is not available?

Carsten


Osgi Developer Mail List wrote
> I think it can not work with a simple optional import. What could work
> is a separate component that has 
> the optional class as a mandatory reference.
> 
> This component could then be injected into your component with an
> optional reference and with an interface that is independent of the
> optional import.
> 
> I think declarative services do not yet support this but it would be a
> very valuable feature as it allows to handle optional imports without
> any class loading magic on the user side.
> 
> Christian
> 
> 2017-11-21 14:53 GMT+01:00 Robert Munteanu via osgi-dev
> >:
> 
> Hi Carsten,
> 
> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler
> > wrote:
> > Hi,
> >
> > if I understand you correctly you have an optional package import to the
> > package providing BarService?
> 
> Yes, that is correct.
> 
> > In that case your class SomeComponent can't be loaded if that package is
> > not available and there is no magic to get around this.
> 
> I was afraid of that. I'll try using a ServiceTracker, guess that's
> the next best thing.
> 
> Thanks,
> 
> Robert
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org 
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
> 
> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> 
> Computer Scientist
> http://www.adobe.com
> 
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Christian Schneider via osgi-dev]

I think it can not work with a simple optional import. What could work is a
separate component that has
the optional class as a mandatory reference.

This component could then be injected into your component with an optional
reference and with an interface that is independent of the optional import.

I think declarative services do not yet support this but it would be a very
valuable feature as it allows to handle optional imports without any class
loading magic on the user side.

Christian

2017-11-21 14:53 GMT+01:00 Robert Munteanu via osgi-dev <
osgi-dev@mail.osgi.org>:

> Hi Carsten,
>
> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler 
> wrote:
> > Hi,
> >
> > if I understand you correctly you have an optional package import to the
> > package providing BarService?
>
> Yes, that is correct.
>
> > In that case your class SomeComponent can't be loaded if that package is
> > not available and there is no magic to get around this.
>
> I was afraid of that. I'll try using a ServiceTracker, guess that's
> the next best thing.
>
> Thanks,
>
> Robert
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Robert Munteanu via osgi-dev]

Hi Tim,

On Tue, Nov 21, 2017 at 3:47 PM, Timothy Ward  wrote:
> Hi Robert,
>
> From the code snippet it looks as though you aren’t using the standard 
> annotations (OPTIONAL_UNARY isn’t one of the enum values). If you want 
> support for non-standard annotations then you’ll probably be best served by 
> using the relevant mailing list for the community that provides the 
> annotations.

Yes, we're still using the Felix SCR annotations.

> If you were using the standard DS annotations then I would be telling you 
> that what you’re doing is supported, but that you should be careful when 
> using optional or multiple references with a static reluctant injection 
> policy. The static reluctant policy rarely gives you the desired behaviour in 
> these cases and usually results in your component having no reference even 
> when there is a suitable service available.

That I was not aware of, thank you. Anyway, Carsten made the point
that if BarService is not available at runtime SCR will not handle it,
so I guess I need to look up the component programatically.

Thanks,

Robert
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Timothy Ward via osgi-dev]

See also,

https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward 


Tim

> On 21 Nov 2017, at 13:53, Robert Munteanu via osgi-dev 
>  wrote:
> 
> Hi Carsten,
> 
> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler  
> wrote:
>> Hi,
>> 
>> if I understand you correctly you have an optional package import to the
>> package providing BarService?
> 
> Yes, that is correct.
> 
>> In that case your class SomeComponent can't be loaded if that package is
>> not available and there is no magic to get around this.
> 
> I was afraid of that. I'll try using a ServiceTracker, guess that's
> the next best thing.
> 
> Thanks,
> 
> Robert
> ___
> 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] Declarative services and optional imports

[Robert Munteanu via osgi-dev]

Hi Carsten,

On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler  wrote:
> Hi,
>
> if I understand you correctly you have an optional package import to the
> package providing BarService?

Yes, that is correct.

> In that case your class SomeComponent can't be loaded if that package is
> not available and there is no magic to get around this.

I was afraid of that. I'll try using a ServiceTracker, guess that's
the next best thing.

Thanks,

Robert
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Carsten Ziegeler via osgi-dev]

Hi,

if I understand you correctly you have an optional package import to the
package providing BarService?

In that case your class SomeComponent can't be loaded if that package is
not available and there is no magic to get around this.

Regards

Carsten


Osgi Developer Mail List wrote
> Hi,
> 
> I have an SCR component that references a service, with 0...1
> cardinality. That service is part of an optional import. The aim is
> that if the package is available at runtime, the reference is bound,
> otherwise not, but the component functions without it, e.g.
> 
> 
> @Component public class SomeComponent {
> 
> @Reference private FooService foo;
> 
> @Reference(cardinality = OPTIONAL_UNARY ) private BarService bar;
> 
> }
> 
> The result though is that the component bind method lookups fail, e.g.:
> 
> Failure loooking up method
> bindFoo(org.osgi.framework.ServiceReference) in class
> com.example.SomeComponent. Assuming no such method.
> (java.lang.NoClassDefFoundError: com/example/optional/BarService)
> 
> What's interesting is that the 'foo' reference is not part of an
> optional import, the class is visible and the reference is there.
> Obviously in this scenario the optional import for BarService is not
> satisfied and the class it not available.
> 
> I'm running org.apache.felix.scr from the latest OSGi-r7 folder -
> https://svn.apache.org/repos/asf/felix/trunk/osgi-r7/scr/ .
> 
> So my questions are:
> 
> 1. Is this scenario something that SCR can support?
> 2. If the answer above is no, what is the best way of achieving the
> result? Splitting the bundle is unfortunately quite tedious so I'd
> like to avoid that.
> 
> Thanks,
> 
> Robert
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Timothy Ward via osgi-dev]

Hi Robert,

From the code snippet it looks as though you aren’t using the standard 
annotations (OPTIONAL_UNARY isn’t one of the enum values). If you want support 
for non-standard annotations then you’ll probably be best served by using the 
relevant mailing list for the community that provides the annotations.

If you were using the standard DS annotations then I would be telling you that 
what you’re doing is supported, but that you should be careful when using 
optional or multiple references with a static reluctant injection policy. The 
static reluctant policy rarely gives you the desired behaviour in these cases 
and usually results in your component having no reference even when there is a 
suitable service available.

Regards,

Tim

> On 21 Nov 2017, at 13:28, Robert Munteanu via osgi-dev 
>  wrote:
> 
> Hi,
> 
> I have an SCR component that references a service, with 0...1
> cardinality. That service is part of an optional import. The aim is
> that if the package is available at runtime, the reference is bound,
> otherwise not, but the component functions without it, e.g.
> 
> 
> @Component public class SomeComponent {
> 
> @Reference private FooService foo;
> 
> @Reference(cardinality = OPTIONAL_UNARY ) private BarService bar;
> 
> }
> 
> The result though is that the component bind method lookups fail, e.g.:
> 
> Failure loooking up method
> bindFoo(org.osgi.framework.ServiceReference) in class
> com.example.SomeComponent. Assuming no such method.
> (java.lang.NoClassDefFoundError: com/example/optional/BarService)
> 
> What's interesting is that the 'foo' reference is not part of an
> optional import, the class is visible and the reference is there.
> Obviously in this scenario the optional import for BarService is not
> satisfied and the class it not available.
> 
> I'm running org.apache.felix.scr from the latest OSGi-r7 folder -
> https://svn.apache.org/repos/asf/felix/trunk/osgi-r7/scr/ .
> 
> So my questions are:
> 
> 1. Is this scenario something that SCR can support?
> 2. If the answer above is no, what is the best way of achieving the
> result? Splitting the bundle is unfortunately quite tedious so I'd
> like to avoid that.
> 
> Thanks,
> 
> Robert
> 
> -- 
> http://robert.muntea.nu/
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Declarative services and optional imports

[Robert Munteanu via osgi-dev]

Hi,

I have an SCR component that references a service, with 0...1
cardinality. That service is part of an optional import. The aim is
that if the package is available at runtime, the reference is bound,
otherwise not, but the component functions without it, e.g.


@Component public class SomeComponent {

@Reference private FooService foo;

@Reference(cardinality = OPTIONAL_UNARY ) private BarService bar;

}

The result though is that the component bind method lookups fail, e.g.:

Failure loooking up method
bindFoo(org.osgi.framework.ServiceReference) in class
com.example.SomeComponent. Assuming no such method.
(java.lang.NoClassDefFoundError: com/example/optional/BarService)

What's interesting is that the 'foo' reference is not part of an
optional import, the class is visible and the reference is there.
Obviously in this scenario the optional import for BarService is not
satisfied and the class it not available.

I'm running org.apache.felix.scr from the latest OSGi-r7 folder -
https://svn.apache.org/repos/asf/felix/trunk/osgi-r7/scr/ .

So my questions are:

1. Is this scenario something that SCR can support?
2. If the answer above is no, what is the best way of achieving the
result? Splitting the bundle is unfortunately quite tedious so I'd
like to avoid that.

Thanks,

Robert

-- 
http://robert.muntea.nu/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev