Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Hi, I know SLF4J is a great logging framework for us, but I encounter with many questions with configuring SLF4J to work with one's favorite logging frameworks very often, via ML, IRC or personal e-mail. IIRC, we already talked about providing a way to choose the logging framework, but I thought it might worth to raise this issue again because our community grew up since then. It might be a good idea to make MINA independent from any logging framework by default and let users choose it, like some libraries do: IoLogger.setInstance(new Log4JLogger()); Basically it will remove the red tape for any users who are not familiar with SLF4J logging framework, because most people are very used to what commons-logging does or just to log4j or java.util.logging. WDYT? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Hi Trustin, I don't like this idea. It basically means that we are going to build are own logging-lib facade, a job that SLF4J does very well. And IMHO it won't simplify things, we'll have to explain people how our mechanism for choosing a logging-librarry works. Maybe a well-written FAQ entry about MINA and SLF4J would help out a lot ? I agree that SLF4J is a great logging facade. It takes 10 minutes to read the documentation, and I think anyone serious about server-side java should take the time to check it out. I am also convinced that SLF4J is going to get more momentum in the future. See the list of projects at the bottom of http://www.slf4j.org/index.html just my 2 cents. Maarten On 9/27/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi, I know SLF4J is a great logging framework for us, but I encounter with many questions with configuring SLF4J to work with one's favorite logging frameworks very often, via ML, IRC or personal e-mail. IIRC, we already talked about providing a way to choose the logging framework, but I thought it might worth to raise this issue again because our community grew up since then. It might be a good idea to make MINA independent from any logging framework by default and let users choose it, like some libraries do: IoLogger.setInstance(new Log4JLogger()); Basically it will remove the red tape for any users who are not familiar with SLF4J logging framework, because most people are very used to what commons-logging does or just to log4j or java.util.logging. WDYT? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Well... since the documentation for SLF4J is very clear and easy to understand, I don't really see a reason to abandon it. Personally I think the (original) choice for this logging facade was perfect (especially since you can change the actual logger on the spot, without any code changes). Jeroen Brattinga Trustin Lee wrote: Hi, I know SLF4J is a great logging framework for us, but I encounter with many questions with configuring SLF4J to work with one's favorite logging frameworks very often, via ML, IRC or personal e-mail. IIRC, we already talked about providing a way to choose the logging framework, but I thought it might worth to raise this issue again because our community grew up since then. It might be a good idea to make MINA independent from any logging framework by default and let users choose it, like some libraries do: IoLogger.setInstance(new Log4JLogger()); Basically it will remove the red tape for any users who are not familiar with SLF4J logging framework, because most people are very used to what commons-logging does or just to log4j or java.util.logging. WDYT? Trustin
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
On 9/27/07, Maarten Bosteels [EMAIL PROTECTED] wrote: Hi Trustin, I don't like this idea. It basically means that we are going to build are own logging-lib facade, a job that SLF4J does very well. And IMHO it won't simplify things, we'll have to explain people how our mechanism for choosing a logging-librarry works. Maybe a well-written FAQ entry about MINA and SLF4J would help out a lot ? Agreed, but there are some issues. I agree that SLF4J is a great logging facade. It takes 10 minutes to read the documentation, and I think anyone serious about server-side java should take the time to check it out. I am also convinced that SLF4J is going to get more momentum in the future. See the list of projects at the bottom of http://www.slf4j.org/index.html One disadvantage of SLF4J though is that it becomes unpredictable if people puts wrong jars or additional jars in the classpath. It might be a good idea if there's any way to diagnose such a problem. If we can do that, we could print some direct instruction to the users. Yes, it's what SLF4J has to offer, but I thought we can do that too. Another disadvantage of SLF4J is that it doesn't play well with java.util.logging. Related discussion is found here: http://www.nabble.com/java.util.logging.LogManager-Implementation--t3754880.html For example, we can't incorporate very well with Tomcat in logging because Tomcat is using java.util.logging. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Hi Trustin, How about inquiring with Ceki to see if these concerns can be addressed then see what other options exist? The idea of yet another logging implementation is a bit nausiating: there are so many already in existance. Adding yet another one to the mix especially to be maintained by the mina community is just going to increase the confusion around logging. People are just tired, annoyed and confused with having to deal with all the logging choices. On the otherhand you may have some very good reasons for it - if so why not just join the slf4j community to fix these issues. I dont think Ceki considering your history and reputation would object to granting you commit access. Alex On 9/27/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/27/07, Maarten Bosteels [EMAIL PROTECTED] wrote: Hi Trustin, I don't like this idea. It basically means that we are going to build are own logging-lib facade, a job that SLF4J does very well. And IMHO it won't simplify things, we'll have to explain people how our mechanism for choosing a logging-librarry works. Maybe a well-written FAQ entry about MINA and SLF4J would help out a lot ? Agreed, but there are some issues. I agree that SLF4J is a great logging facade. It takes 10 minutes to read the documentation, and I think anyone serious about server-side java should take the time to check it out. I am also convinced that SLF4J is going to get more momentum in the future. See the list of projects at the bottom of http://www.slf4j.org/index.html One disadvantage of SLF4J though is that it becomes unpredictable if people puts wrong jars or additional jars in the classpath. It might be a good idea if there's any way to diagnose such a problem. If we can do that, we could print some direct instruction to the users. Yes, it's what SLF4J has to offer, but I thought we can do that too. Another disadvantage of SLF4J is that it doesn't play well with java.util.logging. Related discussion is found here: http://www.nabble.com/java.util.logging.LogManager-Implementation--t3754880.html For example, we can't incorporate very well with Tomcat in logging because Tomcat is using java.util.logging. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
On 9/27/07, Maarten Bosteels [EMAIL PROTECTED] wrote: On 9/27/07, Maarten Bosteels [EMAIL PROTECTED] wrote: On 9/27/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/27/07, Maarten Bosteels [EMAIL PROTECTED] wrote: Hi Trustin, I don't like this idea. It basically means that we are going to build are own logging-lib facade, a job that SLF4J does very well. And IMHO it won't simplify things, we'll have to explain people how our mechanism for choosing a logging-librarry works. Maybe a well-written FAQ entry about MINA and SLF4J would help out a lot ? Agreed, but there are some issues. I agree that SLF4J is a great logging facade. It takes 10 minutes to read the documentation, and I think anyone serious about server-side java should take the time to check it out. I am also convinced that SLF4J is going to get more momentum in the future. See the list of projects at the bottom of http://www.slf4j.org/index.html One disadvantage of SLF4J though is that it becomes unpredictable if people puts wrong jars or additional jars in the classpath. It might be a good idea if there's any way to diagnose such a problem. If we can do that, we could print some direct instruction to the users. Yes, it's what SLF4J has to offer, but I thought we can do that too. Yes, we could check out if we can do something about that. But if people put two versions of mina (or any other library) on the classpath things become unpredictable as well. Another disadvantage of SLF4J is that it doesn't play well with java.util.logging. Related discussion is found here: http://www.nabble.com/java.util.logging.LogManager-Implementation--t3754880.html For example, we can't incorporate very well with Tomcat in logging because Tomcat is using java.util.logging. AFAIK tomcat switched completely to Jakarta Commons Logging since 5.5. We are using mina and SLF4J and log4j inside tomcat without any issues. I don't think it has ever used java.util.logging ? It uses -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager http://tomcat.apache.org/faq/logging.html correction: The tomcat code uses JCL exclusively but the default Tomcat configuration will use java.util.logging. Oh I see. Wrong example. Your opinion makes perfect sense. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Any logging framework will have pros and cons. SLF4J are solving a lot of pb we had with log4j. It's not perfect, and users who are not completely aware of the existence of a documentation may have pb. This is pretty much a RTFM problem than a SLF4j pb. I would much more favor an augmented FAQ to any other options. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
Emmanuel Lecharny wrote: Any logging framework will have pros and cons. SLF4J are solving a lot of pb we had with log4j. It's not perfect, and users who are not completely aware of the existence of a documentation may have pb. This is pretty much a RTFM problem than a SLF4j pb. I would much more favor an augmented FAQ to any other options. +1 Emmanuel took the words out of my mouth.
Re: Is SLF4J hard to configure? (read: do we need to provide a way to choose the logging framework?)
I added a simple logging tutorial to http://mina.apache.org/documentation.html I hope this will help and at least we will have something to point people towards. On 9/27/07, Mike Heath [EMAIL PROTECTED] wrote: Emmanuel Lecharny wrote: Any logging framework will have pros and cons. SLF4J are solving a lot of pb we had with log4j. It's not perfect, and users who are not completely aware of the existence of a documentation may have pb. This is pretty much a RTFM problem than a SLF4j pb. I would much more favor an augmented FAQ to any other options. +1 Emmanuel took the words out of my mouth. -- ..Cheers Mark
