On Wed, Dec 12, 2012 at 8:38 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote:
> Another criteria that people should pay attention to is whether the > implementation supports Mapped Diagnostic Contexts > http://logback.qos.ch/manual/mdc.html > > AFAIU this may rule out JUL as a serious implementation... In other words > when we want to start using MDCs to make it easier to navigate the logs, if > the implementation we choose does not support MDCs then we would need to > choose again. > > According to the slf4j website logback and log4j support MDCs (I am > presuming that log4j2 does also therefore) > Yes, please see https://logging.apache.org/log4j/2.x/manual/thread-context.html Gary > > On Tuesday, 11 December 2012, Stephen Connolly wrote: > > > Given that some people are already confused as to what the exact question > > is > > I think we should clarify exactly what is the decision that is being > asked. > > > > There has already been a decision to use the slf4j API for logging within > > core. > > > > * The vast majority of plugins will still use the Maven Log interface > for > > their logging. > > > > * A small limited number of plugins with specific needs will use the > > slf4j API that > > is exposed by core directly, but those plugins will have to do some > > work in > > order to ensure that they work with Maven pre 3.1.0 as well as Maven > > post 3.1.0 > > > > My understanding is that they will have to add a slf4j implementation > > to their > > dependencies... on Maven 3.1.0+ the implementation will be ignored as > > the > > slf4j-api that they see on their classpath will already have been > > initialized with > > core's implementation. On Maven pre-3.1.0 their slf4j-api will be > > initialized and > > find their slf4j implementation. > > > > * A smaller subset of plugins need to control the slf4j implementation > > and > > cannot have a different implementation. Those plugins will have to add > > a > > metadata flag requesting a classloader that is isolated from core's > > slf4j API. > > Such plugins might be redirecting log output for processing, or some > > other > > need that we have not foreseen. > > > > On Maven 3.1.0 if the metadata flag is not present the plugin will > > likely be > > borked and a newer version with the metadata flag will need to be > > released > > [Though the precise behaviour in the absence of this flag is yet to be > > defined] > > When the flag is enabled, the Maven Log interface will be the way the > > plugin > > is required to route the information it wants logged to the user > > through to > > the user. > > > > On Maven pre-3.1.0 things will be as they always were, i.e. the Maven > > Log > > interface is the way we prefer information to be logged through to the > > user. > > > > What is being discussed now is which *implementation* to use for the > Maven > > CLI > > commands by default in core starting with Maven 3.1.0. > > > > There are a number of possible implementations: > > > > * SLF4J Simple was initially considered. This is a very limited logger > > but would > > be able to produce logging output formatted the same as Maven > currently > > provides. *However* there is a regression caused for some of the > > integration > > tests when using SLF4J and fixing those issues currently produces > > performance > > regressions as well as the current uncertainty as to whether those > > fixes will > > be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J > Simple > > is currently being rejected on technical grounds (but if sufficient > > developers > > really want to go with the "we don't want to choose a specific > > implementation" > > choice, this is the implementation you would be selecting. > > > > * Logback is being proposed by Jason. AFAIK this implementation passes > on > > the > > technical criteria. In other words no failing integration tests and no > > significant > > performance regressions. > > > > * Log4j2 has been championed by Olivier. AFAIK this implementation > passes > > on > > the integration tests. I am not sure of the performance technical > test. > > One should > > note that Log4j2 is a new implementation and is not Log4j > > > > I hope that Olivier or somebody else can confirm the integration test > > status of Log4j2 > > as a back end implementation and provide information on the > performance > > status > > of Log4j2. > > > > To my knowledge no other SLF4J implementations have been proposed, but if > > there are others that people want considered please provide an update > here. > > > > The primary concern that Maven committers should apply is the technical > > merit of > > any proposed implementation. > > > > An implementation should be able to pass all the integration tests and > not > > produce > > a significant performance regression. > > > > Developers should not concern themselves with the licensing terms of the > > implementation provided that the implementation is available under one of > > the > > ASL compatible licenses (i.e. Category A or Category B). If a Category B > > licensed > > implementation is chosen then for legal reasons the PMC must approve the > > use > > of that dependency. (Personally speaking, if that decision is purely > based > > on > > technical grounds, I do not see why the PMC would object) > > > > Maven Committers can use other criteria in making th > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
