headers
Jacob Kjome | 20 Feb 2010 02:20
Favicon

Re: Reconfigure during runtime

How about using something a bit more dynamic and fully developed...

http://openutils.sourceforge.net/openutils-log4j/servlet.html

Jake

On 2/17/2010 7:19 AM, Per Lindberg wrote:
> Per Lindberg wrote:
>
>> That's reassuring! Now all I have to do is to figure out why
>> I can't get it to work as it should. :-)
>
> ...and now I finally got it working. I had a trivial bug.
> Thanks again for the reassurement, that helped me look
> in the right place.
>
> In case anyone is interested, here's what you can do:
>
> String loggerClassPath = request.getParameter("logger-class-path");
> String loggerLevel = request.getParameter("logger-level");
> org.apache.log4j.Logger.getLogger(loggerClassPath)
> .setLevel(org.apache.log4j.Level.toLevel(loggerLevel));
>
> Works like a charm, even when logging calls then are to slf4j.
>
> Cheers,
> Per Lindberg
>
> _______________________________________________
> slf4j-user mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
ownedthx | 22 Feb 2010 01:57
Picon

Should NOPLogger implement org.slf4j.spi.LocationAwareLogger? Dealing with appender startup problem


Hi all,

I'm using a logback appender which logs during startup, causing a NOPLogger
to be created while the underlying library initializes.

In this specific scenario, I'm coercing a 3rd-party library out of direct
log4j usage by using the log4j-over-slf4j bridge.  However, the
Category.java implementation in the bridge will throw an exception if the
underlying logger (in this case, NOPLogger) does not implement the
LocationAwareLogger interface.

This seems wrong to me--seems to me the NOPLogger should implement
LocationAwareLogger, and NOP the log statement specific to that, just like
it does with all the other various log overloads it implements, instead of
causing the appender to fail to start.

Any thoughts on this?

By the way, I did stop the error by doing just what was recommended here...

Thanks,
Seth

--

-- 
View this message in context: http://n3.nabble.com/Should-NOPLogger-implement-org-slf4j-spi-LocationAwareLogger-Dealing-with-appender-startup-problem-tp326006p326006.html
Sent from the slf4j - user mailing list archive at Nabble.com.
Permalink | Reply | 3 comments |
headers
Ceki Gulcu | 22 Feb 2010 07:45
Picon
Gravatar

Re: Should NOPLogger implement org.slf4j.spi.LocationAwareLogger? Dealing with appender startup problem

Hello Seth,

Reading the code of the Category class in log4j-over-slf4j, it appears
that both loggers of type org.slf4j.Logger *and* LocationAwareLogger
are supported. Category class in log4j-over-slf4j should throw an
exception if the slf4j logger it gets is of type NOPLogger. Can you
show the exception you are observing?

Cheers,

On 22.02.2010 01:57, ownedthx wrote:
>
> Hi all,
>
> I'm using a logback appender which logs during startup, causing a NOPLogger
> to be created while the underlying library initializes.
>
> In this specific scenario, I'm coercing a 3rd-party library out of direct
> log4j usage by using the log4j-over-slf4j bridge.  However, the
> Category.java implementation in the bridge will throw an exception if the
> underlying logger (in this case, NOPLogger) does not implement the
> LocationAwareLogger interface.
>
> This seems wrong to me--seems to me the NOPLogger should implement
> LocationAwareLogger, and NOP the log statement specific to that, just like
> it does with all the other various log overloads it implements, instead of
> causing the appender to fail to start.
>
> Any thoughts on this?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Seth Call | 22 Feb 2010 16:12
Picon

Re: Should NOPLogger implement org.slf4j.spi.LocationAwareLogger? Dealing with appender startup problem

Hi Ceki,

The method in question is this:

public void log(String FQCN, Priority p, Object msg, Throwable t) {
     int levelInt = priorityToLevelInt(p);
     if (locationAwareLogger != null) {
       locationAwareLogger.log(null, FQCN, levelInt, 
convertToString(msg), t);
     } else {
       throw new UnsupportedOperationException("The logger [" + slf4jLogger
           + "] does not seem to be location aware.");
     }
   }

You are right: I only saw this when the logger was the NOPLogger.  I saw 
the UnsupportedOperationException shown in that method was thrown.

What I'm suggesting is that the NOPLogger should implement 
LocationAwareLogger, since I don't see any value in having the NOPLogger 
stop a log from happening...

Thanks,
Seth

On 2/22/10 12:45 AM, Ceki Gulcu wrote:
> Hello Seth,
>
>
> Reading the code of the Category class in log4j-over-slf4j, it appears
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ceki Gülcü | 22 Feb 2010 16:44
Picon
Gravatar

Re: Should NOPLogger implement org.slf4j.spi.LocationAwareLogger? Dealing with appender startup problem


NOPLogger does not do anything and consequently cannot be location
aware. The code log(String FQCN, Priority p, Object msg, Throwable t)
method throws an exception because the caller expects location aware
logging but the actual logger implementation is not capable of
delivering "location awareness".  One easy solution to this problem is
to modify the said log method as follows:

   public void log(String FQCN, Priority p, Object msg, Throwable t) {
     int levelInt = priorityToLevelInt(p);
     differentiatedLog(null, FQCN, levelInt, msg, t);
   }

I'll happily make the change provided you enter a bug report asking
for this modification.

By the way, your scenario does not makes sense to me. If I understand
correctly, you are using logback-classic as your logging
framework. You have a logback appender doing logging. If that appender
logs during its own initialization or obtains a logger, since SLF4J
will not be yet initialized the returned logger will be of type
NOPLogger. But that will not exercise code found in log4j-over-slf4j
unless the logback-class appender you are using depends on some other
library which uses log4j. Is that the case?

On 22/02/2010 4:12 PM, Seth Call wrote:
> Hi Ceki,
>
> The method in question is this:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ceki Gülcü | 25 Feb 2010 12:56
Picon
Gravatar

Release of SLF4J version 1.5.11

Hello all,

I am happy to announce the immediate availability of SLF4J version
1.5.11 consisting of bug fixes and minor enhancements. It is totally
compatible with SLF4J version 1.5.10.

Please refer to the the news page for precise details.

    http://www.slf4j.org/news.html

You can download SLF4J, including full source code, class files and
documentation on our download page, shown below.

     http://www.slf4j.org/download.html

You can receive SLF4J related announcements by subscribing to the
SLF4J announce mailing list. To subscribe to QOS.ch announce list,
please visit the following URL.

   http://www.qos.ch/mailman/listinfo/announce

--

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
Permalink | Reply | 0 comments |
headers
Chiao Cheng | 3 Mar 2010 11:34
Picon
Favicon

SLF4J on the Google Android Platform

Hi All,

I was playing around with android and was glad to see that someone already put together a slf4j-android
module.  I tried using it and I really like to make some changes so I created another fork.

First, I found an old thread explaining why slf4j-android also includes slf4j-api code...

> I can already tell you that I needed to merge the SLf4J-API project and 
> the new binding implementation into one (Maven) project. The reason is 
> rather complicated to explain. In short, it is due to the fact that 
> SLF4J API removes the dummy impl.* classes during the build from the 
> target Jar, which is not compatible with the Android DexerI'm not sure why this would be the case because
the dexer is completely ok with dex'ing multiple jars and dependencies.  I suggest we separate out
slf4j-api code from the slf4j-android module.  Once we do this, then it would be easier to keep the two in
sync.  With the current setup, it seems like it would be very easy for slf4j-android to fall out of sync with
the main api version.  And from the web page, it seems like it has already fallen behind.  I made the
appropriate changes (basically stripping out all slf4j-api code from slf4j-android directory) in my
fork and it seems to work just fine.  I've tested using android platform 1.6+.

Next, I found a problem in the recent access modifier changes in slf4j.  Specifically the references from
LoggerFactory to private StaticLoggerBinder.SINGLETON.  Even though the java runtime seems to be ok due
to shortcircuit logic I'm guessing, the android runtime is not:

"access denied from Lorg/slf4j/LoggerFactory; to field Lorg/slf4j/impl/StaticLoggerBinder;.SINGLETON"

For now, I had to change StaticLoggerBinder.SINGLETON back to public to avoid these errors.  But, from
looking at the code, I do not see any reasons for LoggerFactory to reference
StaticLoggerBinder.SINGLETON, other than allowing some modules to work without a getSingleton()
method.  But I would love to remove SINGLETON references in the LoggerFactory.  Also seems a bit hacky to
have code that tries to access private members.  Are there plans to get rid of the SINGLETON references completely?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thorsten.Moeller | 3 Mar 2010 14:00
Picon
Picon
Favicon

Re: SLF4J on the Google Android Platform

Chiao,

thanks for your comments and suggestions (I'm the one who created  
slf4j-android).

I will come back to this next week since I'm currently out of office.

Cheers,
Thorsten

Quoting Chiao Cheng <zimazenini <at> yahoo.com>:

> Hi All,
>
> I was playing around with android and was glad to see that someone   
> already put together a slf4j-android module.  I tried using it and I  
>  really like to make some changes so I created another fork.
>
> First, I found an old thread explaining why slf4j-android also   
> includes slf4j-api code...
>
>> I can already tell you that I needed to merge the SLf4J-API project and
>> the new binding implementation into one (Maven) project. The reason is
>> rather complicated to explain. In short, it is due to the fact that
>> SLF4J API removes the dummy impl.* classes during the build from the
>> target Jar, which is not compatible with the Android DexerI'm not   
>> sure why this would be the case because the dexer is completely ok   
>> with dex'ing multiple jars and dependencies.  I suggest we separate  
>>  out slf4j-api code from the slf4j-android module.  Once we do  
>> this,  then it would be easier to keep the two in sync.  With the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane