mace-opensaml-users - Re: Change of logging framework

Subject: OpenSAML user discussion

List archive

Re: Change of logging framework

From: Chad La Joie <>
To:
Subject: Re: Change of logging framework
Date: Fri, 09 Nov 2007 15:04:54 +0100
Organization: SWITCH

Lots and lots and lots of stuff. :) I just happen to have been dealing with this environment for a *long* time. All my professional life in fact.

Håkon Tuvin Sagehaug wrote:

So let me ask you, is there a thing you don't know?

Chad La Joie skrev:

In Eclipse each project depends on the below project (at least this is how the OpenSAML stack is set up). If you remove libraries and then re-add them you also have to tell Eclipse to export those libraries. This allows the projects which depend on them to have access to the libraries.

Which libraries are exported is just in the tab to the right of where you add/remove libs. The tab is called "Order and Export".

Håkon Tuvin Sagehaug wrote:

OK I could not help my self. If in my eclipse project have the three jar files things work fine, as you would expect, but if I remove them and add them again things is not working anymore. But if I run the class from console it works. Strange, thats why I've been having these problems I think. I've added and removed the jar files so nothing works

Håkon Tuvin Sagehaug skrev:

'Hi

As always you get I right, so I just have to debug my thing. I will try to leave you alone for the rest of the day

Håkon
Chad La Joie skrev:

I just tried it in a very simple test case. I have the attached class and the follow jars on my classpath:

- log4j-1.2.15.jar
- slf4j-api-1.4.3.jar
- slf4j-log4j12-1.4.3.jar

Then I have the attached log4j config file on my classpath.

Håkon Tuvin Sagehaug wrote:

Chad La Joie skrev:

Right. You have to provide it *some* logging system. Which you choose is up to you. The reason for moving to SLF4J was because I *can't* choose the right one because the "right" one depends on your environment.

I know you've been using Log4J, why don't you stick with that?

No problem in sticking to log4j and I understand why you are doing it, so I just want to now what I should have in my classpath(now I slf4j-api.jar and slf4j-log4j.jar.
Per the

SLF4J manual all you need to do is add the SLF4J/Log4J binding to your classpath.
Yes, but this does not work. I've tried in a little app, and it's the same error messages

I noticed that I forgot to check in the various binding libraries in the third-party directory in xml-tooling, which I meant to do so that people didn't have to go to the sight and get them. I've done that, now.

Håkon Tuvin Sagehaug wrote:

With the same jars and no jars I get

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder
at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:221)
at org.apache.xml.security.Init.<clinit>(Unknown Source)

The only thing that worked for me is the slf4j-simple.jar. But that only logs at the INFO level.

Chad La Joie skrev:

No, it should be okay. I've done full, clean, builds of it this morning just to make sure I didn't miss anything and they were fine. My test 2.0 IdP is using the new code as well.

What error are you getting?

Håkon Tuvin Sagehaug wrote:

Hi

I got the new code from svn, but when I tried to use it with my own I got errors. Do I need to have any jar in my own classpath to use the logging features form openSAML?

I tried with the same as in the open-xamltooling but got errors then to.

Chad La Joie skrev:

SLF4J isn't a logging framework, it's just a interface to one. You can use Log4J, Java Util Logging, and other logging frameworks with it. Which framework you use is going to have it's own configuration language.

The first place to start is probably here:
http://slf4j.org/manual.html

Then, pick which logging framework you want to use. If you want to use log4j you can.

Håkon Tuvin Sagehaug wrote:

Do you have any experience in writing properties file for slf4j?
I translated my log4j.properties file in the translator at their page, but it will only log at INFO level, even if I set DEBUG as desired level, any tips??

Håkon

Chad La Joie skrev:

Change has been made. I also rev'ed a few libraries to pick up bug fixes, performance enhancements, etc.

Chad La Joie wrote:

Okay, I'll probably do this tomorrow morning (my time, GMT+1) if I don't have any objects by the time I get in tomorrow. Feedback so far seems to indicate this is a generally good move.

Chad La Joie wrote:

About a week ago I moved the Shibboleth IdP code base to use SLF4J as its logging interface. I did this for one main reason; different environments have really begun to diverge in their logging layer. Some (e.g. some versions of Tomcat) are using old versions Log4J, some are using newer version that break when used with the older version (yay for API changes in patch releases), some are using the java.util.logging (JULI) system. This is making it increasingly difficult to figure out what to target and leading to a number of class/classpath errors. In addition I got some syntax sugar, which was nice, but not the reason I made the change.

After evaluating SLF4J I found that it suited the needs of the IdP. It is similar to Jakarta Commons Logging but without some of the classloading issues. It can bind to Log4J, JULI, and other logging systems. If no one has any objections I'd like to move the OpenSAML stack (XMLTooling, OpenWS, and OpenSAML 2) to SLF4J.

For more information on SLF4J you can check out its website:
http://www.slf4j.org/

For some discussion on the problems with Jakarta Logging Commons you can check out this blog entry and related links.
http://bsnyderblog.blogspot.com/2007/08/my-soapbox-for-slf4j.html

I will *not* be recommending a particular binding for SLF4J (i.e. Log4J, JULI, LogBack, whatever), people should use what is best/supported in their environment. I can say for the IdP I happen to use LogBack because it has a few features that I prefer that Log4J doesn't have. I personally refuse to use JULI mostly for the reasons cited in the above blog post.

So, if you have comments, please let me know by the end of the week.

Thanks.

------------------------------------------------------------------------

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class slf4jLog4JTest {

/**
* @param args
*/
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger(slf4jLog4JTest.class);
logger.info("Got here");
}

}

------------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">









<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"; debug="false">

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out" />

<layout class="org.apache.log4j.PatternLayout">




<param name="ConversionPattern" value="%d %-5p [%C{1}#%M:%L] %m%n" />
</layout>
</appender>





<root>
<priority value="DEBUG"/>
<appender-ref ref="CONSOLE" />
</root>

</log4j:configuration>

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
http://www.switch.ch

Re: Change of logging framework, (continued)

List archive

Re: Change of logging framework