On Dec 12, 2012, at 8:45 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. Well, if have to write our jul formatter to handle the WARN -> WARNING thing, we could handle this as well. slf4j-jdk14 sticks a BasicMDCAdapater on there that just stores the context in a ThreadLocal. Nothing uses it, but the data would be there. Our formatter could grab the MDC and use it if we wanted it to. Not saying that we SHOULD do this, just that we could, particularly if we did write a formatter. Dan > > According to the slf4j website logback and log4j support MDCs (I am > presuming that log4j2 does also therefore) > > 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 >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
