Provide a way to override (required) capabilities generated from DS annotations

[oliverlietz]

I'm currently working on a larger task where I adjust all required and provided capabilities in Apache Sling to allow Karaf/Sling feature resolution: SLING-7546 Take requirements for services into account.

We have one component, OsgiObservationBridge, which translates resource changes/events to OSGi Event Admin events for legacy consumers. This component should only get active when an EventHandler is present.

bnd creates for

    @Reference(name = "handlers",
            cardinality=ReferenceCardinality.AT_LEAST_ONE,
            policy=ReferencePolicy.DYNAMIC,
            service=EventHandler.class,
            target="(|(event.topics=org/apache/sling/api/resource/Resource/*)(event.topics=org/apache/sling/api/resource/ResourceProvider/*))")

the (technical correct) required capability

osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple

But of course the required capability should be optional:

osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple;resolution:=optional

There is no way to override this capability with an instruction in a bnd.bnd file. All capabilities are added to MANIFEST.MF.

[bjhargrave]

Did you try -dsannotations-options: norequirements in your bnd file?

the (technical correct) required capability

osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple

Note, the technically correct requirement is optional with respect to framework resolving since it is effective:=active.

[oliverlietz]

Did you try -dsannotations-options: norequirements in your bnd file?

This disables requirements for all DS components of the bundle which is not desired.

Note, the technically correct requirement is optional with respect to framework resolving since it is effective:=active.

Karaf's feature resolver behaves differently than framework resolving (see SubsystemResolveContext):

    @Override
    public boolean isEffective(Requirement requirement) {
        boolean isServiceReq = ServiceNamespace.SERVICE_NAMESPACE.equals(requirement.getNamespace());
        return !(isServiceReq && FeaturesService.ServiceRequirementsBehavior.Disable == serviceRequirements);
    }

Still need a way to get rid of the required capability.

[bjhargrave]

This disables requirements for all DS components of the bundle which is not desired.

This is the only level of control we have for generation of requirements. There is no way to control it for a specific reference on a component. I imagine a @NoRequirement annotation could be defined by Bnd to do this, but someone would need to make the PR to propose such a change.

[oliverlietz]

I'm in favor of a more general approach (instructions in bnd file override generated ones), but I struggle to find a place where to hook in such logic. Source lacks documentation and I'm not much familiar with it yet.

[bjhargrave]

You could write your own Analyzer plugin which can post-process the Require-Capability header value to remove the generated requirement in preference to your requirement from the bnd file.

[oliverlietz]

Sure, but that wouldn't help others having same or similar issues (found when searching for a solution).
The quickest but least sustainable way is removing DS from OsgiObservationBridge and using low-level OSGi API.

[bjhargrave]

cardinality=ReferenceCardinality.AT_LEAST_ONE in the example means the service requirement is not optional.

[bjhargrave]

Closing.

[rotty3000]

In bnd 4.0.0 we already _prefer_ the capability in the bnd file by assuring it remains first in the resulting list. And since requirements/capabilities are ordered at runtime using the first found produces the desired result.

…

On Fri, May 11, 2018, 12:22 BJ Hargrave, ***@***.***> wrote: cardinality=ReferenceCardinality.AT_LEAST_ONE in the example means the service requirement is not optional. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2429 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI9TFIoa8Cs1N7yz6dJtVIEqta4ZTnTks5txbrPgaJpZM4TiKoi> .

[oliverlietz]

@bjhargrave, what's the point? No EventHandler with matching event.topics is totally fine for the bundle and shouldn't prevent resolving.

[bjhargrave]

No EventHandler with matching event.topics is totally fine for the bundle and shouldn't prevent resolving.

The component declares cardinality=ReferenceCardinality.AT_LEAST_ONE which means zero is not acceptable to the component. So the service requirement for the component is not optional.

Further more, effective:=active requirements never prevent bundles from resolving in the framework.

[oliverlietz]

The component declares cardinality=ReferenceCardinality.AT_LEAST_ONE which means zero is not acceptable to the component. So the service requirement for the component is not optional.

Right, the component should only get activated when at least one EventHandler with matching event.topics is present.

Further more, effective:=active requirements never prevent bundles from resolving in the framework.

See my comment regarding Karaf resolver – Karaf doesn't resolve a feature containing the bundle with OsgiObservationBridge.

[timothyjward]

Right, the component should only get activated when at least one EventHandler with matching event.topics is present.

Which means that from this bundle’s perspective the EventHandler service is mandatory. This is an implementation decision that the author of the bundle has made to use DS to control lifecycle at the expense of not supporting a zero entry whiteboard.

Karaf doesn’t resolve a feature containing the bundle with OSGiObservationBridge

That’s because you’ve got the requirements in the feature backwards. The feature should not require the bridge bundle. The bundle that provides the EventHandler should require an osgi.implementation capability which is provided by the bridge. That way the bridge is deployed as needed, and its service requirement is satisfied by the bundle that requires the implementation capability.

This is the standard pattern for whiteboards in OSGi (see also the Http and JAX-RS whiteboards).

[oliverlietz]

@timothyjward, thanks for your explanation, but OSGiObservationBridge is for supporting legacy clients in a real world application and I'm fine with rewriting it without using DS (see my comment) if bnd is unable to provide support for this and similar use cases – but looks like @rotty3000 is right (testing with 4.0.0-SNAPSHOT right now). Thanks!

[realPyR3X]

I'm also having this issue and looking for a way to resolve it. I have a component I'd like to remain in the resolve state until AT_LEAST_ONE is satisfied and the component activated. However, Karaf will not deploy my feature that includes this bundle for that to happen.

[djencks]

I can think of two workarounds: 1. include a dummy service with some service properties like dummy=true and include a target filter for the reference !(dummy=true). The dummy service will satisfy karaf’s attempts so make sure there’s some chance all your components might start, but it won’t actually bind. I think you can specify enabled=false for the dummy component also, then you won’t need the target filter. 2. in the component, have cardinality MULTIPLE but reset it to 1+ using a configuration for the component containing a <target_name>.cardinality.minimum property. David Jencks

…

On Jan 8, 2019, at 11:00 PM, realPyR3X ***@***.***> wrote: I'm also having this issue and looking for a way to resolve it. I have a component I'd like to remain in the resolve state until AT_LEAST_ONE is satisfied and the component activated. However, Karaf will not deploy my feature that includes this bundle for that to happen. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2429 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAix3q_lfXM6KwsQuPsJPZPVxr-TGZy3ks5vBZOJgaJpZM4TiKoi>.

[oliverlietz]

I have just added a plugin for bnd to remove parameters from bundle headers, see FELIX-6019.