{"id":22281097,"url":"https://github.com/ops4j/org.ops4j.pax.logging","last_synced_at":"2025-05-14T21:11:05.640Z","repository":{"id":1227141,"uuid":"1155836","full_name":"ops4j/org.ops4j.pax.logging","owner":"ops4j","description":"The OSGi Logging framework implementation. Supports SLF4J,LOG4J,JCL etc.","archived":false,"fork":false,"pushed_at":"2025-03-31T07:43:56.000Z","size":5047,"stargazers_count":47,"open_issues_count":7,"forks_count":77,"subscribers_count":49,"default_branch":"main","last_synced_at":"2025-04-10T10:01:20.986Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://ops4j1.jira.com/wiki/spaces/paxlogging/overview","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ops4j.png","metadata":{"files":{"readme":"readme.adoc","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2010-12-10T10:39:16.000Z","updated_at":"2025-03-31T07:44:00.000Z","dependencies_parsed_at":"2023-07-06T22:01:25.347Z","dependency_job_id":"7cbea38e-23b8-44b9-91c6-373a556283ab","html_url":"https://github.com/ops4j/org.ops4j.pax.logging","commit_stats":null,"previous_names":[],"tags_count":105,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ops4j%2Forg.ops4j.pax.logging","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ops4j%2Forg.ops4j.pax.logging/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ops4j%2Forg.ops4j.pax.logging/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ops4j%2Forg.ops4j.pax.logging/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ops4j","download_url":"https://codeload.github.com/ops4j/org.ops4j.pax.logging/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254227631,"owners_count":22035671,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-03T16:14:05.834Z","updated_at":"2025-05-14T21:11:00.624Z","avatar_url":"https://github.com/ops4j.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n= PAX-LOGGING\n\nThe goal of this project is to allow users and bundles to use well known Logging APIs like SLF4J or Commons-Logging.\n\n== Versions\n\n\n|===\n| |1.9.x |1.10.x |1.11.x |1.12.x |2.0.x |2.1.x |2.2.x |2.3.x\n\n|OSGi Log version\n|R6 (1.3)\n|R6 (1.3)\n|R6 (1.3)\n|R6 (1.3)\n|R7 (1.4)\n|R7 (1.4)\n|R8 (1.5)\n|R8 (1.5)\n\n|Log4j1 backend\n|yes\n|yes\n|yes\n|no\n|yes\n|no\n|no\n|no\n\n|Log4j2 version\n|2.12.4\n|2.17.1\n|2.17.1\n|2.24.3\n|2.18.0\n|2.18.0\n|2.24.3\n|2.24.3\n\n|Logback version\n|no\n|1.2.9\n|1.2.11\n|1.3.15\n|1.2.11\n|1.2.11\n|1.3.15\n|1.5.18\n\n|JDK\n|~\n|~\n|~\n|JDK 8+\n|~\n|~\n|JDK 8+\n|JDK 11+\n\n|Maintained\n|no\n|no\n|no, use 1.12.x instead\n|yes\n|no, use 2.2.x instead\n|no, use 2.2.x instead\n|yes\n|yes\n|===\n\nNOTE: All versions support Log4j1 *API*, while only selected ones support Log4j1 *backend*.\n\n.History of the versions\n\n* Version 1.11.x was major refactor of 1.10.x where \u003e100 integration tests were added and the behavior of Log4j1, Log4j2 and Logback backends was unified\n* New major version 2.0.x was created to provide implementation of a new version of the `org.osgi.service.log` package from OSGi R7 specification\n* Version 1.12.x and 2.1.x were created during https://www.lunasec.io/docs/blog/log4j-zero-day/[Log4j crisis] to provide versions that match 1.11.x and 2.0.x (respectively), but without Log4j1 backend\n* Version 2.2.x was created to provide implementation of new version of the `org.osgi.service.log` package from OSGi R8 specification - from day 1 without Log4j1 backend (but still with Log4j1 API)\n* Version 2.3.x was created as natural evolution of 2.2.x, where Logback was upgraded to a version that requires minimum JDK 11.\n\nAt some point, https://reload4j.qos.ch/[reload4j] fork of https://logging.apache.org/log4j/1.2/index.html[Apache log4j] was used.\n\nIn 2023 I decided to stop maintaining these versions:\n\n* 1.11.x, because 1.12.x is compatible version but without log4j1 _backend_ (we don't need it in 2023). Log4j1 API is still available. 1.12.x is the only version exporting `org.osgi.service.log` with version 1.3\n* 2.1.x, because 2.2.x is supporting OSGi CMPN R8 (Log Service 1.5) which is compatible with R7 (Log Service 1.4)\n* 2.0.x, because 2.1.x is no longer maintained, because 2.2.x should be used instead.\n\n1.12.x should be used for older OSGi runtimes, based for example on Karaf 4.2 (and Felix 5.6.12).\n\nPlease don't worry about deprecating 2.0.x/2.1.x. Pax Logging 2.2.x is the same as 2.1.x, but with _two_ exports:\n----\n...\norg.osgi.service.log; version=1.4,\norg.osgi.service.log; version=1.5,\n...\n----\n\n== Basics\n\nThere should be a distinction between _Logging API_ which, by itself, doesn't do any logging, but instead requires specific logging implementation (and related configuration) and the _Logging implementation_ (referred to as a _backend_) itself.\n\nLogging APIs (or _Facades_) matching the above distinction include:\n\n* https://www.slf4j.org/[SLF4J]\n* https://commons.apache.org/proper/commons-logging/[Commons Logging]\n* https://osgi.org/specification/osgi.cmpn/7.0.0/service.log.html[OSGi Compendium Log Service]\n* http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html[JBoss Logging]\n\nLogging implementations always provide their own _APIs_ and can be used without any of the above facades. These include:\n\n* https://logging.apache.org/log4j/2.x/[Apache Log4J2]\n* https://logback.qos.ch/[Logback]\n\nHowever usage of Logback _without_ SLF4J is very rare and won't be implemented in pax-logging.\n\nAnd the above two (with their specific configuration file syntax) are supported by (respectively):\n\n* pax-logging-log4j2 (log4J2)\n* pax-logging-logback (logback)\n\n`pax-logging-log4j1` was named `pax-logging-service` before version 2.0.0 and was removed completely in 2.1.0. However Log4j1 API was _not_ removed.\n\n== Different Logging APIs\n\nThe fundamental interface is `org.osgi.service.log.LogService` from Chapter 101 of OSGi Compendium specification.\nThe history of `org.osgi.service.log` package versions is:\n\n* `1.0`: OSGi R1\n* `1.1`: OSGi R2\n* `1.2`: OSGi R3\n* `1.3`: OSGi R4, R4.1, R4.2, R4.3, R5, R6\n* `1.4`: OSGi R7\n* `1.5`: OSGi R8\n\npax-logging-api 1.x uses version `1.3` from OSGi Compendium R6.\n\npax-logging-api 2.0.x/2.1.x uses version `1.4` from OSGi Compendium R7.\n\npax-logging-api 2.2.x uses version `1.5` from OSGi Compendium R8.\n\nEach class that's an entry point to specific Logging framework (like `org.slf4j.LoggerFactory`) interacts with pax-logging using `org.ops4j.pax.logging.PaxLoggingManager`. This _manager_ tracks instances of framework-specific `org.ops4j.pax.logging.PaxLoggingService` services that eventually delegate to particular framework (like Log4J2).\n\nThis indirection allows to plug-in OSGi specific mechanism (like replacing `org.ops4j.pax.logging.PaxLoggingService` implementation at runtime) without refreshing (in OSGi terms) pax-logging-api bundle.\n\nThere's one important thing. Logging facades and frameworks share familiar concepts of _category_ (or a logger _name_). This concept was introduced (afair) in Log4J1 with tree-like _hierarchy_ of loggers where more general loggers could provide shared configuration (like appenders) for more particular loggers.\n\nOSGi Compendium `org.osgi.service.log.LogService` _doesn't_ have this notion of _category_, but (without a need to provide more technical details) pax-logging implements calls to `org.osgi.service.log.LogService.log()` method in such way that _category_ is (if possible) bundle's _symbolic name_. This _category_ is then used to get a logger from underlying logging backend.\n\nIn other words each `org.osgi.service.log.LogService.log()` call may be represended by this pseudo code:\n\n[listing,options=nowrap]\n----\n// calculate category\ncategory = try to take category from bundle's symbolic name\n\n// obtain logger from underlying backend, like Log4J2\nlogger = LoggerFactory.getLogger(bundle, category)\n\n// log a message according to specified level\nlogger.info(message, throwable) // or warn() or debug(), ...\n----\n\nBeing aware of this, it's actually better to _not_ use `org.osgi.service.log.LogService.log()` in your code directly and just use given logging facade (like SLF4J or Commons Logging) - this removes a need to obtain a logger (which is cached anyway) on each log call.\n\n=== OSGi R7 Log Service\n\nWith OSGi R7, standard Log Service gets a concept of _logger_. This makes the service easier to use - almost like de facto standard logging facades, where some _factory_ is used to obtain _loggers_ that are used to invoke logging methods.\n\nOSGi R7 adds new interface `org.osgi.service.log.LoggerFactory`, which is actually a new super interface of old `org.osgi.service.log.LogService` service.\n\nFactory methods that return instances of `org.osgi.service.log.Logger` by name or class are intuitive. There are however factory methods that take new argument: `Class\u003cL\u003e loggerType` where `\u003cL extends org.osgi.service.log.Logger\u003e`.\nThe only known/acceptable classes that can be passed to such factory methods are:\n\n* `org.osgi.service.log.Logger`\n* `org.osgi.service.log.FormatterLogger`\n\nBy passing `org.osgi.service.log.FormatterLogger.class` as an argument, user of factory method indicates that he/she wants to use printf-like formatting, for example:\n\n[listing,options=nowrap]\n----\nServiceReference\u003cLoggerFactory\u003e sr = context.getServiceReference(org.osgi.service.log.LoggerFactory.class);\nLoggerFactory loggerFactory = context.getService(sr);\norg.osgi.service.log.Logger log = loggerFactory.getLogger(\"com.example.service\", FormatterLogger.class);\nlog.info(\"Hello %s\", \"world\");\n----\n\nWhen passing `org.osgi.service.log.Logger.class` or when not passing anything, we assume Slf4J-like formatting:\n\n[listing,options=nowrap]\n----\nServiceReference\u003cLoggerFactory\u003e sr = context.getServiceReference(org.osgi.service.log.LoggerFactory.class);\nLoggerFactory loggerFactory = context.getService(sr);\norg.osgi.service.log.Logger log = loggerFactory.getLogger(\"com.example.service\");\nlog.info(\"Hello {}\", \"world\");\n----\n\n==== Fully Qualified Class Name\n\n`FQCN` concept is very important. It's used to _mark_ a place inside stack trace where code that invokes logging operation _transitions_ into the logging mechanism itself. Last stack frame before logging mechanism marks a _location_ that can be used to obtain class name, method name, file name and line number (so called _location info_). Before OSGi R7, it was quite easy to implement correctly, because all the logging methods where managed by Pax Logging itself and proper `FQCN` could be set. With OSGi R7 logging service, _logger_ is also a standard interface and logging methods may be called without any facade (like Slf4J).\n\nPax Logging had to carefuly handle all the _entry points_ into logging mechanism, to correctly determine `FQCN`.\n\n== Concepts\n\npax-logging is not trivial bridge to different (2 actually) logging frameworks (Log4J2, Logback), it also provides SPI layer that allows users to extend any logging framework. The most clear usage is when user wants to provide custom _appender_ that processes _logging events_.\n\n=== Logging events\n\nEach time a method like `log.info()` is called in any code fragment, new _logging event_ is created. This event is a representation of a fact that user wants to log some message/information. Each _logging event_ has some information associated like timestamp, code location (if available), message, exception (if needed) and severity (importance) of the event.\n\n=== Appenders\n\n_Appender_ is kind of processor that does something with the _logging event_ - usually appending new information (typically a line) to a file.\n\n=== Level and threshold\n\nThis is a bit confusing part. At first glance it looks trivial - when user wants to invoke logging method, he/she may use one of typical methods like `info()`, `warn()`, `trace()` or other.\n\nSimply from this set of alternatives we can derive the concept of _logging event level_ (or _severity_).\n\nLet's start with something we can treat as _canonical_ - https://en.wikipedia.org/wiki/Syslog#Severity_level[Syslog]. Here are the level names and their numerical equivalents:\n\n.Syslog levels\n|===\n|Numerical value |Severity/level name\n\n|0\n|Emergency\n\n|1\n|Alert\n\n|2\n|Critical\n\n|3\n|Error\n\n|4\n|Warning\n\n|5\n|Notice\n\n|6\n|Informational\n\n|7\n|Debug\n|===\n\nFrom the above, we can try to summarize:\n\n====\nNumerically _higher_ level is _less important_.\n====\n\nA concept related to _level_ is _threshold_. Without giving precise constraints, _threshold_ is a _limit_ for _logging events_. For the above, Syslog example, setting a _threshold_ value to _Warning_ means that we're interested in events with _Warning_ or (numerically) _lower_ events.\n\nThus:\n\n====\nThe _higher_ (numerically) the threshold, the more logging events are processed. Less important events are processed.\n====\n\n.Adding more confusion\n\nLogging frameworks (and APIs) used in pax-logging treat the _level_ concept differently... Log4J1 has direct relation to Syslog levels, but it's not a case with Log4J2 and java.util.logging.\nHere's a table where Syslog and Log4J1 can be directly related. Placement of levels from other libraries is a bit arbitrary and related to logging level name equivalents.\n\n* Log4J1: constants in `org.apache.log4j.Level` class\n* Log4J2: values in `org.apache.logging.log4j.spi.StandardLevel` enum\n* Logback: constants in `ch.qos.logback.classic.Level` class\n* java.util.logging: values in `java.util.logging.Level` class\n* Slf4J: constants in `org.slf4j.spi.LocationAwareLogger` interface\n* OSGi R6: constants in `org.osgi.service.log.LogService` interface\n* OSGi R7: values in `org.osgi.service.log.LogLevel` enum\n\n[options=nowrap]\n|===\n|Syslog |Log4J1 |Log4J2 |Logback|java.util.logging |SLF4J |OSGi R6|OSGi R7\n\n|0 - Emergency\n|Integer.MAX_VALUE - OFF\n|0 - OFF\n|Integer.MAX_VALUE - OFF\n|Integer.MAX_VALUE - OFF\n|\n|\n|0 - AUDIT\n\n|0 - Emergency\n|50000 - FATAL\n|100 - FATAL\n|\n|1000 - SEVERE\n|\n|\n|\n\n|1 - Alert\n|\n|\n|\n|\n|\n|\n|\n\n|2 - Critical\n|\n|\n|\n|\n|\n|\n|\n\n|3 - Error\n|40000 - ERROR\n|200 - ERROR\n|40000 - ERROR\n|1000 - SEVERE\n|40 - ERROR\n|1 - ERROR\n|1 - ERROR\n\n|4 - Warning\n|30000 - WARN\n|300 - WARN\n|30000 - WARN\n|900 - WARNING\n|30 - WARN\n|2 - WARNING\n|2 - WARN\n\n|5 - Notice\n|\n|\n|\n|\n|\n|\n|\n\n|6 - Informational\n|20000 - INFO\n|400 - INFO\n|20000 - INFO\n|800 - INFO, 700 - CONFIG\n|20 - INFO\n|3 - INFO\n|3 - INFO\n\n|7 - Debug\n|10000 - DEBUG\n|500 - DEBUG\n|10000 - DEBUG\n|500 - FINE\n|10 - DEBUG\n|4 - DEBUG\n|4 - DEBUG\n\n|7 - Debug\n|5000 - TRACE\n|600 - TRACE\n|5000 - TRACE\n|400 - FINER\n|0 - TRACE\n|\n|5 - TRACE\n\n|\n|\n|\n|\n|300 - FINEST\n|\n|\n|\n\n|7 - Debug\n|Integer.MIN_VALUE - ALL\n|Integer.MAX_VALUE - ALL\n|Integer.MIN_VALUE - ALL\n|Integer.MIN_VALUE - ALL\n|\n|\n|\n|===\n\nNotes and confusing parts:\n\n* Log4J1's `OFF` level matches numerical value of Syslog `Emergency` level\n* java.util.logging: there are too many less important levels (FINE, FINER, FINEST) and too little more critical ones (only SEVERE)\n* Syslog doesn't define _trace_ level, so its _debug_ entry is duplicated to cover constants from logging frameworks\n* Syslog, Log4J2 and OSGi use increasing numerical level for decreasing event importance\n* Log4J1, java.util.logging and SLF4J use higher numerical levels for more important events\n* Mapping of java.util.logging levels to more popular level names is implemented in `org.ops4j.pax.logging.spi.support.BackendSupport.toJULLevel()`\n* `OFF` and `ALL` special levels have to be treated carefully by pax-logging because the usage of numerical values is totally unintuitive.\n* OSGi R7 introduces `AUDIT` log level for _information that must always be logged_ - thus suggesting that it's _more than error_ - I've associated it with Syslog's `Emergency` level. Though matching value from `org.apache.log4j.Priority` has comment _is intended to turn off logging_.\n\n=== Markers\n\n_Markers_ allow to pass/associate additional, dynamic information with logging operation itself. Just as logger name (category) and level are static aspects of the logger itself, _marker_ is associated with single logging invocation (thus effectively with _logging event_). Single logger may be used to log message with or without marker and it's up to specific implementation (Logback, Log4J2) to handle the marker accordingly.\n\nFor example, Log4J1 doesn't support markers, so slf4j-log4j12 bridges to Log4J1 using `org.slf4j.helpers.MarkerIgnoringBase` abstract base class which simply ignores markers. Logback and Log4J2 implement _full_ `org.slf4j.spi.LocationAwareLogger` with marker support.\n\nMarkers are used usually by implementation-specific filters and appenders:\n\n* filters may be configured to restrict logging statements to ones using (or not using) particular marker\n* some appenders may simply do not do anything if specific marker is (or is not) present (for example that's the case with `ch.qos.logback.classic.boolex.OnMarkerEvaluator` that may be attached to `ch.qos.logback.classic.net.SMTPAppender`)\n\nFinally, a marker may have parent (or child) marker(s) associated - making them something slightly more complex than single _name_.\n\nIn Pax Logging, `org.ops4j.pax.logging.PaxLogger` interface didn't contain methods accepting markers. https://ops4j1.jira.com/browse/PAXLOGGING-160[PAXLOGGING-160] passed _marker_ as String attribute through thread-bound `org.ops4j.pax.logging.PaxContext`. https://ops4j1.jira.com/browse/PAXLOGGING-259[PAXLOGGING-259] adds such methods to this interface.\n\nRemember - in Pax Logging, it's possible to use for example Log4J2 _API_ to log information that's effectively handled by Logback, so despite the API being aware of markers, they may not be used correctly by actual logging implementation. As consequence, `isXXXEnabled(..., marker, ...)` methods may not be handled early in the process of logging.\n\n== SLF4J\n\n`slf4j-api-1.7.33-sources.jar` contains more sources than `slf4j-api-1.7.33.jar` has classes - in particular, `org.slf4j.impl` package is removed from the jar and the responsibility to provide:\n\n* `org.ops4j.impl.StaticLoggerBinder`\n* `org.ops4j.impl.StaticMDCBinder`\n* `org.ops4j.impl.StaticMarkerBinder`\n\nclasses lies on the side of _binding library_ for SLF4J API. Such classes are provided by (among others):\n\n* `logback-classic-1.2.10.jar`\n* `log4j-slf4j-impl-2.17.1.jar`\n* `slf4j-nop-1.7.33.jar`\n* `slf4j-log4j12-1.7.33.jar`\n* `slf4j-simple-1.7.33.jar`\n\npax-logging-api provides own implementation of these three classes. All other classes are directly repackaged (using bndlib) from `slf4j-api-1.7.33.jar` - classes that don't have to be changed are no longer shipped in pax-logging-api source directory.\n\n== Commons Logging\n\nWhile SLF4J takes simple and elegant approach for finding the actual implementation (`StaticLoggerBinder`), Commons Logging uses old school discovery through various ClassLoader and ServiceLoader tricks.\n\nIn pax-logging, all this discovery is not needed, so the only reimplemented class is `org.apache.commons.logging.LogFactory` with all the discovery code removed.\n\n== Apache JULI\n\nApache JULI is specialized (and repackaged) version of Commons Logging with original discovery mechanism already removed for Tomcat's internal logging mechanism purposes.\n\nIn pax-logging, there was less work to do - discovery mechanism was already removed, only `org.apache.juli.logging.LogFactory.getInstance(java.lang.String)` method was changed to delegate to `PaxLoggingManager`.\n\n== Avalon Logging\n\nAncient Avalon framework predates most (if not all) Java server frameworks aiming to provide code and component organization patterns and programming model. Without dealing much with archeology, pax-logging-api provides support for `org.apache.avalon.framework.logger` package where the ultimate _source of truth_ is https://svn.apache.org/repos/asf/excalibur/tags/avalon-framework-api-4.3-Release/framework/api/src/java/org/apache/avalon/framework/logger/[this SVN tag and directory].\n\nThere are no _factory methods_ to access Avalong loggers as we know from SLF4J or even from Commons Logging. There's simply new instance creation, where the reference may be assigned to `org.apache.avalon.framework.logger.Logger` interface. Thus pax-logging-api doesn't include any source from Avalon Framework. Simply implementation of `org.apache.avalon.framework.logger.Logger` is provided.\n\nExcalibur (actual library/framework using Avalon) simply provides concrete implementations of `org.apache.avalon.framework.logger.Logger`, like:\n\n* `org.apache.avalon.excalibur.logger.Log4JLogger`\n* `org.apache.avalon.framework.logger.NullLogger`\n* `org.apache.avalon.framework.logger.CommonsLogger`\n* `org.apache.avalon.excalibur.logger.ServletLogger`\n* `org.apache.avalon.framework.logger.Jdk14Logger`\n* `org.apache.avalon.framework.logger.ConsoleLogger`\n\nTo achieve _factory method_ approach, pax-logging-api exports `org.ops4j.pax.logging.avalon` package with special (not implied from Avalon Framework design) factory class for Avalon loggers. For other facades, package with factory classes is not `org.ops4j.pax.logging.*`.\n\n== JBoss Logging\n\nJBoss started to use dedicated logging _bridge_ (facade) with http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html[Hibernate 4.0]. Similarly to e.g., Commons Logging, actual logging framework is discovered at runtime.\n\nJBoss Logging can delegate to either concrete logging implementation (like Log4J2) or another logging facade (like SLF4J or Commons Logging). It uses discovery (ClassLoader + ServiceLoader) mechanism to find the framework to delegate to.\n\nOriginally, `org.jboss.logging.provider` property may be set to one of these values:\n\n* jboss\n* jdk\n* log4j2\n* log4j\n* slf4j\n\nThen discovery checks ServiceLoader for `org.jboss.logging.Provider` provider (`/META-INF/services/org.jboss.logging.Provider`).\n\npax-logging API doesn't yet delegate JBoss Logging API to pax-logging OSGi manager.\nhttps://ops4j1.jira.com/browse/PAXLOGGING-251[PAXLOGGING-251] tracks this issue.\n\n== Log4j\n\nAh, the grandfather of all configurable Logging frameworks. Created when there was no logging bridges/facades around. Actually first facade (Commons Logging) was created to bridge common logging API to one of different logging frameworks (back then, it was only Log4J1 and Java Util Logging (JUL) from JDK1.4).\n\nBecause its origins are in pre-logging bridge times, Log4J1's API was used directly by very large amount of code. That's why pax-logging fully supports its native API. However in Pax Logging 1.12.x and 2.1.x I've removed the implementation (in particular the appenders) based on Log4J1.\n\nAlso, this was the first logging framework embraced by pax-logging project itself.\n\nHere, the problem is with splitting original log4j:log4j JAR into API (for pax-logging-api) and implementation (for pax-logging-log4j1).\n\nThe original `Export-Package` header of log4j:log4j (yes - it is correct OSGi bundle) is (after formatting):\n\n[listing,options=nowrap]\n----\norg.apache.log4j;         version=\"1.2.17\"; uses:=\"org.apache.log4j.spi,org.apache.log4j.helpers,org.apache.log4j.pattern,org.apache.log4j.or,org.apache.log4j.config\",\norg.apache.log4j.config;  version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j,org.apache.log4j.spi\",\norg.apache.log4j.helpers; version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi,org.apache.log4j.pattern\",\norg.apache.log4j.jdbc;    version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi\",\norg.apache.log4j.jmx;     version=\"1.2.17\"; uses:=\"org.apache.log4j,javax.management,org.apache.log4j.helpers,org.apache.log4j.spi\",\norg.apache.log4j.net;     version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi,javax.naming,org.apache.log4j.helpers,javax.jms,org.apache.log4j.xml,javax.mail,javax.mail.internet,org.w3c.dom,javax.jmdns\",\norg.apache.log4j.nt;      version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j,org.apache.log4j.spi\",\norg.apache.log4j.or;      version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j.spi,org.apache.log4j\",\norg.apache.log4j.or.jms;  version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,javax.jms,org.apache.log4j.or\",\norg.apache.log4j.or.sax;  version=\"1.2.17\"; uses:=\"org.apache.log4j.or,org.xml.sax\",\norg.apache.log4j.pattern; version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j.spi,org.apache.log4j,org.apache.log4j.or\",\norg.apache.log4j.rewrite; version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi,org.apache.log4j.helpers,org.apache.log4j.xml,org.w3c.dom\",\norg.apache.log4j.spi;     version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.helpers,org.apache.log4j.or\",\norg.apache.log4j.varia;   version=\"1.2.17\"; uses:=\"org.apache.log4j.spi,org.apache.log4j,org.apache.log4j.helpers\"\norg.apache.log4j.xml;     version=\"1.2.17\"; uses:=\"javax.xml.parsers,org.w3c.dom,org.xml.sax,org.apache.log4j.config,org.apache.log4j.helpers,org.apache.log4j,org.apache.log4j.spi,org.apache.log4j.or\",\n----\n\nAdditionally, the jar contains:\n\n* org.apache.log4j.chainsaw\n* org.apache.log4j.lf5.*\n\npax-logging-api exports these (from log4j1):\n\n[listing,options=nowrap]\n----\norg.apache.log4j;     version=1.2.15; uses:=\"org.apache.log4j.spi org.ops4j.pax.logging org.osgi.framework\"\norg.apache.log4j.spi; version=1.2.15; uses:=\"org.apache.log4j\"\norg.apache.log4j.xml; version=1.2.15; uses:=\"javax.xml.parsers org.w3c.dom\"\n----\n\nI checked original `log4j:log4j` and started with single reexport of `org.apache.log4j` package. The closure of exports turned out to be:\n[listing,options=nowrap]\n----\nExport-Package:\n org.apache.log4j;         version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j.or,org.apache.log4j.spi\",\n org.apache.log4j.config;  version=\"1.2.17\"; uses:=\"org.apache.log4j\",\n org.apache.log4j.helpers; version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi\",\n org.apache.log4j.or;      version=\"1.2.17\"; uses:=\"org.apache.log4j.spi\",\n org.apache.log4j.pattern; version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.helpers,org.apache.log4j.spi\",\n org.apache.log4j.spi;     version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.or\",\n org.apache.log4j.xml;     version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.config,org.apache.log4j.spi\"\nImport-Package:\n com.ibm.uvm.tools;resolution:=optional\n----\n\n`com.ibm.uvm.tools` was additional import generated by analyzing (bndlib) `org.apache.log4j.spi.LocationInfo` class.\n\nSo the remaining exports from original `log4j:log4j` that are not part of the above closure are:\n[listing,options=nowrap]\n----\norg.apache.log4j.jdbc;    version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi\",\norg.apache.log4j.jmx;     version=\"1.2.17\"; uses:=\"org.apache.log4j,javax.management,org.apache.log4j.helpers,org.apache.log4j.spi\",\norg.apache.log4j.net;     version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi,javax.naming,org.apache.log4j.helpers,javax.jms,org.apache.log4j.xml,javax.mail,javax.mail.internet,org.w3c.dom,javax.jmdns\",\norg.apache.log4j.nt;      version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,org.apache.log4j,org.apache.log4j.spi\",\norg.apache.log4j.or.jms;  version=\"1.2.17\"; uses:=\"org.apache.log4j.helpers,javax.jms,org.apache.log4j.or\",\norg.apache.log4j.or.sax;  version=\"1.2.17\"; uses:=\"org.apache.log4j.or,org.xml.sax\",\norg.apache.log4j.rewrite; version=\"1.2.17\"; uses:=\"org.apache.log4j,org.apache.log4j.spi,org.apache.log4j.helpers,org.apache.log4j.xml,org.w3c.dom\",\norg.apache.log4j.varia;   version=\"1.2.17\"; uses:=\"org.apache.log4j.spi,org.apache.log4j,org.apache.log4j.helpers\"\n----\n\nNot exported packages:\n\n* org.apache.log4j.chainsaw\n* org.apache.log4j.lf5\n\n`pax-logging-log4j1` (before it was removed) did not export anything.\n\nAdditionally, apache-log4j-extras-1.2.17.jar has some new packages:\n\nOSGi Exported:\n\n* org.apache.log4j.extras\n* org.apache.log4j.filter\n* org.apache.log4j.rolling\n* org.apache.log4j.rule\n\nNot OSGi exported:\n\n* org.apache.log4j.component\n* org.apache.log4j.receivers\n\napache-log4j-extras-1.2.17.jar duplicates some packages from log4j-1.2.17.jar, but with additional classes (most of the classes are the same):\n\n* org.apache.log4j (has additional `DBAppender.class`, `LoggerRepositoryExImpl.class` (with 2 inner classes))\n* org.apache.log4j.pattern (has additional `ExtrasFormattingInfo.class`, `ExtrasPatternParser.class` and `ExtrasPatternParser$ReadOnlyMap.class`)\n* org.apache.log4j.spi (has additional `LoggingEventFieldResolver.class`)\n* org.apache.log4j.varia (has additional `SoundAppender.class`)\n* org.apache.log4j.xml (has additional `XSLTLayout.class`)\n\nWith PAXLOGGING-252, I'd like to make it easier to maintain pax-logging itself. The goals (and kind of work log) are:\n\n* if some classes are needed from original Log4J1 (and later with Log4J2 too) they should be Export-Packaged\n* if some classes have to be adjusted for pax-logging (OSGi in general), they should be copied _and committed_ without changing. Changes should be done in separate commit to distinguish original version from changes.\n* log4j classes should only be exported by pax-logging-api *or* Private-Packaged by pax-logging-log4j1 - never both (so far it was the case with `org.apache.log4j.Category`)\n* I'm going to export `org.apache.log4j` package with the closure of _uses_, which is:\n** org.apache.log4j\n** org.apache.log4j.config\n** org.apache.log4j.helpers\n** org.apache.log4j.or\n** org.apache.log4j.pattern\n** org.apache.log4j.spi\n** org.apache.log4j.xml\n* possibly the above list will change, if some pax-logging adjustments will remove some _uses_ from the closure.\n* I've removed _all_ log4j1 sources from pax-logging, I'm going to copy `org.apache.log4j.Logger`, `org.apache.log4j.MDC` and `org.apache.log4j.NDC` classes and the classes they require, reapply _all_ the changes done so far in pax-logging-api with better tracking (_diffability_, _cherrypickability_) and finally remove the sources that don't have changes (those classes will then be simply Export-Packaged from log4j:log4j dependency).\n* After adjusting some classes to pax-logging (like making configuration methods dummy), it turned out that these packages don't have to be exported:\n** org.apache.log4j.config\n** org.apache.log4j.xml\n* But because `org.apache.log4j.xml` was exported in previous versions of pax-logging-api, I'll leave it as is. Also because pax-logging-log4j1 requires some classes from `org.apache.log4j.config` and I don't want this bundle to duplicate any pax-logging-api classes (whether exported or private), I'll add export for `org.apache.log4j.config` package in pax-logging-api.\n\n.Update\n\nMy plan was to export the above set of packages from pax-logging-api and import them in pax-logging-log4j1 with few exceptions. Mainly, `org.apache.log4j.Logger` class _has to_ be exported by pax-logging-api (with changes related to delegation to pax-logging services), but it also _has to_ be private packaged in pax-logging-log4j1, because it actually has to call log4j:log4j functionality (like keeping hierarchy of loggers).\n\nOSGi R6 Core specification says:\n\n====\n*3.9.4 Overall Search Order*\n\nFrameworks must adhere to the following rules for class or resource loading. When a bundle's class\nloader is requested to load a class or find a resource, the search must be performed in the following\norder:\n\n…\n\n*3*. If the class or resource is in a package that is imported using Import-Package or was imported dynamically in a previous load, then the request is delegated to the exporting bundle's class loader [...]\n\n...\n\n*5*. Search the bundle's embedded classpath.\n====\n\nSo it was not possible:\n\n* to have changed `org.apache.log4j.Logger` class exported from in pax-logging-api and\n* to have unchanged `org.apache.log4j.Logger` class private-packaged in pax-logging-log4j1, while other classes from `org.apache.log4j` package kept being imported from pax-logging-api\n\nThe only solution is to *not* import `org.apache.log4j` package from pax-logging-api to pax-logging-log4j1 bundle.\nSome Maven tricks (`maven-dependency-plugin:unpack`) have to be involved.\n\nThis is set of rules I found:\n\n* first, pax-logging-api has to export consistent set of packages, even if some classes are adjusted for OSGi purposes. This is easy by Export-Packaging and copying to `src/main/java` if needed\n* if pax-logging-log4j1 can use *all* the classes from one of the above exported packages from pax-logging-api, it should import them\n* if there's at least one class from the above exported packages, that has to be different in pax-logging-log4j1 (like `org.apache.log4j.Category` or `org.apache.log4j.helpers.AppenderAttachableImpl`), then pax-logging-log4j1 has to Private-Package such package\n* but because Private-Package handling (by maven-bundle-plugin and bndlib) involves discovery using classpath, we have to be careful. We can only assume that `org.apache.felix.bundleplugin.BundlePlugin.getClasspath()` method uses `currentProject.getBuild().getOutputDirectory()` as *first* directory/location when checking the package.\n* because `org.apache.log4j` package is available both from pax-logging-api and log4j:log4j (and log4j:apache-log4j-extras) dependencies of pax-logging-log4j1, we have to ensure that classes from log4j:log4j are taken. Instead of relying on `\u003cdependency\u003e` order in pax-logging-log4j1 POM, we rather use `maven-dependency-plugin:unpack` with this configuration:\n\n=== Summary of package splitting for Log4J1 (deprecated information in 1.12.x and 2.1.x)\n\nI think users deserve this summary, because there are 4 bundles/jars:\n\n* pax-logging-api\n* pax-logging-log4j1 (the Log4J1 _backend_)\n* log4j:log4j - the implementation\n* log4j:apache-log4j-extras which is log4j:log4j + some additional classes\n\nAnd there's this design flaw that single JAR is treated as both API and Implementation (what's worse - some packages mix API and Implementation classes).\n\nlog4j:apache-log4j-extras source JAR (and github repository) duplicates these packages from log4j:log4j:\n\n* org.apache.log4j\n* org.apache.log4j.pattern\n* org.apache.log4j.spi\n* org.apache.log4j.varia\n* org.apache.log4j.xml\n\nBut fortunately doesn't duplicate any of actual source files.\n\nlog4j:apache-log4j-extras JAR duplicates the above packages where the classes are simply merged from own project and from log4j:log4j JAR. However, pax-logging-api re-exports `org.apache.log4j`, `org.apache.log4j.pattern`, `org.apache.log4j.spi` and `org.apache.log4j.xml` from the log4j:log4j JAR, not from log4j:apache-log4j-extras, because some additional classes (like `org.apache.log4j.DBAppender`) introduce too many additional packages that have to be re-exported (because of `uses` clause).\n\nHere's full list of packages and notes about how it's used in pax-logging.\n\norg.apache.log4j::\nThis is the main package mixing all kinds of classes (API, Implementation, internal functionality, ...)\n\n* pax-logging-api re-exports all the classes from log4j:log4j, but `BasicConfigurator`, `Category`, `Hierarchy`, `Logger`, `LogManager`, `MDC`, `NDC`, `Priority` and `PropertyConfigurator` are changed to adjust them for OSGi/pax-logging requirements. The changes turn some methods into noop variants. While factory methods (the most important _get logger_ for example) delegate to pax logging services to obtain loggers.\n* pax-logging-log4j1 doesn't import this package from pax-logging-api, instead it Private-Packages all the classes from log4j:apache-log4j-extras without exporting, but there are some additional and changed classes:\n** `AsyncAppender` has fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-101[PAXLOGGING-101] and https://ops4j1.jira.com/browse/PAXLOGGING-182[PAXLOGGING-182]\n** `Category` has fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-99[PAXLOGGING-99] and https://ops4j1.jira.com/browse/PAXLOGGING-182[PAXLOGGING-182]\n** `ConsoleAppender` has fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-90[PAXLOGGING-90]\n** There's new `DailyZipRollingFileAppender` class related to https://ops4j1.jira.com/browse/PAXLOGGING-226[PAXLOGGING-226] - it's not available in original Log4J1\n** There's new `OsgiThrowableRenderer` introduced with https://ops4j1.jira.com/browse/PAXLOGGING-80[PAXLOGGING-80]\n** There's new `PaxLoggingConfigurator` that handles special, OSGi configuration parsing (with references to OSGi services implementing interfaces from `org.ops4j.pax.logging.spi` package)\n** There's new `SanitizingPatternLayout` introduced with https://ops4j1.jira.com/browse/PAXLOGGING-201[PAXLOGGING-201]\n\norg.apache.log4j.chainsaw::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.component.*::\nThis package (and subpackages) comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.config::\nThis package comes from log4j:log4j.\n\n* It's exported from pax-logging-api without changes\n* It's Private-Packaged in pax-logging-log4j1 from log4j:log4j without importing from pax-logging-api. There's one additional class:\n** `PaxPropertySetter' which is a copy of `PropertySetter` with fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-83[PAXLOGGING-83]\n\norg.apache.log4j.extras::\nThis package comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.filter::\nThis package comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1. pax-logging-log4j1 contains additional classes:\n\n* `MatchFilterBase` and `MDCMatchFilter` come from abandoned Log4J 1.3 release moved at some point to log4j-sandbox\n\norg.apache.log4j.helpers::\nThis package is tricky. It's in `uses` closure of packages exported from pax-logging-api, but pax-logging-log4j1 can't import it. pax-logging-log4j1 fixes performance problems with `AppenderAttachableImpl`, but it can't import this package from pax-logging-api, because it can't import `org.apache.log4j` package and this _root_ package contains `org.apache.log4j.Appender` class which is used as argument to some of `AppenderAttachableImpl` methods.\n\n* pax-logging-api re-exports this package from log4j:log4j and:\n** changes `Loader` class to load classes using OSGi methods\n** changes `LogLog` class to delegate to fallback logger from pax-logging-api itself\n** adds `MessageFormatter` class from sandbox/abandoned Log4J1 1.3\n\n* pax-logging-log4j1 Private-Packages this package from ... pax-logging-api (to include the fixes for `Loader` and `LogLog` classes) and:\n** `AppenderAttachableImpl` has fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-182[PAXLOGGING-182]\n\norg.apache.log4j.jdbc::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.jmx::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.lf5.*::\nThis package (and subpackages) comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.net::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.nt::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.or (Object Renderer)::\n\n* pax-logging-api re-exports this package from log4j:log4j without changes, because it's in the `uses` closure of the exported Log4J1 API.\n* pax-logging-log4j1 imports this package from pax-logging-api, because it doesn't add any own changes\n\norg.apache.log4j.or.jms::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.or.sax::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.pattern::\nThis package comes from log4j:log4j, but log4j:apache-log4j-extras adds `ExtrasFormattingInfo` and `ExtrasPatternParser`.\n\n* pax-logging-api exports this package from log4j:log4j (because pax-logging-api can't have Maven dependency on log4j:apache-log4j-extras) and keeps a copy if these two additional classes taken directly from log4j:apache-log4j-extras\n* pax-logging-log4j1 imports this package from pax-logging-api\n\norg.apache.log4j.receivers.*::\nThis package (and subpackages) comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.rewrite::\nThis package comes from log4j:log4j and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.rolling.*::\nThis package (and subpackages) comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1.\n\n* `RollingFileAppender` has fixes related to https://ops4j1.jira.com/browse/PAXLOGGING-189[PAXLOGGING-189]\n\norg.apache.log4j.rule::\nThis package comes from log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.sift::\nThat's entirely pax-logging-log4j1 private package with `MDCSiftingLoggingAppender` class created for https://ops4j1.jira.com/browse/PAXLOGGING-83[PAXLOGGING-83]\n\norg.apache.log4j.spi::\n\n* pax-logging-api re-exports this package from log4j:log4j without changes\n* pax-logging-log4j1 doesn't import this package from pax-logging-api, instead, it Private-Packages it from both log4j:log4j and log4j:apache-log4j-extras.\n** log4j:apache-log4j-extras has `LoggingEventFieldResolver` - it couldn't be exported from pax-logging-api because it requires classes from `org.apache.log4j.rule` package, which we don't want to export from pax-logging-api\n** pax-logging-log4j1 adds `OptionFactory` - new class created for https://ops4j1.jira.com/browse/PAXLOGGING-83[PAXLOGGING-83]\n\norg.apache.log4j.varia::\nThis package comes from both log4j:log4j and log4j:apache-log4j-extras and is Private-Packaged in pax-logging-log4j1 without changes.\n\norg.apache.log4j.xml::\nThis package comes from both log4j:log4j and log4j:apache-log4j-extras (which adds `XSLTLayout` class).\n\n* pax-logging-api re-exports this package from log4j:log4j, and:\n** adds `XSLTLayout` copied directly from log4j:apache-log4j-extras to own `src/main/java`\n** changes `DOMConfigurator`, so methods are effectively no-op\n* pax-logging-log4j1 imports this package from pax-logging-api\n\norg.apache.log4j.zip::\nThat's entirely pax-logging-log4j1 private package with `ZipRollingFileAppender` class created for https://ops4j1.jira.com/browse/PAXLOGGING-116[PAXLOGGING-116]\n\n=== Location Info\n\nWhen Log4J1 is used with pattern layout that deals with class/method names and/or file names and line numbers, there's a need to analyze stack trace to get this info.\n\nWhen log4J1 is called normally, without ANY facade (and outside of pax-logging), the relevant stack trace fragment is:\n\n[listing,options=nowrap]\n----\n\"main@1\" prio=5 tid=0x1 nid=NA runnable\n  java.lang.Thread.State: RUNNABLE\n\t  at org.apache.log4j.spi.LocationInfo.\u003cinit\u003e(LocationInfo.java:144)\n\t  at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)\n\t  at org.apache.log4j.helpers.PatternParser$LocationPatternConverter.convert(PatternParser.java:500)\n\t  at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)\n\t  at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)\n\t  at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)\n\t  at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)\n\t  at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)\n\t  at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)\n\t  at org.apache.log4j.Category.callAppenders(Category.java:206)\n\t  at org.apache.log4j.Category.forcedLog(Category.java:391)\n\t  at org.apache.log4j.Category.info(Category.java:666)\n\t  at org.ops4j.pax.logging.test.log4j1.Log4j1NativeApiTest.loggerAPI(Log4j1NativeApiTest.java:80)\n...\n----\n\nThe discovered class name shuold be `org.ops4j.pax.logging.test.log4j1.Log4j1NativeApiTest`.\nWhat log4j ensures to make it work is passing `org.apache.log4j.Category.FQCN` (or `org.apache.log4j.Logger.FQCN`) value down through `org.apache.log4j.Category.forcedLog` method. Then the last stack trace element before `FQCN` is used to collection location info.\n\nWhen Log4J1 is used through SLF4J, `org.slf4j.impl.Log4jLoggerAdapter.FQCN` is used to pass through `org.apache.log4j.Category.log()` and `org.apache.log4j.Category.callAppenders()`.\n\nWith pax-logging, the stack trace is a bit more complex:\n[listing,options=nowrap]\n----\n\"Karaf Shell Console Thread@9179\" daemon prio=5 tid=0x31 nid=NA runnable\n  java.lang.Thread.State: RUNNABLE\n\t  at org.apache.log4j.spi.LocationInfo.\u003cinit\u003e(LocationInfo.java:136)\n\t  at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)\n\t  at org.apache.log4j.helpers.PatternParser$ClassNamePatternConverter.getFullyQualifiedName(PatternParser.java:555)\n\t  at org.apache.log4j.helpers.PatternParser$NamedPatternConverter.convert(PatternParser.java:528)\n\t  at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)\n\t  at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)\n\t  at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)\n\t  at org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)\n\t  at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)\n\t  at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)\n\t  - locked \u003c0x2402\u003e (a org.apache.log4j.RollingFileAppender)\n\t  at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:59)\n\t  at org.apache.log4j.Category.callAppenders(Category.java:179)\n\t  at org.apache.log4j.Category.forcedLog(Category.java:333)\n\t  at org.apache.log4j.Category.log(Category.java:724)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:152)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:145)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.inform(PaxLoggerImpl.java:179)\n\t  at org.ops4j.pax.logging.internal.TrackingLogger.inform(TrackingLogger.java:86)\n\t  at org.ops4j.pax.logging.slf4j.Slf4jLogger.info(Slf4jLogger.java:476)\n\t  at org.ops4j.pax.logging.test.log4j1.Log4j1PaxLoggingApiTest.loggerAPI(...)\n...\n----\n\nAnd the FQCN that's equal to `org.ops4j.pax.logging.slf4j.Slf4jLogger` is ensured by pax-logging-api and shaded classes from given facade (here - SLF4J).\n\nWhen pax-logging is used with Log4J1 and without SLF4J, stack trace is like:\n[listing,options=nowrap]\n----\n\"Karaf Shell Console Thread@9190\" daemon prio=5 tid=0x31 nid=NA runnable\n  java.lang.Thread.State: RUNNABLE\n\t  at org.apache.log4j.spi.LocationInfo.\u003cinit\u003e(LocationInfo.java:136)\n\t  at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)\n\t  at org.apache.log4j.helpers.PatternParser$ClassNamePatternConverter.getFullyQualifiedName(PatternParser.java:555)\n\t  at org.apache.log4j.helpers.PatternParser$NamedPatternConverter.convert(PatternParser.java:528)\n\t  at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)\n\t  at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)\n\t  at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)\n\t  at org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)\n\t  at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)\n\t  at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)\n\t  - locked \u003c0x240e\u003e (a org.apache.log4j.RollingFileAppender)\n\t  at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:59)\n\t  at org.apache.log4j.Category.callAppenders(Category.java:179)\n\t  at org.apache.log4j.Category.forcedLog(Category.java:333)\n\t  at org.apache.log4j.Category.log(Category.java:724)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:152)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:145)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.inform(PaxLoggerImpl.java:179)\n\t  at org.ops4j.pax.logging.internal.TrackingLogger.inform(TrackingLogger.java:86)\n\t  at org.apache.log4j.Category.info(Category.java:623)\n\t  at org.apache.log4j.Logger.info(Logger.java:585)\n\t  at org.ops4j.pax.logging.test.log4j1.Log4j1PaxLoggingApiTest.loggerAPI(...)\n...\n----\n\nSo the FQCN should be `org.apache.log4j.Logger`. Even if the logger is obtained via `org.apache.log4j.Category` static methods, the logger is of `org.apache.log4j.Logger` class and stack trace analysis works without problems.\nAlso, trace/debug/info/warn/error/fatal methods are defined in `Category` class, but overriden in `Logger`, to properly detect the calling class/method.\n\nBut not all logging methods are overriden...\n[listing,options=nowrap]\n----\n\"Karaf Shell Console Thread@9205\" daemon prio=5 tid=0x31 nid=NA runnable\n  java.lang.Thread.State: RUNNABLE\n\t  at org.apache.log4j.spi.LocationInfo.\u003cinit\u003e(LocationInfo.java:136)\n\t  at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)\n\t  at org.apache.log4j.helpers.PatternParser$ClassNamePatternConverter.getFullyQualifiedName(PatternParser.java:555)\n\t  at org.apache.log4j.helpers.PatternParser$NamedPatternConverter.convert(PatternParser.java:528)\n\t  at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)\n\t  at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)\n\t  at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)\n\t  at org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)\n\t  at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)\n\t  at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)\n\t  - locked \u003c0x240c\u003e (a org.apache.log4j.RollingFileAppender)\n\t  at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:59)\n\t  at org.apache.log4j.Category.callAppenders(Category.java:179)\n\t  at org.apache.log4j.Category.forcedLog(Category.java:333)\n\t  at org.apache.log4j.Category.log(Category.java:724)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:152)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:145)\n\t  at org.ops4j.pax.logging.log4j1.internal.PaxLoggerImpl.inform(PaxLoggerImpl.java:179)\n\t  at org.ops4j.pax.logging.internal.TrackingLogger.inform(TrackingLogger.java:86)\n\t  at org.apache.log4j.Category.info(Category.java:644)\n\t  at org.apache.log4j.Logger.info(Logger.java:589)\n\t  at org.apache.log4j.Category.log(Category.java:858)\n\t  at org.apache.log4j.Category.log(Category.java:829)\n\t  at org.ops4j.pax.logging.test.log4j1.Log4j1PaxLoggingApiTest.loggerAPI(...)\n...\n----\n\nWhen calling `org.apache.log4j.Category.log(org.apache.log4j.Priority, java.lang.Object)` directly, the method is defined in `Category` class, so when analyzing stack trace, `org.apache.log4j.Category.log(Category.java:858)` will be detected as logging event location. This will be fixed with PAXLOGGING-252.\n\nThe location info should be `org.ops4j.pax.logging.test.OsgiLogServiceApiTest.logServiceAPI()`.\nFQCN is ... `\"\"` location can't be found and in logs we can see (for pattern `%d{ISO8601} | %-5.5p | {%t} [%c]/[%C] (%F:%L) | %m%n` and symbolic name = `my-bundle`):\n[listing,options=nowrap]\n----\n2019-04-26 08:11:53,126 | INFO  | {Karaf Shell Console Thread} [my-bundle]/[?] (?:?) | Hello!\n----\n\n=== API / Implementation separation\n\nThe biggest problem with Log4J1 is not only OSGi-specific problem of having API and implementation classes in single log4j:log4j library. Even methods are mixed within _single class_.\n\n`org.apache.log4j.Logger` (together with its superclass `org.apache.log4j.Category`) class contains ~80 methods.\nThese methods can be groupped into:\n\n* factory methods used to obtain a _logger_ (which is of the same instance `org.apache.log4j.Logger`): `getLogger`, `getInstance`, `getRootLogger`, ...\n* logging methods used to log messages: `info`, `debug`, `warn`, ... (with different parameter list)\n* logging threshold methods: `isInfoEnabled`, `isDebugEnabled`, ...\n* methods related to appenders: `addAppender`, `isAttached`, ... - these methods allow (in original usage) to attach appenders to loggers dynamically. In OSGi it doesn't make sense, because Log4J1 *API* may be used to log messages which are eventually handled by Logback or Log4J2 backend (or even `DefaultServiceLog` if pax-logging backend is not (yet) installed)\n* methods related to logger configuration: `getAddittivity`, `getParent`, `setLevel`, ...\n* meta methods related to _logging repository_: `getCurrentCategories`, `getHierarchy`, `getLoggerRepository`, `shutdown`, ... - these methods are generally throwing `UnsupportedOperationException` in pax-logging-api.\n\nThe above groupping is much better implemented in other logging frameworks which have separate logger and factory classes and also do the configuration and all the _meta_ in different way (than through single _logger_ class).\n\n== Logback\n\nAs mentioned on https://logback.qos.ch/[project's web page], Logback _picks up where log4j leaves off_.\n\nLogback was created after the logging-bridge (r)evolution and even if it may be used without any logging facade/bridge, it is very uncommon to do so. That's why there are no special API classes in pax-logging-api related to Logback. Logback is handled by pax-logging _only_ through implementation of `org.ops4j.pax.logging.PaxLoggingService`.\n\nLogback is mostly used behind SLF4J facade and both logger factory and MDC/NDC API comes from SLF4J itself when dealing with Logback.\n\nLogback is initialized using `org.slf4j.impl.StaticLoggerBinder` Slf4J mechanism - but only if such class is\nexplicitly requested/loaded (e.g., through `org.slf4j.LoggerFactory.getLogger()` and `org.slf4j.LoggerFactory.bind()`).\nWith pax-logging-logback, Logback's version of `org.slf4j.impl.StaticLoggerBinder` is neither exported nor used.\n\npax-logging-logback implementation of `org.ops4j.pax.logging.PaxLoggingService` explicitly configures `ch.qos.logback.classic.LoggerContext` instance (which, by the way, implements `org.slf4j.ILoggerFactory`).\n\n=== Logback contrib\n\nSee https://github.com/qos-ch/logback-contrib\n\nThere are several additional JARs we Private-Package in pax-logging-logback:\n\n* logback-jackson\n* logback-json-core\n* logback-json-classic\n\nAfter private-packaging the above, I've adjusted the generated `Import-Package` header providing explicit version ranges for Groovy and Jackson and making some imports optional.\n\n== Log4J2\n\nAfter huge (in my humble, subjective opinion) success of Logback, Log4J2 was created as modernized version of original Log4j project with full awareness of logging bridges/facades and weird properties file syntax.\n\npax-logging provides dedicated implementation of `org.ops4j.pax.logging.PaxLoggingService` that delegates to Log4J2.\n\nAgain, Log4J2 itself may be used without bridge/facade and (differently than with Logback) pax-logging fully supports its native API.\n\nHere's a list of all `org.apache.logging.log4j` artifacts I found in version 2.11.2:\n\n* org.apache.logging.log4j:log4j-api\n* org.apache.logging.log4j:log4j-1.2-api\n* org.apache.logging.log4j:log4j-appserver\n* org.apache.logging.log4j:log4j-cassandra\n* org.apache.logging.log4j:log4j-core\n* org.apache.logging.log4j:log4j-couchdb\n* org.apache.logging.log4j:log4j-flume-ng\n* org.apache.logging.log4j:log4j-iostreams\n* org.apache.logging.log4j:log4j-jcl\n* org.apache.logging.log4j:log4j-jdbc-dbcp2\n* org.apache.logging.log4j:log4j-jmx-gui\n* org.apache.logging.log4j:log4j-jpa\n* org.apache.logging.log4j:log4j-jul\n* org.apache.logging.log4j:log4j-liquibase\n* org.apache.logging.log4j:log4j-mongodb2\n* org.apache.logging.log4j:log4j-mongodb3\n* org.apache.logging.log4j:log4j-osgi\n* org.apache.logging.log4j:log4j-slf4j-impl\n* org.apache.logging.log4j:log4j-slf4j18-impl\n* org.apache.logging.log4j:log4j-slf4j2-impl\n* org.apache.logging.log4j:log4j-taglib\n* org.apache.logging.log4j:log4j-to-slf4j\n* org.apache.logging.log4j:log4j-web\n\nCurrently, pax-logging uses 3:\n\n* org.apache.logging.log4j:log4j-api\n* org.apache.logging.log4j:log4j-core\n* org.apache.logging.log4j:log4j-slf4j2-impl\n\nI'm going to include some more just like with `log4j:apache-log4j-extras` and `ch.qos.logback.contrib`.\n\nThese won't be supported/embedded/referenced:\n\n* org.apache.logging.log4j:log4j-1.2-api - it's Log4J1 \"API\" (with all the restrictions I mentioned when talking about API/Impl separation problems of Log4J1) and actually it's very similar to how pax-logging-api itself changes original Log4J1 classes\n* org.apache.logging.log4j:log4j-jcl - it's Apache Commons Logging _service_ defined in `/META-INF/services/org.apache.commons.logging.LogFactory`, effectively bridging Apache Commons Logging directly into Log4J2. pax-logging-api does it a bit differently.\n* org.apache.logging.log4j:log4j-jul - it provides `java.util.logging.LogManager` implementation to be used with `-Djava.util.logging.manager` system property. pax-logging-api however registers global `java.util.logging.Handler` which bridges Java Util Logging into pax-logging.\n* org.apache.logging.log4j:log4j-slf4j-impl - provides org.apache.logging.slf4j.Log4jLoggerFactory which is implementation of Slf4J's `org.slf4j.ILoggerFactory`. pax-logging-api provides own `org.slf4j.impl.StaticLoggerBinder` with own `org.slf4j.ILoggerFactory` implementation\n* org.apache.logging.log4j:log4j-slf4j18-impl - just like the above, but for Slf4J 1.8.x (still beta at the time of writing)\n* org.apache.logging.log4j:log4j-to-slf4j - is a library that enforces kind of _reversed_ usage. Log4J2 API calls are directed to Slf4J which (by design) has to be bridged to target logging framework. See https://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html. This definitely isn't something pax-logging should support.\n* org.apache.logging.log4j:log4j-osgi - strange \"bundle\" including only some non-pax-exam tests that install other Log4J2 bundles.\n* org.apache.logging.log4j:log4j-appserver - `org.apache.logging.log4j.appserver.jetty.Log4j2Logger` (Jetty) and `org.apache.logging.log4j.appserver.tomcat.TomcatLogger` (Tomcat JULI) implementations\n* org.apache.logging.log4j:log4j-web - `/META-INF/services/javax.servlet.ServletContainerInitializer` service that installs `org.apache.logging.log4j.web.Log4jServletFilter` filter and `org.apache.logging.log4j.web.Log4jServletContextListener` listener\n* org.apache.logging.log4j:log4j-taglib - `http://logging.apache.org/log4j/tld/log` tag library to be used in JSP pages\n* org.apache.logging.log4j:log4j-jmx-gui - `/META-INF/services/com.sun.tools.jconsole.JConsolePlugin` service for JConsole.\n* org.apache.logging.log4j:log4j-liquibase - bridges `liquibase.logging.core.AbstractLogger` into Log4J2\n\nThe remaining Log4J2 artifacts can be split into 3 categories:\n\n* API - log4j-api - to be included in (handled by) pax-logging-api (I hope)\n* Implementation - log4j-core - to be included in pax-logging-log4j2\n* Additional appenders, specialized `org.apache.logging.log4j.core.appender.db.jdbc.AbstractConnectionSource` or similar extensions:\n** log4j-iostreams - `java.io` bridges to Log4J2. See https://logging.apache.org/log4j/2.x/log4j-iostreams/index.html\n** log4j-jdbc-dbcp2\n** log4j-jpa\n** log4j-cassandra\n** log4j-couchdb\n** log4j-mongodb2\n** log4j-mongodb3\n** log4j-flume-ng - see https://logging.apache.org/log4j/2.x/log4j-flume-ng/index.html\n\nThe original exports of `org.apache.logging.log4j:log4j-api` are:\n\n[listing,options=nowrap]\n----\norg.apache.logging.log4j;         version=\"2.11.2\"; uses:=\"org.apache.logging.log4j.message, org.apache.logging.log4j.spi, org.apache.logging.log4j.util\"\norg.apache.logging.log4j.message; version=\"2.11.2\"; uses:=\"org.apache.logging.log4j.util\"\norg.apache.logging.log4j.simple;  version=\"2.11.2\"; uses:=\"org.apache.logging.log4j,org.apache.logging.log4j.message,org.apache.logging.log4j.spi,org.apache.logging.log4j.util\"\norg.apache.logging.log4j.spi;     version=\"2.11.2\"; uses:=\"org.apache.logging.log4j,org.apache.logging.log4j.message,org.apache.logging.log4j.util\"\norg.apache.logging.log4j.status;  version=\"2.11.2\"; uses:=\"org.apache.logging.log4j,org.apache.logging.log4j.message,org.apache.logging.log4j.spi\"\norg.apache.logging.log4j.util;    version=\"2.11.2\"; uses:=\"org.apache.logging.log4j.message,org.apache.logging.log4j.spi,org.osgi.framework\"\n----\n\nThis perfectly matches what pax-logging-api (re)exported. These are actually all the packages included in `org.apache.logging.log4j:log4j-api`.\n\n=== Plugins\n\nLog4J2 is extended using plugin system. Quoting http://lo[the manual]:\n\n====\nIn Log4j 2 a plugin is declared by adding a `@Plugin` annotation to the class declaration. During initialization the `Configuration` will invoke the `PluginManager` to load the built-in Log4j plugins as well as any custom plugins. The `PluginManager` locates plugins by looking in five places:\n\n1. Serialized plugin listing files on the classpath. These files are generated automatically during the build (more details below).\n2. (OSGi only) Serialized plugin listing files in each active OSGi bundle. A BundleListener is added on activation to continue checking new bundles after log4j-core has started.\n3. A comma-separated list of packages specified by the log4j.plugin.packages system property.\n4. Packages passed to the static PluginManager.addPackages method (before Log4j configuration occurs).\n5. The packages declared in your log4j2 configuration file.\n====\n\nCurrently, pax-logging doesn't do the same discovery as bundle activator of original `org.apache.logging.log4j:log4j-core`.\nThough similar mechanism may be added in the future.\n\n`org.apache.logging.log4j.core.config.plugins.util.PluginManager.collectPlugins()` collects the plugins from different sources. The cache file is declared as `org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor.PLUGIN_CACHE_FILE` and refers to `META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat`. It's a binary file conforming to `java.io.DataInputStream` which may occur multiple times on the classpath.\n\npax-logging-log4j2 bundle directly uses the original plugin cache file from `org.apache.logging.log4j:log4j-core` and additional plugins are added using `org.apache.logging.log4j.core.config.plugins.util.PluginManager.addPackage()` during pax-logging-log4j2 initialization.\n\nDefault cache file contains exactly these categories and numbers of plugins (206 total):\n[listing,options=nowrap]\n----\ncache = {org.apache.logging.log4j.core.config.plugins.processor.PluginCache@1030}\n categories: java.util.Map  = {java.util.LinkedHashMap@1059}  size = 6\n  \"core\" -\u003e {java.util.LinkedHashMap@1069}  size = 117\n  \"converter\" -\u003e {java.util.LinkedHashMap@1071}  size = 44\n  \"lookup\" -\u003e {java.util.LinkedHashMap@1073}  size = 13\n  \"configurationfactory\" -\u003e {java.util.LinkedHashMap@1075}  size = 4\n  \"fileconverter\" -\u003e {java.util.LinkedHashMap@1077}  size = 2\n  \"typeconverter\" -\u003e {java.util.LinkedHashMap@1079}  size = 26\n----\n\n=== Configuration\n\nLog4J2 has complex configuration mechanisms and can process configuration from different sources. Configuration may be stored in XML, JSON, YAML and properties files. Among these, properties file (very common in Log4J1 times) is the most confusing...\n\n`org.apache.logging.log4j.core.config.builder.impl.DefaultConfigurationBuilder` is the most important class here that allows to understand how configuration is organized. This builder includes `org.apache.logging.log4j.core.config.builder.api.Component` _components_ for these _concepts_:\n\n* root\n* loggers\n* appenders\n* filters\n* properties\n* custom levels\n* scripts\n\n`org.apache.logging.log4j.core.config.builder.api.Component` is generally a container for:\n\n* attributes (a map)\n* child `org.apache.logging.log4j.core.config.builder.api.Component` instances\n* plugin type\n* name\n\nPlugin types of components inside \"root\" component may be one of:\n\n* \"Scripts\"\n* \"Loggers\"\n* \"Appenders\"\n* \"Filters\"\n* \"Properties\"\n* \"CustomLevels\"\n\nBut generally, plugin _type_ is a key for org.apache.logging.log4j.core.config.plugins.util.PluginManager.plugins map which maps names to `org.apache.logging.log4j.core.config.plugins.util.PluginType`\n\n== Testing in Karaf\n\nThat's tricky problem. If we want to use Pax Exam and test Pax Logging under Karaf with Maven we have to consider:\n\n* Maven runs maven-surefire|failsafe-plugin test in separate JVM (by default)\n* When using `pax-exam-container-karaf`, 3rd JVM process is launched\n* We can't use normal Karaf (even minimal one) because it uses fixed pax-logging version for bundles started from `etc/startup.properties`\n* So we have to prepare custom Karaf distribution, where initial (startup) bundles are the ones from current Pax Logging version (the one being tested)\n\nThen, taking into account the logging process itself:\n\n* We want logging statement issued by pax-exam itself to be handled properly (before launching Karaf) - ideally using `src/test/resources/log4j2-test.properties`\n* Thus `test` classpath has to contain `org.slf4j:slf4j-api` and `org.apache.logging.log4j:log4j-slf4j2-impl`\n* Karaf has to start without any `org.ops4j.pax.logging` PID configured, but we want logging statements to be handled properly even if invoked from pax-logging-api bundle activator\n* Thus proper _default service log_ has to be configured in `etc/config.properties`\n* Remember that maven-surefire|failsafe-plugin can be configured with `\u003credirectTestOutputToFile\u003e`\n\nSummarizing (for `pax-logging-it-karaf/karaf-it`):\n\n* there's `src/test/resources/log4j2-test.properties` with `Console` and `RollingFile` appenders. Both will start and end logging with these:\n[listing,options=nowrap]\n----\nEXAM\u003e 12:22:55.205 [main] INFO  (DefaultExamSystem.java:127) org.ops4j.pax.exam.spi.DefaultExamSystem - Pax Exam System (Version: 4.13.1) created.\n...\nEXAM\u003e 12:22:59.423 [main] INFO  (ReactorManager.java:444) org.ops4j.pax.exam.spi.reactors.ReactorManager - suite finished\n----\n* for `RollingFile` appender, the output will go to `pax-logging-it-karaf/karaf-it/target/logs/pax-exam-test.log` (as configured in `src/test/resources/log4j2-test.properties`)\n* for `Console` appender, the output will go to:\n** stdout, if maven-failsafe-plugin is configured with `\u003credirectTestOutputToFile\u003efalse\u003c/redirectTestOutputToFile\u003e`\n** `pax-logging-it-karaf/karaf-it/target/failsafe-reports/org.ops4j.pax.logging.it.karaf.CleanIntegrationTest-output.txt` if maven-failsafe-plugin is configured with `\u003credirectTestOutputToFile\u003etrue\u003c/redirectTestOutputToFile\u003e`\n* When Karaf starts, before `pax-logging-api` is **resolved** (it doesn't have to be started/active to provide the exported classes!) each _early_ bundle (like fileinstall or configadmin) has to dynamically deal with logging. Such bundles usually don't use e.g., SLF4J API. For example, configadmin uses `org.apache.felix.cm.impl.Log` and fileinstall uses `org.apache.felix.fileinstall.internal.Util.Logger` (and subclasses). If a bundle uses e.g., SLF4J API, pax-logging-api **has to** be resolved.\n* When a bundle (I created special `org.ops4j.pax.logging.karaf:karaf-base-logger`) uses e.g., SLF4J API (imports `org.slf4j` package), but pax-logging-api bundle is not yet started, console based `org.ops4j.pax.logging.spi.support.DefaultServiceLog` is used internally. Even if `org.ops4j.pax.logging.spi.support.FileServiceLog` could be used as indicated by `etc/config.properties`, it's not used when pax-logging-api is stopped (because I implemented special synchronization of file-backend for such fallback logger).\n** then such bundle (e.g., in `org.ops4j.pax.logging.karaf.base.Activator.start()`) simply writes to stdout using `DefaultServiceLog`. This is printed to stdout (if maven-failsafe-plugin is told so) (with layout hardcoded in `DefaultServiceLog`):\n[listing,options=nowrap]\n----\norg.ops4j.pax.logging.karaf.base-logger [org.ops4j.pax.logging.karaf.base.Activator] INFO : Starting before pax-logging-api\n----\n* Then pax-logging-api starts and in its activator again calls logging methods through various logging APIs (managed by itself). Now, because this bundle is already starting, `FileServiceLog` may be used (as indicated by `etc/config.properties` - configured using `editConfigurationFilePut(\"etc/custom.properties\", \"org.ops4j.pax.logging.useFileLogFallback\", fileName)` in Pax Exam configuration). This is printed to `pax-logging-it-karaf/karaf-it/target/logs-default/CleanIntegrationTest.log`:\n[listing,options=nowrap]\n----\norg.ops4j.pax.logging.pax-logging-api [org.ops4j.pax.logging.internal.Activator] INFO : Enabling Java Util Logging API support.\norg.ops4j.pax.logging.pax-logging-api [org.ops4j.pax.logging.internal.Activator] INFO : Enabling SLF4J API support.\n...\norg.ops4j.pax.logging.pax-logging-api [org.ops4j.pax.logging.internal.Activator] INFO : Disabling Log4J v2 API support.\norg.ops4j.pax.logging.pax-logging-api [org.ops4j.pax.logging.internal.Activator] INFO : Disabling Java Util Logging API support.\n----\n* Then pax-logging-log4j2 starts, finds there's no `org.ops4j.pax.logging` PID so defaults are used (in this particular case from `org.apache.logging.log4j.core.config.AbstractConfiguration.setToDefault()`). The pattern is `org.apache.logging.log4j.core.config.DefaultConfiguration.DEFAULT_PATTERN` and no file appender is configured, so this is printed to stdout (if maven-failsafe-plugin is told so):\n[listing,options=nowrap]\n----\n13:23:05.344 [FelixStartLevel] DEBUG org.apache.felix.configadmin - Registering service [org.osgi.service.log.LogService, xxx, org.ops4j.pax.logging.PaxLoggingService, org.osgi.service.cm.ManagedService, id=15, bundle=7/mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.11.0-SNAPSHOT]\n13:23:05.353 [FelixStartLevel] DEBUG org.apache.felix.configadmin - Scheduling task ManagedService Update: pid=[org.ops4j.pax.logging]\n13:23:05.358 [FelixStartLevel] DEBUG org.apache.felix.configadmin - [ManagedService Update: pid=[org.ops4j.pax.logging]] scheduled\n13:23:05.544 [CM Configuration Updater (Update: pid=org.apache.karaf.features)] DEBUG org.apache.felix.configadmin - Running task Update: pid=org.apache.karaf.features\n...\n13:23:06.664 [BundleWatcher: 1] DEBUG org.ops4j.pax.exam.raw.extender.intern.Probe - Registering Service: org.ops4j.pax.exam.ProbeInvoker with Probe-Signature=\"PaxExam-3be14d5b-583b-4688-ae78-9f8c1c2ef280\" and expression=\"org.ops4j.pax.logging.it.karaf.CleanIntegrationTest;justRun\"\n13:23:06.786 [RMI TCP Connection(1)-127.0.0.1] INFO  org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner - running justRun in reactor\n13:23:06.789 [RMI TCP Connection(1)-127.0.0.1] INFO  org.ops4j.pax.logging.it.karaf.AbstractControlledIntegrationTestBase - ========== Running org.ops4j.pax.logging.it.karaf.CleanIntegrationTest.justRun() ==========\n13:23:06.790 [RMI TCP Connection(1)-127.0.0.1] INFO  org.ops4j.pax.logging.it.karaf.CleanIntegrationTest - #0: org.apache.felix.framework (System Bundle)\n13:23:06.790 [RMI TCP Connection(1)-127.0.0.1] INFO  org.ops4j.pax.logging.it.karaf.CleanIntegrationTest - #1: org.ops4j.pax.logging.karaf.base-logger (mvn:org.ops4j.pax.logging.karaf/karaf-base-logger/1.11.0-SNAPSHOT)\n...\n13:23:06.815 [FelixStartLevel] DEBUG org.ops4j.pax.swissbox.extender.BundleWatcher - Releasing bundle [org.apache.geronimo.specs.geronimo-atinject_1.0_spec]\n13:23:06.825 [FelixStartLevel] DEBUG org.apache.felix.configadmin - Unregistering service [org.osgi.service.cm.ManagedService, id=28, bundle=8/mvn:org.apache.karaf.features/org.apache.karaf.features.core/4.2.6]\norg.ops4j.pax.logging.pax-logging-api [org.ops4j.pax.logging.karaf.base.Activator] INFO : Stopping after pax-logging-api\n----\n* The above listing contains entries from logging invocations made inside `@Test` methods using SLF4J API.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fops4j%2Forg.ops4j.pax.logging","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fops4j%2Forg.ops4j.pax.logging","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fops4j%2Forg.ops4j.pax.logging/lists"}