commit | b4c6b7786ec5e1525934a8700c3800e51d37c996 | [log] [tgz] |
---|---|---|
author | Raymond Augé <rotty3000@apache.org> | Fri Jun 22 19:26:04 2018 +0000 |
committer | Raymond Augé <rotty3000@apache.org> | Fri Jun 22 19:26:04 2018 +0000 |
tree | 2e71d3f986737026d90e8a1fec854ce6233885a3 | |
parent | dba21656a2c2f8badab7c5e77b6d7b97370498c5 [diff] |
[maven-release-plugin] copy for tag org.apache.felix.logback-1.0.0 git-svn-id: https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.logback-1.0.0@1834158 13f79535-47bb-0310-9956-ffa450edef68
Apache Felix Logback is a small integration of the Logback backend with OSGi.
With OSGi R7 the Log Service Specification 1.4 (Log 1.4) brings a slew of new features designed to improve the developer experience with logging, the details of which can be read about here.
This project is intended to help bridge the last frontier of OSGi logging by leveraging many capabilities of Logback, the new Log 1.4 features to provide a unified backend where:
The LICENSE is of course Apache License Version 2.0.
First, to add Logback to an OSGi framework include the following dependencies
<dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.x</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.2.x</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.x</version> </dependency>
These provide the slf4j
logging API over the Logback backend.
Configuring logback is most easily handled by setting the system property logback.configurationFile
to point to a file on the file system.
This is an example using a bndrun file:
-runproperties: logback.configurationFile=file:${.}/logback.xml
where in bnd ${.}
gives the path to the directory of the bndrun file.
Logback offers many features from it's configuration file, so make sure to look through the documentation.
There are at least two possible deployment scenarios.
The standard approach is to install all bundles into the OSGi runtime.
pros:
cons:
[^*]: (In the case of the OSGi Log Service this is handled by implementations that support Log 1.4, or perhaps earlier through proprietary means. Most logging frameworks simply do not support this type of feature.)
The runpath approach is intended overcome the cons of the standard approach; to initialize the log engine and allow APIs to bind to implementations as early as possible in order to capture all records without resorting to a queues, being worried about binding issues, or having to be concerned with missed logs due to start ordering.
pros:
cons:
Of course adding Logback does not magically result in all logs being funnelled into the same appenders, particularly the OSGi logs. However, it is quite common to assemble an OSGi application from a variety of bundles which use a variety of logging APIs. Many of these can already be mapped onto Logback.
Many examples setting up the various logging APIs can be found in the integration tests of the project.
The following APIs are tested:
The OSGi Log specification describes events resulting in log records. Log 1.4 defines logger names mapping to these events.
Event | Logger Name | Events types |
---|---|---|
Bundle event | Events.Bundle | INSTALLED - BundleEvent INSTALLEDSTARTED - BundleEvent STARTEDSTOPPED - BundleEvent STOPPEDUPDATED - BundleEvent UPDATEDUNINSTALLED - BundleEvent UNINSTALLEDRESOLVED - BundleEvent RESOLVEDUNRESOLVED - BundleEvent UNRESOLVED |
Service event | Events.Service | REGISTERED - ServiceEvent REGISTEREDMODIFIED - ServiceEvent MODIFIEDUNREGISTERING - ServiceEvent UNREGISTERING |
Framework event | Events.Framework | STARTED - FrameworkEvent STARTEDERROR - FrameworkEvent ERRORPACKAGES_REFRESHED - FrameworkEvent PACKAGES REFRESHEDSTARTLEVEL_CHANGED - FrameworkEvent STARTLEVEL CHANGEDWARNING - FrameworkEvent WARNINGINFO - FrameworkEvent INFO |
Legacy Log Service events | LogService | any log events originating from bundles that used the original LogService logging API |
Note: In order to improve the granularity of the logging associated with these events, Apache Felix Logback makes it possible to refer to these mappings per bundle by appending a period (.
) and segments of the Bundle-SymbolicName
of the originating bundle(s) to the logger names. This greatly improves the configurability.
Consider the following logback.xml
example:
<configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%.15thread] %-5level %logger{36}:%line - %msg%n</pattern> </encoder> </appender> <!-- log all bundle events --> <logger name="Events.Bundle" level="TRACE"/> <!-- WARN framework service events, because we can --> <logger name="Events.Service.org.eclipse.osgi" level="WARN"/> <!-- turn OFF legacy Log Service records from bundles with BSN `org.baz.*` --> <logger name="LogService.org.baz" level="OFF"/> <!-- DEBUG service events for bundles with BSN `org.fum.*` --> <logger name="Events.Service.org.fum" level="DEBUG"/> <!-- DEBUG custom project --> <logger name="org.my.foo" level="DEBUG"/> <root level="ERROR"> <appender-ref ref="STDOUT" /> </root> </configuration>
eclipse.log.enabled=false