logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Small addition to API suggestion.
Date Tue, 02 Sep 2014 03:21:10 GMT
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 <boards@gmail.com> 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 <boards@gmail.com> 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 <ralph.goers@dslextreme.com> 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 <remko.popma@gmail.com> 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 <boards@gmail.com> 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 <garydgregory@gmail.com> 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 <boards@gmail.com>
>>> 
>>> 
>>> 
>>> -- 
>>> Matt Sicker <boards@gmail.com>
> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>
> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>


Mime
View raw message