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<String>=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<String>="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é* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
