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]>
