I'll let folks focus on their evaluations and I'll work on the sample plugins and classloader isolation.
On Dec 12, 2012, at 9:23 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On Wednesday, 12 December 2012, Daniel Kulp wrote: > >> >> On Dec 12, 2012, at 8:45 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com <javascript:;>> 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. > > > I cannot recall if JUL guarantees that the formatter will be called from > the same thread as the log record was generated on. > > If it maintains that as an invariant then we could rescue JUL as a possible > implementation > > If not then I fear it us dead in the water > > -Stephen > >> >> 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 >>> -- >> Daniel Kulp >> dk...@apache.org <javascript:;> - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> >> For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
