Re: [osgi-dev] serviceloader

2019-12-17 Thread Raymond Auge via osgi-dev 
You could also use bnd's `@ServiceProvider` and/or `@ServiceConsumer`
annotations which handle all of this magic for you.

The addition of the service capability was recently added so is not
available until next release (5.0.0), but everything else is handled.

Before 5.0.0 this is what I typically use:

@Capability(
 attribute =
"objectClass:List=javax.enterprise.inject.spi.Extension",
 namespace = SERVICE_NAMESPACE
)
@ServiceProvider(
 attribute = {
 CDI_EXTENSION_PROPERTY + '=' + EXTENSION_NAME,
 SERVICE_SCOPE + '=' + SCOPE_PROTOTYPE, // specially supported by
SpiFly to provide prototype scoped services
 SERVICE_VENDOR + "=Apache Software Foundation",
 "version:Version=" + EXTENSION_VERSION
 },
 uses = Extension.class,
 value = Extension.class
)
// implements Extension
public class MPConfigExtension extends ConfigExtension { ... }


- Ray

On Tue, Dec 17, 2019 at 9:28 AM David Bosschaert via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Markus,
>
> Sorry for the late reply.
>
> I think it makes sense in the bundle_provider to also have the capability
> Provide-Capability: osgi.service;objectClass:List="foo.bar.MySPI"
>
> Ideally this could be automatically generated by tooling, when it sees the
>   Provide-Capability: osgi.serviceloader;osgi.serviceloader=...
> capability, but I don't think this auto-generation happens right now.
>
> > Or should the requirement
>
>> > osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
>> > also be satisfied by the provided
>> > osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
>> > (and its requirement for the Registrar) by the resolving
>> implementations?
>>
>
> I don't think that during resolution such 'complicated' mapping should
> take place. Capabilities and requirements are straightforward so an
> osgi.service requirement should be satisfied by an osgi.service capability,
> not a capability in some other namespace.
>
> But yes, providing the additional osgi.service capability in
> the bundle_provider makes sense to me.
>
> Best regards,
>
> David
> ___
> 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)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] serviceloader

2019-12-17 Thread David Bosschaert via osgi-dev 
Hi Markus,

Sorry for the late reply.

I think it makes sense in the bundle_provider to also have the capability
Provide-Capability: osgi.service;objectClass:List="foo.bar.MySPI"

Ideally this could be automatically generated by tooling, when it sees the
  Provide-Capability: osgi.serviceloader;osgi.serviceloader=...
capability, but I don't think this auto-generation happens right now.

> Or should the requirement

> > osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
> > also be satisfied by the provided
> > osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
> > (and its requirement for the Registrar) by the resolving implementations?
>

I don't think that during resolution such 'complicated' mapping should take
place. Capabilities and requirements are straightforward so an osgi.service
requirement should be satisfied by an osgi.service capability, not a
capability in some other namespace.

But yes, providing the additional osgi.service capability in
the bundle_provider makes sense to me.

Best regards,

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

Re: [osgi-dev] serviceloader

2019-12-17 Thread Markus Rathgeb via osgi-dev 
Hi guys,

is this the wrong list for such question?
Can you point me to a more suitable one?

Best regards,
Markus

Am Fr., 18. Okt. 2019 um 10:55 Uhr schrieb Markus Rathgeb :
>
> Hello,
>
> I have question about the serviceloader specific manifest entries (WRT
> to the example from
> https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html):
>
> The bundle that provides an implementation by SPI should contain that
> manifest headers:
>
> Require-Capability:
> osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)"
> Provide-Capability: osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
>
> Let's name it bundle_provider for the moment.
>
> If my reading has been correct the ServiceLoader Registrar (e.g.
> SPI-fly) register the specific implementation class OSGi Services so
> that OSGi-aware consumers can simply use them from the OSGi Service
> Registry.
>
> If "@Reference foo.bar.MySPI" is used in a component (so a consumer)
> the bnd tooling will generate that manifest header:
>
> Require-Capability:
> osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
>
> Wouldn't it make sense if bundle_provider also contains the header:
>
> Provide-Capability: osgi.service;objectClass:List="foo.bar.MySPI"
>
> As bundle_provider requires the ServiceLoader Registrar can't it state
> that the OSGi service is provided?
>
> Or should the requirement
> osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
> also be satisfied by the provided
> osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
> (and its requirement for the Registrar) by the resolving implementations?
>
> Best regards,
> Markus
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Questions about R7 Configurator

2019-12-17 Thread Raymond Auge via osgi-dev 
... not just DS, but OSGi CDI too with Bean Property Types [1]!

:)

[1]
https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html#service.cdi-bean.property.types

On Tue, Dec 17, 2019 at 7:03 AM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hi David,
>
> Ah, ok. Yes, that helps indeed. Thanks!
>
> Cheers,
> =David
>
>
> On Dec 17, 2019, at 19:55, David Bosschaert 
> wrote:
>
> Hi David,
>
> This means that having an untyped map of configuration data is in most
> cases not what you want. More convenient is to convert it to a typed api.
> Using the OSGi converter to create an annotation instance is a very
> convenient way to do this. Annotations are particularly useful since they
> allow you to specify defaults too.
>
> The converter spec at
> https://osgi.org/specification/osgi.enterprise/7.0.0/util.converter.html#util.converter-maps
> just under table 707.5 has an example of this.
>
> The converter allows you to do this anywhere you like; Declarative
> Services also has this functionality built-in. There it's called 'component
> property types'.
>
> Hope this helps,
>
> David
>
> On Tue, 17 Dec 2019 at 06:56, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>>
>> Hi!
>>
>> I have a question about the Configurator spec. I am trying to update from
>> the old enRoute Configurer to the new R7 Configurator.
>>
>>
>> I am not sure what this means:
>>
>> A convenient way to convert a configuration map to the desired data types
>> is by using the Converter to convert it to an annotation instance or by
>> using a Declarative Services component property type.
>>
>>
>>
>> Can somebody enlighten me?
>>
>>
>>
>> I will surely have more questions later. :-)
>>
>>
>> Cheers,
>> =David
>>
>> ___
>> 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)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Questions about R7 Configurator

2019-12-17 Thread David Leangen via osgi-dev 

Hi David,

Ah, ok. Yes, that helps indeed. Thanks!

Cheers,
=David


> On Dec 17, 2019, at 19:55, David Bosschaert  
> wrote:
> 
> Hi David,
> 
> This means that having an untyped map of configuration data is in most cases 
> not what you want. More convenient is to convert it to a typed api. Using the 
> OSGi converter to create an annotation instance is a very convenient way to 
> do this. Annotations are particularly useful since they allow you to specify 
> defaults too. 
> 
> The converter spec at 
> https://osgi.org/specification/osgi.enterprise/7.0.0/util.converter.html#util.converter-maps
>  
> 
>  just under table 707.5 has an example of this.
> 
> The converter allows you to do this anywhere you like; Declarative Services 
> also has this functionality built-in. There it's called 'component property 
> types'.
> 
> Hope this helps,
> 
> David
> 
> On Tue, 17 Dec 2019 at 06:56, David Leangen via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> 
> Hi!
> 
> I have a question about the Configurator spec. I am trying to update from the 
> old enRoute Configurer to the new R7 Configurator.
> 
> 
> I am not sure what this means:
> 
>> A convenient way to convert a configuration map to the desired data types is 
>> by using the Converter to convert it to an annotation instance or by using a 
>> Declarative Services component property type.
> 
> 
> Can somebody enlighten me?
> 
> 
> 
> I will surely have more questions later. :-)
> 
> 
> Cheers,
> =David
> 
> ___
> 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] Questions about R7 Configurator

2019-12-17 Thread David Bosschaert via osgi-dev 
Hi David,

This means that having an untyped map of configuration data is in most
cases not what you want. More convenient is to convert it to a typed api.
Using the OSGi converter to create an annotation instance is a very
convenient way to do this. Annotations are particularly useful since they
allow you to specify defaults too.

The converter spec at
https://osgi.org/specification/osgi.enterprise/7.0.0/util.converter.html#util.converter-maps
just under table 707.5 has an example of this.

The converter allows you to do this anywhere you like; Declarative Services
also has this functionality built-in. There it's called 'component property
types'.

Hope this helps,

David

On Tue, 17 Dec 2019 at 06:56, David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hi!
>
> I have a question about the Configurator spec. I am trying to update from
> the old enRoute Configurer to the new R7 Configurator.
>
>
> I am not sure what this means:
>
> A convenient way to convert a configuration map to the desired data types
> is by using the Converter to convert it to an annotation instance or by
> using a Declarative Services component property type.
>
>
>
> Can somebody enlighten me?
>
>
>
> I will surely have more questions later. :-)
>
>
> Cheers,
> =David
>
> ___
> 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