I'm going to refactor the LoggerAdapter class a bit as some of its methods make more sense as protected abstract methods instead. I may end up renaming it again if a more apparent design pattern emerges.
On 2 September 2014 00:12, Matt Sicker <[email protected]> wrote: > Seeing how common of a pattern it is, I think a class like this would be > beneficial to writing logging API bridges. > > > On 2 September 2014 00:05, Ralph Goers <[email protected]> wrote: > >> Oops. Nevermind. I was remembering the code incorrectly. You didn’t make >> it more complicated. I did. >> >> Ralph >> >> On Sep 1, 2014, at 10:00 PM, Ralph Goers <[email protected]> >> wrote: >> >> Actually, it was that simple but you made it more complicated by creating >> a Map of Maps. Why is that needed? >> >> I am not convinced this is a good idea. >> >> Ralph >> >> On Sep 1, 2014, at 8:49 PM, Matt Sicker <[email protected]> wrote: >> >> I'm updating log4j-jdk to use log4j-core if available. A similar pattern >> might be useful for the 1.2 bridge. Plus, the duplicate code isn't just the >> map; it's everything in AbstractExternalLoggerContextRegistry. Here, take a >> look: >> >> >> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob_plain;f=log4j-api/src/main/java/org/apache/logging/log4j/spi/AbstractExternalLoggerContextRegistry.java;h=9e7a8fcdf43eae0a3ac0eb2163ab1da39bbce987;hb=LOG4J2-608 >> >> >> On 1 September 2014 22:24, Ralph Goers <[email protected]> >> wrote: >> >>> Yes, I would recommend trying to make log4j-jdk dependent only on the >>> log4j 2 api. However, if there is some functionality that is crucial to >>> how jul works then go ahead and make it be dependent on core. I believe >>> getParents() is the reason the log4j 1.2 bridge is dependent on core. >>> >>> Ralph >>> >>> On Sep 1, 2014, at 7:42 PM, 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]> >> >> >> >> > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
