I haven't looked at the code (don't know how much duplicate code we're talking about), but in general I would prefer putting shared logic in core, to keep the published api as small as possible. All the bridge modules need core to do useful work anyway...
Sent from my iPhone > On 2014/09/02, at 5:50, Matt Sicker <[email protected]> wrote: > > Yes exactly. It would be either do that, or make log4j-slf4j-impl and > log4j-jcl depend on log4j-core. I'm not actually sure why they don't already > depend on core other than the fact that they can get away without using it. > > >> On 1 September 2014 15:40, Gary Gregory <[email protected]> wrote: >> So are you suggesting we put the new code in the API SPI package and not in >> core to avoid dragging in the core jar? >> >> Gary >> >> >> -------- Original message -------- >> From: Matt Sicker >> Date:09/01/2014 14:16 (GMT-05:00) >> To: Log4J Developers List >> Subject: Small addition to API suggestion. >> >> I'm working on the JDK/JUL bridge again, and I noticed that there's a bit of >> code duplication occurring in log4j-slf4j-impl as well as log4j-jcl. This >> duplication is further duplicated in log4j-jdk which I'm working on right >> now. >> >> The duplication is making a weak hash map of LoggerContext to >> ConcurrentMap<String, L> where L is some external logger class. What I'm >> proposing is a simple SPI class I've temporarily called >> ExternalLoggerContextRegistry<L>. The purpose of this interface is to >> provide a standardized way to keep track of external loggers that are >> bridged with Log4j loggers. >> >> I'll push this work into a branch called LOG4J2-608 which is the JDK logging >> bridge ticket. Class names are obviously not final. I wanted to put this in >> core instead of api, but the bridges all use just the API. >> >> -- >> Matt Sicker <[email protected]> > > > > -- > Matt Sicker <[email protected]>
