| slf4j logging for runtime debugging [message #1023636] |
Sun, 24 March 2013 20:15 |
 Steve Kallestad
Messages: 62
Registered: March 2013 |
Member |
|
|
I prefer slf4j over log4j for a variety of reasons, but I understand when I have to take a few extra steps to use my preferred logger.
A few weeks ago, I got a little stumped by the XText documentation:
Xtext uses Apache's log4j for logging. It is configured using the so called
log4j.properties
, which is
looked up in the root of the Java classpath. If you want to change or provide configuration at runtime
(i.e. non-OSGI), all you have to do is putting such a
log4j.properties
in place and make sure that it is not
overridden by other
log4j.properties
in previous classpath entries.
In OSGi you provide configuration by creating a fragment for
org.apache.log4j
. In this case you need to
make sure that there's no second fragment contributing a
log4j.properties
file.
I read this several times and frankly, I felt like a third grader trying to decipher an encyclopedia entry.
I started looking into what it takes to build OSGI fragments, then got distracted by some postings about xtext's built in logger, and almost caved and started using log4j just to get things moving forward.
But one thing stuck in my mind and I couldn't get past it... logging should be easy. I shouldn't be forced into a particular logger implementation and I *really* shouldn't be throwing System.out.println statements in my code.
So I finally pulled myself away from deciphering documentation and figured out that doing logging with slf4j is pretty easy.
In plugin.xml, on the dependencies tab, I added two imported packages - ch.qos.logback.classic and org.slf4j. They're already on the list (I believe) because antlr brought them in.
From there, working with slf4j is the same as it always was.
For any classes I declare, it's a matter of inserting:
private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
and adding any statements:
logger.debug("My debug message: {}", someString);
Now, where to put logback.xml...
logback-classic looks for logback.xml on the classpath and I had a pretty hard time figuring out how to include my own logback.xml that was editable.
Under launch configurations, under "Launch Runtime Eclipse" in the VM arguments textbox, I added:
-Dlogback.configurationFile=d:\path\to\logback.xml
now I can edit the logback.xml file to show/hide various loglevels for various classes while troubleshooting.
So anyhow, I figured I'd share this little tidbit in case anyone else out there got stumped by the logging documentation.
[Updated on: Sun, 24 March 2013 20:17] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02335 seconds
] 
Search
Help
Register
Login
Home
