Maison  >  Article  >  Après la mise à jour vers 2.x, l'utilisation de « slf4j.api » dans un bundle OSGi nécessite l'extension « osgi.serviceloader.processor »

Après la mise à jour vers 2.x, l'utilisation de « slf4j.api » dans un bundle OSGi nécessite l'extension « osgi.serviceloader.processor »

王林
王林avant
2024-02-10 21:12:08971parcourir

Après avoir introduit la dernière mise à jour de la version 2.x, l'éditeur de PHP Apple a constaté que l'utilisation de "slf4j.api" dans le package OSGi nécessite l'extension "osgi.serviceloader.processor". Cette mise à jour constitue un changement important pour les développeurs utilisant cette extension, car elle offre plus de flexibilité et de commodité. Le but de cette mise à jour est d'aider les développeurs à mieux utiliser et gérer slf4j.api pour améliorer les performances et la stabilité du programme. Les développeurs peuvent s’attendre à davantage de mises à jour et d’améliorations pour répondre à leurs besoins évolutifs.

Contenu de la question

J'ai créé un petit projet de reproduction sur github : slf4j-experiment

En gros, ce dont j'ai besoin est un package osgi avec du code utilisant slf4j-api.

Exemple :

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");
    }
}

Dans mon build.gradle j'ai :

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'
    
    // ...
}

Cela fonctionne comme prévu avec slf4j 1.7.36

Maintenant, en utilisant la version 2.0.11 de slf4j, du fait du recours à des fournisseurs de services, il y a de nouvelles contraintes modélisées dans les métadonnées osgi et maintenant je suis bloqué :

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)))

On dirait que j'ai besoin d'un pack supplémentaire, probablement fourni par spi fly, mais je ne comprends pas comment...

Solution de contournement

Votre Exemple Avertissement :

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

(Je ne suis pas fan de gradle + osgi + bnd) se résout en slf4j-api-1.7.36.jar depuis maven central.

Voici le bon bundle osgi :

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

Mais slf4j-api-2.0.11.jar a :

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

En fait - cela satisfait 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 a obtenu ces en-têtes (obligatoires) dans ce commit . p>

spi-fly est la version d'osgi du chargeur de service Java, transformant dynamiquement le code du bundle afin de configurer le chargeur de classe de contexte de thread correct.

Il s'agit en fait d'une exigence appropriée pour l'API 2 de slf4j lorsqu'ils passent de la liaison statiqueimplémentée par les enregistreurs aux /meta-inf/services/org 的服务发现.slf4j.spi.slf4jserviceproviderservices.

Cependant, osgi est une bête tenace. Pour la journalisation, je recommande le projet de journalisation pax, qui non seulement exporte les bons packages org.slf4j, mais vous permet également de configurer dynamiquement le backend de journalisation et de le configurer à l'aide de la gestion de configuration osgi.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer
Article précédent:Contrôleur API SpringArticle suivant:Contrôleur API Spring