Re: [logging] logging vs slf4j
+1 as well. That's the path I advocated for Configuration 2.0, combined with the log4j bridge from Paul Smith [1] Maybe we should stop spending our energy on alternative logging frameworks and try to improve the standard one in the JDK instead. I have been told that Java was open source now, so let's contribute ! Emmanuel Bourg [1] http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html Le 07/08/2011 10:31, Jochen Wiedmann a écrit : On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregorygarydgreg...@gmail.com wrote: Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the log4j case before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the Apache Way itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. The logback project is not satisfying me as a developer. I am at the ASF because I like the way it is. I like the software. And of course I like the way the work is done here and finally I like the license. logback/slf4j is going another way. It does not have the license, and holidays seem to be very important to the project. We, the ASF, have really good software in our repositories. We have very competent people around. Why do we discuss to move to slf4j/logback - now? The last time we discussed this there was less activity on logging. Now there is activity on the logging project at apache. There is Ralph and some other people doing lots of work for log4j2. We have learned there are some people who want commons-logging. We have learned in Tomcat are some people who created classloader workarounds and know about the case and could help with it. It feels wrong to me to move away to slf4j/logback with Commons at this point of time. We would kill the new growing dynamics of logging. Instead we should use the new interest and try to work together on the new log4j/commons-logging. Over at logging we welcome new fresh blood. After all, even log4j 1.2.x is not bad software. I use it daily; i have not missed the features of logback (parametrized messages, Markers etc.) so far. I put log4j in my class path, copy over one of my fave configuration, ready. No need to waste any more time to this. log4j is still good and at the moment I don't see a reason to move on. In the commons-logging case, if the commons-* projects stop using commons-logging, then commons-logging feels pretty dead. So my preference is: - Help Ralph to make log4j 2.0 become truth - Update commons-logging, make it work with log4j 2.0 - Try to make log4j 2.0 become compatible with slf4j If one of you is interested in helping with log4j, please subscribe to log4j-...@logging.apache.org Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Tue, Aug 9, 2011 at 5:57 AM, Christian Grobmeier grobme...@gmail.com wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the log4j case before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the Apache Way itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. The logback project is not satisfying me as a developer. I am at the ASF because I like the way it is. I like the software. And of course I like the way the work is done here and finally I like the license. logback/slf4j is going another way. It does not have the license, and holidays seem to be very important to the project. We, the ASF, have really good software in our repositories. We have very competent people around. Why do we discuss to move to slf4j/logback - now? The last time we discussed this there was less activity on logging. Now there is activity on the logging project at apache. There is Ralph and some other people doing lots of work for log4j2. We have learned there are some people who want commons-logging. We have learned in Tomcat are some people who created classloader workarounds and know about the case and could help with it. It feels wrong to me to move away to slf4j/logback with Commons at this point of time. We would kill the new growing dynamics of logging. Instead we should use the new interest and try to work together on the new log4j/commons-logging. Over at logging we welcome new fresh blood. After all, even log4j 1.2.x is not bad software. I use it daily; i have not missed the features of logback (parametrized messages, Markers etc.) so far. I put log4j in my class path, copy over one of my fave configuration, ready. No need to waste any more time to this. log4j is still good and at the moment I don't see a reason to move on. In the commons-logging case, if the commons-* projects stop using commons-logging, then commons-logging feels pretty dead. So my preference is: - Help Ralph to make log4j 2.0 become truth - Update commons-logging, make it work with log4j 2.0 - Try to make log4j 2.0 become compatible with slf4j +1 If one of you is interested in helping with log4j, please subscribe to log4j-...@logging.apache.org Done. Nice message Christian. Gary Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 09.08.2011 11:57, Christian Grobmeier wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the log4j case before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the Apache Way itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. * On the ASF model In a nutshell, while the ASF is a great organization in many ways, it is not a meritocracy mainly because merit is not measured at all and at the project level no responsiblity is accrued on merit beyond committership. BTW, the BDFL model is not a meritocracy either. Finding a good model for running organisations is no simple matter. The Apache model may even be better than some but it bothers me that the ASF misrepresents itself as a meritocracy. * On logging One of the disadvantages of a relatively large and open ecosystem such as Java is that you get several competing libraries solving common problems. Logging is a rather devisive case in point. SLF4J has deficiences with regards to modularity are imho testimony to the lack of a widely accepted solution to modularity in Java. In any case, I am unaware of a satisfactory solution. OSGi is of course one possible approach but OSGi is a complex beast and not that widely accepted (yet). As for deficiences in SLF4J API, varargs support [1] and event data support come to mind. Varargs support is very likely to be added in SLF4J 2.0. As for event data support mentioned by Ralph, the idea was initially proposed by Joern Huxhorn. I am not entirely convinced by it. However, Ralph is right to observe that had SLF4J been developped at the ASF and that Ralph, Joern and me were the only SLF4J developpers, event data support would probably be part of the SLF4J API. Having said that, since event data support is a little controversial, it might have been turned down at the ASF as well (assuming the involvement of more developpers who shared my lack of enthusiams for event data). Anyway, Ralph made some very valuable contributiuons to the logback project and I am sorry to see him stop. Given what I have seen of his work, he will surely do an excellent job with log4j v2. [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31 -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hi all guys!!! sorry for joining so late the discussion (working on some stuff as bricklayer at home!!! didn't know it is fun!) * I don't understand why JULI should be so complicated to be adopted... if in trouble, please take a look at juli-to-log4j[1] bride written by our ASF mate Paul Smith. I'm a big fan on Google Guice and I tend to write my tasks on work on top of JSR330 using it - it relies 100% on JULI for logging, when/if something goes wrong, I just hijack the logging to log4j or logback. done. And believe me, if I can do it, everybody can. * given the previous fact, the proposed facade by slf4j reminds me what we could already do using JULI and related bridges - please correct me if I'm wrong, I'm sure there are missing features I'm not aware, but I could bridge JULI to logback as well - and if omitting the -Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager is a so huge difference, I missed something * Ceki, you can't immagine how much I have to be thankful to you!!! :) I strongly respect you, your POV and what you've been doing, but I hope there will be the chance to bring you back to the ASF :) Have a nice day, all the best!!! Simo [1] http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 9, 2011 at 7:16 PM, Ceki Gulcu c...@qos.ch wrote: On 09.08.2011 11:57, Christian Grobmeier wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the log4j case before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the Apache Way itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. * On the ASF model In a nutshell, while the ASF is a great organization in many ways, it is not a meritocracy mainly because merit is not measured at all and at the project level no responsiblity is accrued on merit beyond committership. BTW, the BDFL model is not a meritocracy either. Finding a good model for running organisations is no simple matter. The Apache model may even be better than some but it bothers me that the ASF misrepresents itself as a meritocracy. * On logging One of the disadvantages of a relatively large and open ecosystem such as Java is that you get several competing libraries solving common problems. Logging is a rather devisive case in point. SLF4J has deficiences with regards to modularity are imho testimony to the lack of a widely accepted solution to modularity in Java. In any case, I am unaware of a satisfactory solution. OSGi is of course one possible approach but OSGi is a complex beast and not that widely accepted (yet). As for deficiences in SLF4J API, varargs support [1] and event data support come to mind. Varargs support is very likely to be added in SLF4J 2.0. As for event data support mentioned by Ralph, the idea was initially proposed by Joern Huxhorn. I am not entirely convinced by it. However, Ralph is right to observe that had SLF4J been developped at the ASF and that Ralph, Joern and me were the only SLF4J developpers, event data support would probably be part of the SLF4J API. Having said that, since event data support is a little controversial, it might have been turned down at the ASF as well (assuming the involvement of more developpers who shared my lack of enthusiams for event data). Anyway, Ralph made some very valuable contributiuons to the logback project and I am sorry to see him stop. Given what I have seen of his work, he will surely do an excellent job with log4j v2. [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31 -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional
Re: [logging] logging vs slf4j
Hi all, If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. +1. I like this plan. +1 I like this plan too. it sounds *very* reasonable: unified, standard (?) way to log, easy to bridge to everything needed. can we ask more? have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I'm not a fan of this plan. Have you actually tried to bridge jul to anything? While it will work anywhere that doesn't imply it will work properly. Ralph On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all, If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. +1. I like this plan. +1 I like this plan too. it sounds *very* reasonable: unified, standard (?) way to log, easy to bridge to everything needed. can we ask more? have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 08/08/2011 02:00 PM, ralph.goers @dslextreme.com wrote: On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi simonetrip...@apache.orgwrote: If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. +1. I like this plan. +1 I like this plan too. it sounds *very* reasonable: unified, standard (?) way to log, easy to bridge to everything needed. can we ask more? have a nice day, all the best!!! Simo I'm not a fan of this plan. Have you actually tried to bridge jul to anything? While it will work anywhere that doesn't imply it will work properly. Ralph I'm not a fan of this plan either. Jul bridging is not simple because JUL doesn't provide the necessary hooks, and packages under the java.* namespace can't be replaced. For example, see this slf4j page: http://www.slf4j.org/legacy.html To quote one relevant sentence: ...Consequently, j.u.l. to SLF4J translation can seriously impact on the cost of disabled logging statements (60 fold increase) and a measurable impact on enabled log statements (20% overall increase). Logging to Logback via slf4j does provide a work-around to the above performance problem (LevelChangePropagator) but other frameworks may not (log4j?), and in general configuring the JUL bridge is much harder than it should be, and many users will get it wrong. Other frameworks may have similar issues bridging JUL as well. Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta rocketra...@fastmail.fm wrote: Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict pbened...@apache.org wrote: On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta rocketra...@fastmail.fm wrote: Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. In fairness, using a dependency manager with support for transitive dependencies you should only have to specify the implementation jar. In the case of slf4j you may have to provide multiple jars (impl + bridge X n logging frameworks in use throughout your application), however. Of course, log4j v2 will have to support this paradigm in some fashion or lose runtime market share due to slf4j's ability to cater to the lowest common denominator. Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 3:23 PM, Paul Benedict pbened...@apache.org wrote: On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta rocketra...@fastmail.fm wrote: Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. +1 on that. Give me one jar. Convenience please. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 3:28 PM, Matt Benson gudnabr...@gmail.com wrote: On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict pbened...@apache.org wrote: On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta rocketra...@fastmail.fm wrote: Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. In fairness, using a dependency manager with support for transitive dependencies you should only have to specify the implementation jar. In the case of slf4j you may have to provide multiple jars (impl + bridge X n logging frameworks in use throughout your application), however. Of course, log4j v2 will have to support this paradigm in some fashion or lose runtime market share due to slf4j's ability to cater to the lowest common denominator. Even if I Iived in OSGi-land, I'd want one jar/bundle/file. Slicing and dicing in such a minute way seems like a lot of noise. If I were programming for a light bulb, I might care about how big my jars get, but I do not, so I won't ;) Gary Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 08/08/2011 03:28 PM, Matt Benson wrote: On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict pbened...@apache.org wrote: On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta rocketra...@fastmail.fm wrote: Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. This is nothing new -- commons-logging requires the commons-logging.jar for library creators, and users need commons-logging.jar plus an implementation jar. Slf4j requires the same: slf4j-api.jar for library creators and an implementation jar for users. The bridging jars are *optional* and only required by users to bridge from jcl, jul, or log4j. In fairness, using a dependency manager with support for transitive dependencies you should only have to specify the implementation jar. In the case of slf4j you may have to provide multiple jars (impl + bridge X n logging frameworks in use throughout your application), however. Of course, log4j v2 will have to support this paradigm in some fashion or lose runtime market share due to slf4j's ability to cater to the lowest common denominator. Yes, the reality is large applications need to support multiple source frameworks and will therefore require a bunch of logging jars. Slf4j provides a relatively simple path to consolidating logs from jcl, jul, and log4j into one's chosen target framework (except for jul). With the current landscape, you are dreaming if you think one magical jar is going to support all use cases. This would have been simple if jul had been designed properly, but it wasn't. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I agree with this sentiment. In the last 3 years all of the large commercial projects that I have worked on used slf4j just for the very reason that I needed to bridge the logging implementations in multiple third-party libraries. While reading this thread, one approach occurs to me that hasn't been mentioned. Why not abstract the abstraction? My gut reaction to this approach is negative, but I do feel that it is quite pragmatic. This could be done by choosing (dynamically or by configuration) the logger implementation log4j / commons / slf4j / jul and then loading the LoggerFactory into a wrapper class that is then called used by the Commons project. We would then make the logger implementations a compile-time dependency only and relay upon the consumer to provide them. I do realize that this is essentially doing a Facade on top of a Facade, but it solves the problem for consumers of the library by providing many options. So, am I crazy? -Elijah Yes, the reality is large applications need to support multiple source frameworks and will therefore require a bunch of logging jars. Slf4j provides a relatively simple path to consolidating logs from jcl, jul, and log4j into one's chosen target framework (except for jul). With the current landscape, you are dreaming if you think one magical jar is going to support all use cases. This would have been simple if jul had been designed properly, but it wasn't. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. I cannot see how that is annoying. It's simple and it works. What's annoying you about this? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Raman, You may have proposed this earlier in the thread and I didn't catch it. I actually like your suggestion the best, but it seems like it is a difficult sell for a lot of people to compile against the slf4j API for a variety of reasons that are not strictly code related. My suggestion was intended to bridge the gap between the concerns toward compiling directly against slf4j. Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. From what I can tell from the thread, here are the following points against SLF4J: * Log4j developer V2 would like to see the Apache community support the project rather than putting resources into slf4j. * Slf4j apparently has some deficiencies in its API such as: SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. * Log4j V2 also implements support for the Slf4j API. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. If we can come to some consensus regarding this issues, then I think there will be more traction toward Slf4j. Thanks, -Elijah On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta rocketra...@fastmail.fm wrote: On 08/08/2011 04:56 PM, Elijah Zupancic wrote: This could be done by choosing (dynamically or by configuration) the logger implementation log4j / commons / slf4j / jul and then loading the LoggerFactory into a wrapper class that is then called used by the Commons project. We would then make the logger implementations a compile-time dependency only and relay upon the consumer to provide them. I do realize that this is essentially doing a Facade on top of a Facade, but it solves the problem for consumers of the library by providing many options. So, am I crazy? If I understand you correctly, you would have this dependency chain: random-commons-project - commons-logging-wrapper - API like slf4j or logging implementation (at runtime) Plus commons-logging-wrapper requires compile-time knowledge of all possible target frameworks, since it is not coding to an API. Can you explain the advantage over simply coding random-commons-project against slf4j-api.jar? Then, you have this dependency chain: random-commons-project - slf4j-api - logging implementation (at runtime) And anyone can create their own slf4j compatible logging implementation simply by implementing the slf4j api and dropping their jar into their environment. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
OK. Note that -- in a similar vein to what you proposed -- I'm also fine with simply keeping commons-logging as is. The really nice thing about commons-logging is that it is based on an API (like SLF4j but unlike jul!). Therefore, it is really easy for people to do whatever they want -- e.g. for people who use slf4j, we simply ignore commons-logging.jar and drop in jcl-over-slf4j.jar instead which implements the same jcl API. The main annoyance is with dependency managers that don't understand the equivalency and therefore resolve commons-logging.jar, requiring explicit excludes. This is a manageable problem though. Cheers, Raman On 08/08/2011 05:58 PM, Elijah Zupancic wrote: Raman, You may have proposed this earlier in the thread and I didn't catch it. I actually like your suggestion the best, but it seems like it is a difficult sell for a lot of people to compile against the slf4j API for a variety of reasons that are not strictly code related. My suggestion was intended to bridge the gap between the concerns toward compiling directly against slf4j. Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. From what I can tell from the thread, here are the following points against SLF4J: * Log4j developer V2 would like to see the Apache community support the project rather than putting resources into slf4j. * Slf4j apparently has some deficiencies in its API such as: SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. * Log4j V2 also implements support for the Slf4j API. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. If we can come to some consensus regarding this issues, then I think there will be more traction toward Slf4j. Thanks, -Elijah On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta rocketra...@fastmail.fm wrote: On 08/08/2011 04:56 PM, Elijah Zupancic wrote: This could be done by choosing (dynamically or by configuration) the logger implementation log4j / commons / slf4j / jul and then loading the LoggerFactory into a wrapper class that is then called used by the Commons project. We would then make the logger implementations a compile-time dependency only and relay upon the consumer to provide them. I do realize that this is essentially doing a Facade on top of a Facade, but it solves the problem for consumers of the library by providing many options. So, am I crazy? If I understand you correctly, you would have this dependency chain: random-commons-project - commons-logging-wrapper - API like slf4j or logging implementation (at runtime) Plus commons-logging-wrapper requires compile-time knowledge of all possible target frameworks, since it is not coding to an API. Can you explain the advantage over simply coding random-commons-project against slf4j-api.jar? Then, you have this dependency chain: random-commons-project - slf4j-api - logging implementation (at runtime) And anyone can create their own slf4j compatible logging implementation simply by implementing the slf4j api and dropping their jar into their environment. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 5:58 PM, Elijah Zupancic eli...@zupancic.name wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
A few comments on the list of points against slf4j below... On 08/08/2011 05:58 PM, Elijah Zupancic wrote: From what I can tell from the thread, here are the following points against SLF4J: * Log4j developer V2 would like to see the Apache community support the project rather than putting resources into slf4j. Keep in mind that slf4j is not a logging framework -- it is only a facade that provides: 1) an API 2) (optional) bridges from jul, jcl, log4j to a target framework of choice I think there may be some confusion with Logback. Logback is the logging framework created by Ceki that *implements* the slf4j API, but is a separate project and using slf4j creates no dependency on Logback. * Slf4j apparently has some deficiencies in its API such as: SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. If this is truly an API deficiency (i.e. SLF4J, not logback), then AFAICT every other current logging API has the same deficiency, including log4j, jul and jcl -- since they are all pretty similar. IOW, very few users will care. * Log4j V2 also implements support for the Slf4j API. Great. This is an advantage of coding commons components against slf4j since both logback and log4j v2 can both be used out of the box with a native implementation of the slf4j api. * There is a hassle with too many jars for dependencies with slf4j. I addressed this previously. There is no alternative solution that is simpler. If jul had been implemented as an API (like slf4j) then we'd only need one jar. Alas... * Every time Ceki goes on vacation everything stops. Again, we are talking about an API. It rarely changes. There is little reason for it too change, and many reasons for it not to change. * Some have a preference for Apache driven projects. OK. * Figuring out the dependencies that are needed can be difficult. It's actually really simple. Far and away simpler than commons-logging. For writing a library, you need one jar: slf4j-api.jar. That's it. For developing an application, here are the dependencies in a nutshell. This should cover every common situation. Pick your desired situation, and put the jars specified on your classpath - done. 1) I want all log statements to go to log4j v1: slf4j-log4j12.jar log4j.jar 2) I want all log statements to go to log4j v2: log4jv2.jar (the above is a guess based on your statement that log4j v2 implements the slf4j-api) 3) I want all log statements to go to logback: logback-core.jar logback-classic.jar (optional) logback-access.jar (if logging web access logs) 4) I want all log statements to go to jul: slf4j-jdk14.jar 5) I want all log statements to go to jcl: slf4j-jcl.jar For *all* of the above, add: slf4j-api.jar (optional) jul-to-slf4j.jar (if using libs that call jul) (optional) jcl-over-slf4j.jar (if using libs that call jcl) JCL only supports option #1 and #4 (I think) and uses one less jar in those cases. If we can come to some consensus regarding this issues, then I think there will be more traction toward Slf4j. Cool. Given the above list, I don't really see any issue with coding commons projects against the slf4j api. Except perhaps the it's not made here thing. If that is a problem, then as I said JCL is fine and easily bridged to slf4j and thence to any desired framework. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory garydgreg...@gmail.com wrote: Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. Jochen -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
2011/8/7 Mark Thomas ma...@apache.org: On 07/08/2011 09:31, Jochen Wiedmann wrote: On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory garydgreg...@gmail.com wrote: Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. +1. I like this plan. As an aside, Tomcat doesn't use jul, it uses JULI which is a modified commons logging implementation hard coded to output to jul by default with an alternative Jar that is hard-coded for log4j. Why the complexity? jul is not class loader aware which is a problem as soon as web applications start declaring loggers with the same name. Mark Regarding Tomcat, I want to correct Mark. Tomcat JULI != commons-logging. It is just that two components are packed in the same jar. (E.g. in Tomcat 5.5 they were separate). Tomcat logging (the bin/tomcat-juli.jar: file) contains the following: 1. Tomcat JULI which are additional components to java.util.logging. There are two main components: a) a custom implementation of java.util.logging.LogManager that is classloader-aware, allows to have separate logging configuration per webapp, and also to have more rich configurations than the default LogManager b) a custom FileHandler, that is better suited to our needs than the standard one. Tomcat JULI is enabled by setting certain java properties on the command line. 2. A copy of commons-logging renamed to a different package to avoid conflicts with webapp-provided copies of the library. The tomcat-juli.jar: can come in two flavors. Default one: The default one uses stripped down copy of commons-logging that has its discovery process removed and is hardcoded to use java.util.logging. Extras one: This includes full copy of commons-logging. It is *not* hard-coded for log4j. It is just that its discovery process is kept intact, so it can choose whatever logging framework it finds. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hi Mark! Exactly the classloader problem is what we try to solve in log4j-2.0. Tomcat is by far not the only project which suffers a lot from this shortcoming. OpenWebBeans, MyFaces, OpenJPA, etc - all projects which are usually in a shared classpath have the problem that they cannot cleanly use static Loggers in their classes. Plus jul is _not_ Serializable. With jul, you have to add 20++ lines of code to every class just to fix the most fundamental functionality fixed. In this terms jul is a single big mess... LieGrue, strub --- On Sun, 8/7/11, Mark Thomas ma...@apache.org wrote: From: Mark Thomas ma...@apache.org Subject: Re: [logging] logging vs slf4j To: Commons Developers List dev@commons.apache.org Date: Sunday, August 7, 2011, 9:57 AM On 07/08/2011 09:31, Jochen Wiedmann wrote: On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory garydgreg...@gmail.com wrote: Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. +1. I like this plan. As an aside, Tomcat doesn't use jul, it uses JULI which is a modified commons logging implementation hard coded to output to jul by default with an alternative Jar that is hard-coded for log4j. Why the complexity? jul is not class loader aware which is a problem as soon as web applications start declaring loggers with the same name. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs bill.spe...@gmail.com wrote: IMO, saying Don't do logging in a library seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Yes, IMO the question should be: How and when do you do logging in a library? - if () System.out... - // System.out... - A logging lib - ... Gary Bill- On Aug 5, 2011 2:19 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 8:59 AM, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs bill.spe...@gmail.com wrote: IMO, saying Don't do logging in a library seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Yes, IMO the question should be: How and when do you do logging in a library? - if () System.out... - // System.out... - A logging lib - ... For example, in [codec] trunk, the new BM encoder uses // System.out (yuck), which then causes PMD warnings because some blocks are empty. Gary Gary Bill- On Aug 5, 2011 2:19 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
HttpComponents would be SFL4j in my structure. They definitely need debugging. Lang or Codec don't. If I had to generalize, I'd say it's because HttpComponents is not at the bottom of its stack. You need to know what the communication is between HttpComponents and the API below it (ie) a http connection to a server). Digester and DBCP are two other areas in which logging is very attractive (how is it talking to the XML or a DB). Pool less so imo - what you really want is status information on the state of the pool. Ideally we're talking event-based systems and querying rather than just simple logging [not that I've looked at Pool in eons]. It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself do I need logging? rather than how can I add logging?. I think a lot is added due to the latter approach. Hen On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs bill.spe...@gmail.com wrote: IMO, saying Don't do logging in a library seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Bill- On Aug 5, 2011 2:19 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 8/5/11 12:53 PM, Henri Yandell wrote: HttpComponents would be SFL4j in my structure. They definitely need debugging. Lang or Codec don't. If I had to generalize, I'd say it's because HttpComponents is not at the bottom of its stack. You need to know what the communication is between HttpComponents and the API below it (ie) a http connection to a server). Digester and DBCP are two other areas in which logging is very attractive (how is it talking to the XML or a DB). Pool less so imo - what you really want is status information on the state of the pool. Ideally we're talking event-based systems and querying rather than just simple logging [not that I've looked at Pool in eons]. I see [pool] and [dbcp] as having similar needs. Could be good JMX instrumentation can do it all. Needs from the client perspective are to be able to query the state of the pool and be notified or provide a log of events of interest. In the case of [pool], most events of interest involve the factory, so the workaround up to now has been to add needed capabilities to the factory. I don't get why we should abandon [logging] in favor of a non-ASF, BDFL-esque thingy if [logging] works as a bridge. What I am not sure about for [pool] and [dbcp] is if JMX instrumentation and some other API improvements might just meet the need without introducing logging at all. I think we are conflating two different topics on this thread - 1) future of [logging] 2) what commons components should use for logging. Unless [logging] has terrible flaws that somehow fixed in the SF thing, we should use it, IMO. Phil It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself do I need logging? rather than how can I add logging?. I think a lot is added due to the latter approach. Hen On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs bill.spe...@gmail.com wrote: IMO, saying Don't do logging in a library seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Bill- On Aug 5, 2011 2:19 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 05/08/2011 9:53 PM, Henri Yandell wrote: It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself do I need logging? rather than how can I add logging?. I think a lot is added due to the latter approach. +1 Hen -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Aug 5, 2011, at 16:27, Phil Steitz phil.ste...@gmail.com wrote: On 8/5/11 12:53 PM, Henri Yandell wrote: HttpComponents would be SFL4j in my structure. They definitely need debugging. Lang or Codec don't. If I had to generalize, I'd say it's because HttpComponents is not at the bottom of its stack. You need to know what the communication is between HttpComponents and the API below it (ie) a http connection to a server). Digester and DBCP are two other areas in which logging is very attractive (how is it talking to the XML or a DB). Pool less so imo - what you really want is status information on the state of the pool. Ideally we're talking event-based systems and querying rather than just simple logging [not that I've looked at Pool in eons]. I see [pool] and [dbcp] as having similar needs. Could be good JMX instrumentation can do it all. Needs from the client perspective are to be able to query the state of the pool and be notified or provide a log of events of interest. In the case of [pool], most events of interest involve the factory, so the workaround up to now has been to add needed capabilities to the factory. I don't get why we should abandon [logging] in favor of a non-ASF, BDFL-esque thingy if [logging] works as a bridge. +1 Gary What I am not sure about for [pool] and [dbcp] is if JMX instrumentation and some other API improvements might just meet the need without introducing logging at all. I think we are conflating two different topics on this thread - 1) future of [logging] 2) what commons components should use for logging. Unless [logging] has terrible flaws that somehow fixed in the SF thing, we should use it, IMO. Phil It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself do I need logging? rather than how can I add logging?. I think a lot is added due to the latter approach. Hen On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs bill.spe...@gmail.com wrote: IMO, saying Don't do logging in a library seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Bill- On Aug 5, 2011 2:19 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict pbened...@apache.org wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory garydgreg...@gmail.com wrote: On Aug 5, 2011, at 16:27, Phil Steitz phil.ste...@gmail.com wrote: On 8/5/11 12:53 PM, Henri Yandell wrote: HttpComponents would be SFL4j in my structure. They definitely need debugging. Lang or Codec don't. If I had to generalize, I'd say it's because HttpComponents is not at the bottom of its stack. You need to know what the communication is between HttpComponents and the API below it (ie) a http connection to a server). Digester and DBCP are two other areas in which logging is very attractive (how is it talking to the XML or a DB). Pool less so imo - what you really want is status information on the state of the pool. Ideally we're talking event-based systems and querying rather than just simple logging [not that I've looked at Pool in eons]. I see [pool] and [dbcp] as having similar needs. Could be good JMX instrumentation can do it all. Needs from the client perspective are to be able to query the state of the pool and be notified or provide a log of events of interest. In the case of [pool], most events of interest involve the factory, so the workaround up to now has been to add needed capabilities to the factory. I don't get why we should abandon [logging] in favor of a non-ASF, BDFL-esque thingy if [logging] works as a bridge. +1 Looking forward to Logging 1.1.2 being released :) Hen [Grim Reaper, Janitor, Mr Attic etc etc] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
2011/8/4 Ralph Goers ralph.go...@dslextreme.com The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't have anything to do with logging. In fact I would have said a library in general that is referenced both in the portal application and in portlets. Anyway you're right, if JBPortal would have shaded the logging framework, the problem would disappear. Antonio
Re: [logging] logging vs slf4j
My thought is that there might be some java.util.logging helpers that could be written, and perhaps they might go in [lang] if there are 5 or fewer classes. I assume that slf4j and log4j have their own j.u.logging connections, so that end is dealt with. The time of [logging] has probably passed. Stephen On 3 August 2011 06:50, Henri Yandell flame...@gmail.com wrote: On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) Primarily that I don't get the feeling we have a major community of developers on c-logging. We implemented it because we needed something for our other components (though many simply chose not to log), but it was never the passion of anybody here (hopefully not an incorrect statement). Robert, Simon and others put in tons of good work, but I feel that was duty not passion. So happy to see it die because it's something that's headed to dormancy (be it stable or not). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hasn't the time for both CL and log4j passed by? The trend nowadays seems to be slf4j/logback. Den 3. aug. 2011 15:03 skrev Gary Gregory garydgreg...@gmail.com følgende: Or maybe Log4j 2 could replace [logging]. Gary On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne scolebou...@joda.org wrote: My thought is that there might be some java.util.logging helpers that could be written, and perhaps they might go in [lang] if there are 5 or fewer classes. I assume that slf4j and log4j have their own j.u.logging connections, so that end is dealt with. The time of [logging] has probably passed. Stephen On 3 August 2011 06:50, Henri Yandell flame...@gmail.com wrote: On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) Primarily that I don't get the feeling we have a major community of developers on c-logging. We implemented it because we needed something for our other components (though many simply chose not to log), but it was never the passion of anybody here (hopefully not an incorrect statement). Robert, Simon and others put in tons of good work, but I feel that was duty not passion. So happy to see it die because it's something that's headed to dormancy (be it stable or not). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Aug 3, 2011, at 6:07 AM, David Karlsen wrote: Hasn't the time for both CL and log4j passed by? The trend nowadays seems to be slf4j/logback. If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Aug 3, 2011, at 6:07 AM, David Karlsen wrote: Hasn't the time for both CL and log4j passed by? The trend nowadays seems to be slf4j/logback. If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory garydgreg...@gmail.com wrote: I like Log4J just fine thank you very much :) I'm looking forward to 2.0. Gary I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My dependencies do, however, but LOG4J works great minus a few enhancements I'd like to see. BTW, in terms of swelling community development, if LOG4J+JCL were to merge and just become JCL2, it could have the visibility of all Commons committers. Isn't it much more of a common component than a separate project? I think the logging project is dysfunctional anyway -- make it a common component if possible. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
First of all, sorry to jump in at this point of the discussion. 2011/7/28 Simone Tripodi simonetrip...@apache.org Hi all guys, I remember I raw a thread - not sure if I did it here at commons or somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) I think that we should start from the fact that many application developers use Log4j 1.2 for their purposes, simply because it is *enough* configurable and *enough* useful. Sincerely I think that we don't need anything more than what Log4j 1.2 already provides. And I don't think that j.u.logging is useful enough, the configuration is simply not there. Stated this, obviously it is out of the question to adopt Log4j, simply because Commons is made of libraries, and other libraries use other logging frameworks. So we need a wrapper. I would choose SLF4J for a simple consideration: there is a Commons Logging substitute in SLF4J (jcl-over-slf4j) but not a SLF4J substitute in Commons Logging. From a Maven perspective, If Commons Logging is chosen, when a common library is included, SLF4J users must exclude commons-logging dependency to add jcl-over-slf4j, for all libraries. However in my experience SLF4J has a big drawback: when used in a shared classloader (JBoss Portal anyone?) it is needed to have the same stinky old version of SLF4J in all applications during compile time, and the library should be excluded from the package. Antonio P.S. The world was better when there was only Log4j :-D
Re: [logging] logging vs slf4j
Paul, BTW, in terms of swelling community development, if LOG4J+JCL were to merge and just become JCL2, it could have the visibility of all Commons committers. Isn't it much more of a common component than a separate project? I think the logging project is dysfunctional anyway -- make it a common component if possible. in logging.apache.org are other sub projects doing similar stuff, like log4php, log4c and such. In addition there is the companions subproject. And there is some activity in the logging project. We have had a new addition to the PMC recently and log4php has released a new version before a short while. Together with the log4j2 efforts and the efforts put from time to time into cmpanions and chainsaw, I would say the project is a bit silent, but not dead. If you take out log4j, everything else in logging would become instable. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Antonio Petrelli wrote: However in my experience SLF4J has a big drawback: when used in a shared classloader (JBoss Portal anyone?) it is needed to have the same stinky old version of SLF4J in all applications during compile time, and the library should be excluded from the package. Hello Antonio, Since version 1.0 released about 5 years ago, all versions of SLF4J are compile-time compatible. For example, you can compile code with slf4j-api version 1.4.3 and run it just fine with any other version of slf4j-api, including 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x., 1.5.x and 1.6.x. On the other hand, the version of slf4j binding that you select at runtime needs to match the slf4j-api. For example, if you have slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then you need slf4j-log4j12-1.6.1.jar on your class path, slf4j-log4j12-1.4.3.jar will not work. HTH, -- QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software developers. For further details, see http://logback.qos.ch/job.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hi Ceki 2011/8/3 Ceki Gülcü c...@qos.ch Antonio Petrelli wrote: On the other hand, the version of slf4j binding that you select at runtime needs to match the slf4j-api. For example, if you have slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then you need slf4j-log4j12-1.6.1.jar on your class path, slf4j-log4j12-1.4.3.jar will not work. I think this is the JBoss Portal case, in which slf4j 1.4.3 (both api and binding) is installed and all the portlets are forced to use it. So I think it is a problem with JBoss and JBoss Portal, or even portlet specification itself that are flawed. However the main difference between SLF4J and JCL is that JCL is stuck to 1.1.1 so there is less opportunity for a version mismatch :-D Thanks, I will reply to my own email in the Commons ML about it. Antonio
Re: [logging] logging vs slf4j
2011/8/3 Antonio Petrelli antonio.petre...@gmail.com However in my experience SLF4J has a big drawback: when used in a shared classloader (JBoss Portal anyone?) it is needed to have the same stinky old version of SLF4J in all applications during compile time, and the library should be excluded from the package. Correcting myself, this is a flaw in JBoss Portal and/or the portlet specification, because they need a shared classloader to work, the same problem would happen using commons-logging. Antonio
Re: [logging] logging vs slf4j
The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't have anything to do with logging. Ralph On Aug 3, 2011, at 11:18 AM, Antonio Petrelli wrote: 2011/8/3 Antonio Petrelli antonio.petre...@gmail.com However in my experience SLF4J has a big drawback: when used in a shared classloader (JBoss Portal anyone?) it is needed to have the same stinky old version of SLF4J in all applications during compile time, and the library should be excluded from the package. Correcting myself, this is a flaw in JBoss Portal and/or the portlet specification, because they need a shared classloader to work, the same problem would happen using commons-logging. Antonio - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) Primarily that I don't get the feeling we have a major community of developers on c-logging. We implemented it because we needed something for our other components (though many simply chose not to log), but it was never the passion of anybody here (hopefully not an incorrect statement). Robert, Simon and others put in tons of good work, but I feel that was duty not passion. So happy to see it die because it's something that's headed to dormancy (be it stable or not). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Folks, I' suggest the following: 1.) create single JARs which exactly do what they should. 2.) use the maven-shade-plugin [1] to package 'bundles' containing some fitting jars of your project just for convenience. LieGrue, strub [1] http://maven.apache.org/plugins/maven-shade-plugin/ --- On Fri, 7/29/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [logging] logging vs slf4j To: Commons Developers List dev@commons.apache.org Date: Friday, July 29, 2011, 5:39 PM Unfortunately, you are in the minority on this one. Technically, you could just use the Log4J 2.0 Impl jar, but then you would be coding to a private API. Ralph On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote: One thing that is a hassle to me with modularized projects, even slf4j, is that you end up with a bunch of tiny jars. IOW IMO: a mess. Personally, I want one jar to rule them all. If I want to switch logging implementer or a client wants another impl I have to fiddle with my builds and explain what each jar does. It's a hassle. Gary On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt tcu...@vafer.org wrote: At some stage I started to refactor commons logging into a multi module maven project and got rid of the discovery part. So you would have the commons-logging-api jar plus exactly one of the implementation bridges. So you pick the logging target by putting the correct bridge into your classpath. Similar to slf4j. Didn't think there is still interest in commons logging. Not sure I still have the code. I lost interest after yet another logging discussion :) ...but it shouldn't be hard to re-create. Not sure there is still enough interest in this. Seems to me you should focus on making Log4J the impl excellent That sounds like work ;) Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Which is one of the reasons I have always been very reluctant to use it. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
great news Ralph, and kudos for your hard work! looking forward to hear more from log4j soon! have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jul 29, 2011 at 5:53 AM, Ralph Goers ralph.go...@dslextreme.com wrote: Oh - I should have also mentioned that I implemented support for the SLF4J API and commons logging as well as the new Log4J API. Ralph On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: Random input. Seems to me you should focus on making Log4J the impl excellent and not trying to create yet.another.facade. ie) Don't compete with SLF4J, compete with Logback (given its licensing). Hen On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
At some stage I started to refactor commons logging into a multi module maven project and got rid of the discovery part. So you would have the commons-logging-api jar plus exactly one of the implementation bridges. So you pick the logging target by putting the correct bridge into your classpath. Similar to slf4j. Didn't think there is still interest in commons logging. Not sure I still have the code. I lost interest after yet another logging discussion :) ...but it shouldn't be hard to re-create. Not sure there is still enough interest in this. Seems to me you should focus on making Log4J the impl excellent That sounds like work ;) Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Which is one of the reasons I have always been very reluctant to use it. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Jul 29, 2011 at 10:33 AM, Torsten Curdt tcu...@vafer.org wrote: At some stage I started to refactor commons logging into a multi module maven project and got rid of the discovery part. So you would have the commons-logging-api jar plus exactly one of the implementation bridges. So you pick the logging target by putting the correct bridge into your classpath. Similar to slf4j. Didn't think there is still interest in commons logging. Not sure I still have the code. I lost interest after yet another logging discussion :) ...but it shouldn't be hard to re-create. Not sure there is still enough interest in this. To be honest, I would love to see this. I like log4j/commons-logging very much, but there has been decreasing development effort the past years and slf4j/logback grew strong. Finally I though at least commons-logging is dead. I prefer asf libs, and so I would love to see your changes. This surely would help to revive the loggings project, which already is resurrecting due to Ralphs efforts with Log4j 2. So my interest is here, but I am not sure if I have enough time left to give the support it deserves :-) Cheers Christian Seems to me you should focus on making Log4J the impl excellent That sounds like work ;) Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Which is one of the reasons I have always been very reluctant to use it. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Would there be any merit in combining the log4j and commons logging code? Given a hypothetical Log4j 2 and JCL 2, how much different could they really be in terms of their goals and add-ins? On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hello. I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Do you have a pointer to a listing of those deficiencies? [...] Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Unfortunately, you are in the minority on this one. Technically, you could just use the Log4J 2.0 Impl jar, but then you would be coding to a private API. Ralph On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote: One thing that is a hassle to me with modularized projects, even slf4j, is that you end up with a bunch of tiny jars. IOW IMO: a mess. Personally, I want one jar to rule them all. If I want to switch logging implementer or a client wants another impl I have to fiddle with my builds and explain what each jar does. It's a hassle. Gary On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt tcu...@vafer.org wrote: At some stage I started to refactor commons logging into a multi module maven project and got rid of the discovery part. So you would have the commons-logging-api jar plus exactly one of the implementation bridges. So you pick the logging target by putting the correct bridge into your classpath. Similar to slf4j. Didn't think there is still interest in commons logging. Not sure I still have the code. I lost interest after yet another logging discussion :) ...but it shouldn't be hard to re-create. Not sure there is still enough interest in this. Seems to me you should focus on making Log4J the impl excellent That sounds like work ;) Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Which is one of the reasons I have always been very reluctant to use it. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Commons Logging takes a least common denominator approach, which makes it useful for only fairly simple use cases. The goals for Log4J 2 are much more extensive than just a simple API that wraps other logging frameworks. Ralph On Jul 29, 2011, at 6:19 AM, Paul Benedict wrote: Would there be any merit in combining the log4j and commons logging code? Given a hypothetical Log4j 2 and JCL 2, how much different could they really be in terms of their goals and add-ins? On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hello. I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Do you have a pointer to a listing of those deficiencies? [...] Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
The major issue I had was https://issues.apache.org/jira/browse/LOG4J2-31. We currently use SLF4J for audit logging via the SLF4J extension's EventLogger and EventData. Unfortunately, SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. To use this I had to create a Layout wrapper to convert the XML back to an EventData object so it could be used in various components. Needless to say this is cumbersome, slow and error prone. The Log4J 2.0 API uses a Message interface for everything. This allows the caller to have much more control over the formatting of the objects without having to write complex layouts that check for the presence of certain types of objects as parameters (which they can still do of course). Ralph On Jul 29, 2011, at 2:51 AM, Gilles Sadowski wrote: Hello. I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Do you have a pointer to a listing of those deficiencies? [...] Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
hahahaha :D I asked because there's one user that proposed a [chain] evolution, and one of suggested improvements is migrating over slf4j - I (wrongly, maybe) suggested to keep [logging] because here at commons we continue using it but, as said, I maybe reported a wrong fact. Do we encourage such kind of migrations or we are more conservative? Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jul 28, 2011 at 10:01 PM, Henri Yandell flame...@gmail.com wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons or somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3 branch to make SLF4J? Anyways, I have no idea why all the creativity for logging went outside of Apache, but I would definitely like to see a version 2.0. You taking feature requests yet in JIRA? :-) Paul On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Great news Ralph. I look forward to the new version. Gary On Jul 28, 2011, at 20:26, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Yes, Ceki created SLF4J and Logback based on his experience with 1.2 and 1.3. The logging community is pretty small and really could use more people involved. I've had quite a bit of experience with logging for my employer as our needs are a bit different than what most people use a logging framework for. As a consequence, one of my primary focuses has been to make sure those use cases are supported, in addition to what SLF4J, Logback and Log4j do. https://issues.apache.org/jira/browse/LOG4J2 is where all the feature requests currently reside. Log4j 1.x is in bugzilla. Ralph On Jul 28, 2011, at 5:39 PM, Paul Benedict wrote: Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3 branch to make SLF4J? Anyways, I have no idea why all the creativity for logging went outside of Apache, but I would definitely like to see a version 2.0. You taking feature requests yet in JIRA? :-) Paul On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Random input. Seems to me you should focus on making Log4J the impl excellent and not trying to create yet.another.facade. ie) Don't compete with SLF4J, compete with Logback (given its licensing). Hen On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Ralph On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: Random input. Seems to me you should focus on making Log4J the impl excellent and not trying to create yet.another.facade. ie) Don't compete with SLF4J, compete with Logback (given its licensing). Hen On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Oh - I should have also mentioned that I implemented support for the SLF4J API and commons logging as well as the new Log4J API. Ralph On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: Random input. Seems to me you should focus on making Log4J the impl excellent and not trying to create yet.another.facade. ie) Don't compete with SLF4J, compete with Logback (given its licensing). Hen On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers ralph.go...@dslextreme.com wrote: FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
