Re: [osgi-dev] serviceloader
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
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
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
