So, it sounds to me like this VOTE is withdrawn, since the RM thinks that there's a respin needed. It would be nice to see a formal email communicating this.
On Fri, Dec 7, 2012 at 12:41 PM, ceki <c...@qos.ch> wrote: > On 07.12.2012 02:34, Jason van Zyl wrote: > > >> One benefit is that it would hopefully fix the Sonar problem. But I'm >> not sure what the exact behaviour of SLF4J is. Even if a plugin >> blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar >> case, I think SLF4J is already loaded. Ceki might want to comment on >> how that works. If two SLF4J "systems" can run in the same JVM it may >> work. For the non-SLF4J case it's not using SLF4J, obviously, so there >> is no need to block it. > > SLF4J uses an extremely simple/primitive binding (aka plugin) > mechanism. When the LoggerFactory class is loaded into memory by a > given class loader, the first call to the getILoggerFactory() will > perform initialization. The getILoggerFactory() method is called by > the getLogger(String) method. > > Thus, if LoggerFactory class is loaded into memory N times but various > class loaders, then LoggerFactory class will be initialized N times, > under the very likely assumption that the getLogger() method is called > at least once for each LoggerFactory instance. > > HTH, > > -- > Ceki > 65% of statistics are made up on the spot > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
