osgi / slf4j-osgi Goto Github PK

SLF4J Binding for OSGi Log Service

License: Apache License 2.0

Java 100.00%

slf4j-osgi's Introduction

OSGi

This is the main git repository for the OSGi specifications, implementations and TCKs. It is a Bnd Workspace model build.

Build

See CONTRIBUTING for information on checking out the repo and building.

Draft Specifications

The GitHub Actions build "GitHub Pages" job will publish the draft specifications into the repo's gh-pages branch. So you can view the draft specifications for the osgi/osgi repo:

In your fork, just add core/ or cmpn/ to the end of your fork's GitHub Pages URL. For example:

https://<username>.github.io/osgi/core/

More Information

For more information see the OSGi Specification Project pages at Eclipse: https://projects.eclipse.org/projects/technology.osgi

slf4j-osgi's People

Contributors

Stargazers

Watchers

Forkers

rotty3000 dahoc jellenelis v2com 595385335 stjordanis kchobantonov isabella232 bjhargrave stbischof step-security-bot

slf4j-osgi's Issues

Maven Central?

Is there a reason this is not available through Maven Central repository? It would be really nice to have it there.

Are you planning to release this or do you perceive this just as a proof-of-concept? If you are not planning on releasing this, do you have pointers to other resources that try to achieve the same thing (getting SLF4J logging into R7 logging)?

Kind regards,

Jelle

[Question] Why is this bundle not on Orbit?

I was looking which bindings available for slf4j integration in Eclipse and stumbled over this repo.
Is there any reason why is this bundle is not added to some Orbit release [1]?

I see there are slf4j bindings available on Orbit like org.slf4j.binding.log4j12, but if I understand it right, this one aims to "simply" route all logs from slf4j to standard Eclipse log (if being added to the Eclipse IDE for example) and that is exactly what was I looking for.

Is this bundle not on Orbit because org.apache.aries.spifly.dynamic.framework.extension is also needed? Or just because no one asked yet?

[1] https://download.eclipse.org/tools/orbit/downloads/drops/R20221123021534/

1.7 branch

Is the 1.7 branch something we need\want to keep and maintain?

`OSGiServiceProvider` uses NOOP implementation of the `MDCAdapter`

I am wondering if the OSGiServiceProvider should use the basic MDC implementation - BasicMDCAdapter instead of NOPMDCAdapter which is currently used -

slf4j-osgi/src/main/java/org/osgi/slf4j/OSGiServiceProvider.java

Line 55 in af1a6f1

mdcAdapter = new NOPMDCAdapter();

Due to the usage of the NOPMDCAdapter, nothing seems to be logged at all.

Version range of package import for org.osgi.service.log to strict

I want to use this fragment within a RCP application based on Eclipse 4.18. The included equinox runtime seems to implement the osgi log service version 1.5. Since the package import directive for org.osgi.service.log in slf4j.osgi is stated as [1.4,1.5) the fragment fails to resolve in my context. Looking at the source code and the documentation at https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.log.html#org.osgi.service.log I'm wondering why the version range is so strict.? To my understanding this fragment only consumes the log service api so according to the documentation a version range of [1.4,2.0) should be fine.

No version constraint on Fragment-Host header

Currently the Fragment-Host is specified only with slf4j.api it resolves to any version of slf4j (even older ones).
According to semantic versioning it must only resolve to the next release: slf4j.api;bundle-version="[1.7,1.8)" or maybe even more stricter policy when we assume that a logging provider is tightly coupled to the slf4j implementation of slf4j.api;bundle-version="[1.7.25,1.7.26)"