Nach dem Update auf 2.x erfordert die Verwendung von „slf4j.api“ in einem OSGi-Bundle die Erweiterung „osgi.serviceloader.processor“.

Nach der Einführung des neuesten Updates auf Version 2.x stellte der Herausgeber von PHP Apple fest, dass die Verwendung von „slf4j.api“ im OSGi-Paket die Erweiterung „osgi.serviceloader.processor“ erfordert. Dieses Update ist eine wichtige Änderung für Entwickler, die diese Erweiterung verwenden, da es mehr Flexibilität und Komfort bietet. Der Zweck dieses Updates besteht darin, Entwicklern dabei zu helfen, slf4j.api besser zu nutzen und zu verwalten, um die Programmleistung und -stabilität zu verbessern. Entwickler können sich auf weitere Updates und Verbesserungen freuen, um ihren sich ändernden Anforderungen gerecht zu werden.

Frageninhalt

Ich habe ein kleines Reproduktionsprojekt auf Github erstellt: slf4j-experiment

Grundsätzlich brauche ich ein Osgi-Paket mit etwas Code, der slf4j-api verwendet.

Beispiel:

import org.osgi.service.component.annotations.activate;
import org.osgi.service.component.annotations.component;
import org.osgi.service.component.annotations.deactivate;
import org.slf4j.logger;
import org.slf4j.loggerfactory;

@component(service = someservice.class)
public class someserviceimpl implements someservice {
    private static final logger log = loggerfactory.getlogger(someserviceimpl.class);

    @override
    public string doit(string first, string second) {
        log.info("someserviceimpl: doit(..)");
        return operation(first, second);
    }

    static string operation(string first, string second) {
        return first + second;
    }

    @activate
    public void activate() {
        log.info("someserviceimpl: activate");
    }

    @deactivate
    public void deactivate() {
        log.info("someserviceimpl: deactivate");
    }
}

In meinem build.gradle habe ich:

dependencies {
    compileonly 'org.osgi:osgi.annotation:7.0.0'
    compileonly 'org.osgi:org.osgi.service.component.annotations:1.3.0'

    implementation 'org.slf4j:slf4j-api:2.0.11'
    runtimeonly 'org.slf4j:slf4j-simple:2.0.11'
    
    // ...
}

Das funktioniert wie erwartet mit slf4j 1.7.36

Wenn ich jetzt die 2.0.11-Version von slf4j verwende, gibt es aufgrund der Verwendung von Dienstanbietern neue Einschränkungen, die in den Osgi-Metadaten modelliert sind, und jetzt stecke ich fest:

Resolution failed. Capabilities satisfying the following requirements could not be found:
    [<<INITIAL>>]
      ⇒ osgi.identity: (osgi.identity=slf4j.simple)
          ⇒ [slf4j.simple version=2.0.11]
              ⇒ osgi.wiring.package: (&(osgi.wiring.package=org.slf4j)(version>=2.0.0)(!(version>=3.0.0)))
                  ⇒ [slf4j.api version=2.0.11]
                      ⇒ osgi.extender: (&(osgi.extender=osgi.serviceloader.processor)(version>=1.0.0)(!(version>=2.0.0)))

Sieht so aus, als ob ich ein zusätzliches Paket benötige, das wahrscheinlich von spi fly bereitgestellt wird, aber ich verstehe nicht, wie ...

Problemumgehung

Ihr Beispiel Haftungsausschluss:

slf4j.api;version='[1.7.36,1.7.37)',\
slf4j.simple;version='[1.7.36,1.7.37)'

(Ich bin kein Fan von Gradle + Osgi + BND) wird von Maven Central zu slf4j-api-1.7.36.jar aufgelöst.

Dies ist das richtige Osgi-Bundle:

import-package: org.slf4j.impl;version=1.6.0
export-package: org.slf4j;version=1.7.36, org.slf4j.spi;version=1.7.36
 , org.slf4j.helpers;version=1.7.36, org.slf4j.event;version=1.7.36

Aber slf4j-api-2.0.11.jar hat:

require-capability: osgi.extender;filter:="(&(osgi.extender=osgi.service
 loader.processor)(version>=1.0.0)(!(version>=2.0.0)))"

Tatsächlich – es befriedigt aries spi-fly:

Provide-Capability: osgi.extender;osgi.extender="osgi.serviceloader.re
 gistrar";version:Version="1.0",osgi.extender;osgi.extender="osgi.serv
 iceloader.processor";version:Version="1.0";uses:="org.apache.aries.sp
 ifly"

slf4j hat diese Header (erforderlich) in diesem Commit erhalten . p>

spi-fly ist OSGIs Version des Java Service Loader, die den Code des Bundles dynamisch umwandelt, um den richtigen Thread-Kontext-Klassenlader einzurichten.

Dies ist eigentlich eine richtige Anforderung für slf4j API 2, da sie von der statischen Bindungimplementiert durch Logger zu /meta-inf/services/org 的服务发现.slf4j.spi.slf4jserviceproviderDiensten wechseln.

Allerdings ist Osgi ein hartnäckiges Biest. Für die Protokollierung empfehle ich das Pax-Logging-Projekt, das nicht nur die richtigen org.slf4j Pakete exportiert, sondern auch die dynamische Konfiguration des Logging-Backends und die Konfiguration über das Osgi-Konfigurationsmanagement ermöglicht.

Das obige ist der detaillierte Inhalt vonNach dem Update auf 2.x erfordert die Verwendung von „slf4j.api“ in einem OSGi-Bundle die Erweiterung „osgi.serviceloader.processor“.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!