- logback-user - mailman3.qos.ch

ClassCastException: ch.qos.logback.core.BasicStatusManager cannot be cast to ch.qos.logback.core.status.StatusManage
by Eric Schwarzenbach 21 Aug '12

21 Aug '12

I was on the verge of posting a question, but since I've figured it out, will post the answer for the next person who runs into this. When setting up Logback-access under Tomcat (as described here http://logback.qos.ch/access.html) if you make the mistake of putting the logback-access jar in your webapp's lib directory (in addition to putting in tomcat's lib directory as the directions specify), you will get this exception when you try to hit the servlet: java.lang.ClassCastException: ch.qos.logback.core.BasicStatusManager cannot be cast to ch.qos.logback.core.status.StatusManager Cheers, Eric

1 0

Syslog appender
by Math Roy 17 Aug '12

17 Aug '12

I have looked at the documentation several times and not able to do the following. The hostname on my device returns the string "hostname". I see that SyslogConverter returns this string. I want to be able to replace that with the ip+mac address of the machine. Like this: 23:19:23:18:23:45+192.168.1.1 Is there a easy way to do this. Also I looked at changing the suffixPattern to achieve this. How can I change it in java. With xml the pattern is fixed and I cannot put the mac/ip address. Thanks, Roy

1 0

Resetting Loggers Once Programmatically Changed
by James Morgan 17 Aug '12

17 Aug '12

Hi all, I have implemented a servlet which can be included with my applications that allowed me to programmatically change logging properties on the file, for example ,Changing logging levels, adding loggers, showing all loggers either with explicit levels or not. My problem is that I would like to do *two* additional things with the servlet and I have no idea how to achieve them?: *1st* - I would like to reset loggers to the application defaults defined in my logback.xml file. Previously when I had implementation of this using Log4J I simply used the system property *log4j.configuration* to get hold of the file, then called *DOMConfigurator.configure(Loader.getResource(filename)) *which then reloaded the log4j config file. As I now do not set a system property I cannot work out how to get hold of the my logback.xml configuration file to re-load it, even if I got hold of it is there a way of resetting/reloading my configuration? *2nd* - Secondly in a similar context as part of my servlet I can explicitly add new loggers with new levels e.g. If I have the class * com.james.morgan.myapplication.Class123* which contains a logger I can override the default level for *com.james.morgan* and add a new logger *com.james.morgan.myapplication.Class123 *with a different level, however once I am finished the only way I can put the logger back to the default level is to set the new logger which I have added to the default level, what I what is the ability to delete a logger but again cannot find any documentation on this? Thanks for any help or suggestions with my problems, James

1 0

%file and %line not set when using SMTPAppender
by Patrick Hogarty 16 Aug '12

16 Aug '12

Hello, When using the SMTPAppender as such: <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender"> <smtpHost>1.1.1.1</smtpHost> <to>blah@blah</to> <from>blah@blah</from> <subject>TESTING: %logger{36} - %m</subject> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d{yyyyMMddHHmm:ss} %level [%thread] %logger{36} [%file:%line] %msg%n</pattern> </layout> </appender> The resulting log prints out like so: 201208161255:43 DEBUG [main] LoggingStuff.Foo [?:?] Did it again! 201208161255:43 INFO [main] LoggingStuff.Foo [?:?] Ha info - do it 201208161255:43 WARN [main] LoggingStuff.Foo [?:?] Something is about to happen! 201208161255:43 ERROR [main] LoggingStuff.Foo [?:?] Serious stuff - is it? java.lang.Exception: Yep at LoggingStuff.Foo.doIt(Foo.java:56) [classes/:na] at LoggingStuff.MyApp1.main(MyApp1.java:39) [classes/:na] Where the %file and %line parameters are not set and show up as a '?'. Using the ConsoleAppender and the FileAppender with the same pattern the parameters all get set correctly, as such: 201208161247:54 DEBUG [main] LoggingStuff.Foo [Foo.java:53] Did it again! 201208161247:54 INFO [main] LoggingStuff.Foo [Foo.java:54] Ha info - do it 201208161247:54 WARN [main] LoggingStuff.Foo [Foo.java:55] Something is about to happen! 201208161247:54 ERROR [main] LoggingStuff.Foo [Foo.java:56] Serious stuff - is it? java.lang.Exception: Yep at LoggingStuff.Foo.doIt(Foo.java:56) [classes/:na] at LoggingStuff.MyApp1.main(MyApp1.java:39) [classes/:na] The one thing I have noticed, when looking at the sample code, is that for both the File and Console appenders, the <pattern> tag is wrapped by an <encoder> tag. Where as with the SMTP appender, the <pattern> tag is wrapped by a <layout> tag. Is there a way of forcing the SMTP appender to set these parameters? Thank you Patrick

2 3

how to deploy logback audit server with netbeans and glassfish environment ?
by jules MBOLLO 16 Aug '12

16 Aug '12

Hi all, I am new on logback API, I now trying to use Logback API for implement audit business logging in an J2EE application. As IDE I use Netbeans 7.1, as server application I use Glassfish 3.1. I refered to the current logback-audit documentation to learn to how to use logback-audit. My problem is that, when I try to follow the basic steps of logback's documentation, The deployement of logback-audit-server in my environment (Netbeans 7.1 + glassfish 3.1) don't success. Please If somebody have the process of deploying logback-audit-server in a similar environment as mine. Please let's me have it too. Please help me, I really confidence on the power of logback -audit for help me to implement audit business in my application. Thank. ________________________________ Jules MBOLLO IT Engeneer

1 0

Configuring jul-to-slf4j bridge
by Andrzej Zadorozny 15 Aug '12

15 Aug '12

Hi there. Quick question: is there a way to remove all existing JUL handlers and install the SLF4JBridgeHandler, all via a configuration file such as logback.xml, etc.? Currently I do the following programmatically, but I would like to be able to do this via a configuration file instead: // Remove any existing handlers from JUL's root logger. java.util.logging.Logger julLogger = java.util.logging.Logger.getLogger(JUL_ROOT_LOGGER_NAME); Handler[] julHandlerArray = julLogger.getHandlers(); for ( Handler julHandler : julHandlerArray ) { julLogger.removeHandler(julHandler); } // Install the JUL to SLF4J bridge handler. SLF4JBridgeHandler.install(); Any input would be greatly appreciated. Thank you very much. -- Andrzej Zadorozny

2 1

Logging crossing contexts
by Robert Voliva 14 Aug '12

14 Aug '12

We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files. For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files. Any ideas out there for me to try?

3 5

Making logging failures fatal.
by Thorbjørn Ravn Andersen 14 Aug '12

14 Aug '12

I need to make logback report problems back as exceptions. Our general deployment scenario is one where programs are restarted every day, and are tedious to monitor unless they explicitly make themselves heard. Hence logfiles are important and a failure in the logging framework configuration should cause the program to stop there and then. To my knowledge things like cannot write to log file X/Y/Z or bad configuration are currently just logged using logbacks internal mechanism and the application does not know anything about it. Id prefer not having logback specific code in my application as we strive to be logging framework neutral, but if it is unavoidable to do this I can make an exception. Thanks for any help /Thorbjørn

2 2

Pattern - log thread id instead of thread name
by jaybytez 07 Aug '12

07 Aug '12

In the examples and basic usage we have a pattern like: <pattern>%d [%thread] %level %logger - %m%n</pattern> The thing we don't like is on weblogic, the %thread is outputted as: [[ACTIVE] ExecuteThread: '102' for queue: 'weblogic.kernel.Default (self-tuning)'] Is there a syntax that we can use in the pattern to just log the thread id? Thanks, Jay -- View this message in context: http://old.nabble.com/Pattern---log-thread-id-instead-of-thread-name-tp3426… Sent from the Logback User mailing list archive at Nabble.com.

2 1

can not generate log file in unix box but console show log msg
by Wu, Jun 2 03 Aug '12

03 Aug '12

Hello Guys, I try Logback in IBM AIX unix box. I can not find log file, but ConsoleAppender works fine. I try my test file in Windows, it can generate log file. Can some body help me? >JVM: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20100813 (SR12 FP1 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20100808 (JIT enabled) >Logback.xml for FileAppender configure: <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>myApp.log</file> <encoder> <pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern> </encoder> </appender> >My AIX information: Version: 6.1.0.0 64bit Thanks in advance! Regards, Jun Wu| Senior Developer| Web Services Department | Deposit Products and Business Banking Technology | CIBC (416)-780-5042 | jun2.wu(a)cibc.com<mailto:jun2.wu@cibc.com> This email message and any attachments are CONFIDENTIAL. If you have received this message in error, please notify us immediately by return email and delete this message and any attachments without disclosing or distributing them further. Thank you. Ce courriel, ainsi que toute pièce jointe, est CONFIDENTIEL. Si vous avez reçu ce message par erreur, veuillez nous en aviser surle-champ en nous le renvoyant et le supprimer, ainsi que toute pièce jointe, sans en avoir divulgué ou diffusé le contenu. Merci.

2 4