Maison > Java > 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 »

王林
Libérer: 2024-02-10 21:12:08
avant
1067 Les gens l'ont consulté

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");
    }
}
Copier après la connexion

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'
    
    // ...
}
Copier après la connexion

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)))
Copier après la connexion

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)'
Copier après la connexion

(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
Copier après la connexion

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)))"
Copier après la connexion

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"
Copier après la connexion

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!

source:stackoverflow.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal