So you have a “duplicate” map. So what? Each of these Maps holds different logger objects so you have to have a “duplicate” object. Duplicating 1 line of code is not a big deal.
Ralph On Sep 1, 2014, at 8:03 PM, Matt Sicker <[email protected]> wrote: > Scratch that. I'm going to approach this a different way. The implementation > in log4j-1.2-api is a bit different. > > > On 1 September 2014 21:42, Matt Sicker <[email protected]> wrote: > Oh man, should I make log4j-jdk depend only on log4j-api then? That limits > functionality. No support for setLevel(), getParent(), plus it limits the > ability to add support for Handler classes in the future (I already added > support for JUL's Filter interface). > > The duplicate code is also in log4j-1.2-api. Here's a snippet: > > private static final Map<LoggerContext, ConcurrentMap<String, Logger>> > CONTEXT_MAP = > new WeakHashMap<LoggerContext, ConcurrentMap<String, Logger>>(); > > I'll refactor this one, too, so you can see it all together in the LOG4J2-608 > branch. > > > On 1 September 2014 21:26, Ralph Goers <[email protected]> wrote: > I disagree. We already get comaints that the log4j 1.2 bridge requires core. > Keeping it separate allows for other implementations. Frankly, I'm not sure > the code Matt is talking about is a big enough deal to bother refactoring it. > > Sent from my iPhone > > On Sep 1, 2014, at 7:08 PM, Remko Popma <[email protected]> wrote: > >> 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]> > > > > -- > Matt Sicker <[email protected]> > > > > -- > Matt Sicker <[email protected]>
