I'm OK with this as well.  Because it is not part of the Logger interface JBoss 
would have to expect an AbstractLogger instance but they would not have to 
create their own Loggers.


On Jun 7, 2013, at 1:05 PM, Scott Deboy wrote:

> +1 seems reasonable to me...
> 
> On 6/7/13, Nick Williams <[email protected]> wrote:
>> The JBoss Logging devs have accepted my pull request to fix JBLOGGING-94
>> [1], so JBoss Logging works with Log4j 2 now as of JBoss Logging 3.1.4 and
>> 3.2.0.
>> 
>> However, JBoss Logging still only works with Log4j 2 _IF_ the log4j-1.2-api
>> artifact is on the class path, and so it doesn't perform as well as it
>> could. Thus, I've started working on a pull request that will add
>> first-class support for Log4j 2, significantly improving performance.
>> 
>> However, take a look at lines 850-851 of Category.java from Log4j 1.2 [2]
>> and line 1460 of AbstractLogger.java from Log4j 2 [3]. In Log4j 1.2 this
>> method was public, but its equivalent in Log4j 2 is protected. This means
>> that JBoss Logging will have to subclass AbstractLoggerWrapper and wrap the
>> original logger in order to call this method, with will not perform quite as
>> well as calling the method on the original logger directly. Note that I had
>> to do this exact thing for the log4j-taglib artifact: subclass
>> AbstractLoggerWrapper just so that I could call this method.
>> 
>> It seems, to me, that maybe this method should be public, like it was in
>> 1.2, instead of protected. That would simplify both the tag library and what
>> I'm trying to do in JBoss Logging. It might simplify other bridge/adapter
>> code, too. What do the rest of the devs think of this?
>> 
>> Nick
>> 
>> [1] https://issues.jboss.org/browse/JBLOGGING-94
>> [2]
>> http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/Category.java?view=markup#l850
>> [3]
>> http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java?view=markup#l1460
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to