Re: [logging] Tapestry and JCL
Hello, Simon Kitching wrote: If I were writing a 1.4+ library or app, I'd just use java.util.logging directly. Which reminds me: is the JULI implementation of the java.util.logging API (used in tomcat) available as an independent library? If not, maybe it is worth extracting it as a project of the logging.apache.org group? this is exactly what x4juli ( http://www.x4juli.org ) does: Combine the advantages of Tomcat JULI (Support of per Classloader Logging / configuration and avoiding memory leaks), port the configuration, appenders and goodies of log4j, and implementing a native version of JCL and SLF4J (Different to a static/dynamic bound wrapper, the X4JULI Logger does implement the interfaces). http://svn.berlios.de/wsvn/x4juli/trunk/src/java/org/x4juli/logger/X4JuliLogger.java?op=filerev=0sc=0 Currently I am spending 12-16 hours per day at my company and have no time to develop and release a new version, but may be in September/October. The current SVN trunk does not work, I had to stop my development for mentioned reasons. The version 0.6 does work, even when there is a problem in the samples with the binaries. Regards Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On 31/07/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/28/06, James Carman [EMAIL PROTECTED] wrote: ... Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking Surely java.util.regex requires 1.4? about 1.4 so we can drop the commons-logging dependencies? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On 7/28/06, James Carman [EMAIL PROTECTED] wrote: Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: I've been meaning to ask... is there really much reason for a JDK 1.4+ application/library to depend on commons-logging? Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking about 1.4 so we can drop the commons-logging dependencies? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On Mon, 2006-07-31 at 13:08 -0700, Henri Yandell wrote: On 7/28/06, James Carman [EMAIL PROTECTED] wrote: Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: I've been meaning to ask... is there really much reason for a JDK 1.4+ application/library to depend on commons-logging? Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking about 1.4 so we can drop the commons-logging dependencies? If I were writing a 1.4+ library or app, I'd just use java.util.logging directly. Which reminds me: is the JULI implementation of the java.util.logging API (used in tomcat) available as an independent library? If not, maybe it is worth extracting it as a project of the logging.apache.org group? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Tapestry and JCL
I thought I remembered being part of a conversation about having implementation jars and an API jar. But, I have kind of fell out of the loop a bit w.r.t. JCL. Did that ever come to fruition? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Torsten Curdt Sent: Saturday, July 29, 2006 12:10 AM To: Jakarta Commons Developers List Subject: Re: [logging] Tapestry and JCL A pretty common complaint is that commons-logging is a problem. It does some wierd and awkward class loading things that ultimately result in memory leaks. Well, it's probably not me to answer (Simon?) but AFAIU most of these things were addressed with the last release of JCL. What's left is basically a bad reputation to live with. A more separated/clean approach is planned for a 2.0 release. But I think so far this has only been discussed. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Tapestry and JCL
I think projects should use the best tool for the job (as long as its license is ASL compatible). Apache doesn't have a monopoly on good ideas. If the Tapestry developers really feel SLF4J is better, then that's their choice and all power to them. Although I contribute patches to JCL, I'm certainly not claiming it is perfect - or even terribly good. Having said that, the 1.1 release of JCL is expected to resolve the vast majority of problems previously experienced by users; it now does its best to avoid throwing exceptions even when this means that output may not be generated, or not generated in the expected way. However JCL is definitely hampered by its history, and is now quite a complex beast. That means a greater risk of bugs/issues of course. A new 2.x version really is needed to get rid of all the old cruft but working on commons-logging is not glamorous or terribly rewarding so this may be a while off yet. SLF4J is a good project. It does have some differences from commons-logging. They are: * if using parent-first classloading, and SLF4J is in an ancestor classpath then there is no way for a webapp to configure its own logging library. And if that library doesn't internally support per-webapp configuration, then logging *config* is global across all webapps. This is a direct consequence of the decision in SLF4J not to use classloader tricks. Thus SLF4J is more predictable but less flexible. * SLF4J is far less widely used. Many of the issues with JCL only became known as it was used in various containers with weird classloading approaches. SLF4J's simplicity means that it is *less* likely to strike problems that JCL did, but then again there are some truly odd situations out there (that we worked through while creating the 1.1 JCL release). * I'm personally unconvinced by its approach to i18n. Of course JCL doesn't try to support i18n in its api at all, but I would suggest thinking carefully before using the i18n methods in SLF4J. There are some other options. I believe tomcat 6.x currently includes a statically-bound implementation of the JCL API (probably bound to JULI, which is a java.util.logging implementation). I think SLF4J even offers an implementation of the JCL api that maps to SLF4J adapters. Regards, Simon On Fri, 2006-07-28 at 10:14 -0400, James Carman wrote: Regardless, it's still not an ASF project. We should try to eat our own dog food IMHO. If we don't use our own libraries because we think they're sub-par, then why should anyone else? -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:44 AM To: Jakarta Commons Developers List Subject: Re: [logging] Tapestry and JCL From: James Carman [EMAIL PROTECTED] Thoughts? I would really hate to see an Apache TLP, java-based project switch off JCL in favor of a non-ASF logging API. Unless I'm mistaken, SLF4J comes from Ceki, creator of Log4J. Thus the SLF4J website and separation is as much for political reasons as anything else. (ie, if it was release as part of Log4J, people wouldn't see it as truly independent of Log4J) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Tapestry and JCL
Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: A pretty common complaint is that commons-logging is a problem. It does some wierd and awkward class loading things that ultimately result in memory leaks. An alternative is SL4J: http://www.slf4j.org/ It has an improved API over commons-logging, making it easier to build out complex messages. It's basic claim to fame is that it is statically bound. There are different implementations of the framework for different toolkits. We could bind to the log4j version for testing and building, and users will bind to a specific version for deployment. It is under the X11 license (compatible with the ASL). The only problem is that the code is not quite threadsafe, something I can address inside Tapestry 5 code. Thoughts? I have sent them the link to the memory leak WIKI page and suggested adding in a web filter that releases the resources for the current thread's context classloader (as prescribed by the WIKI). Does anyone else have any suggestions on what could/should be done? I would really hate to see an Apache TLP, java-based project switch off JCL in favor of a non-ASF logging API. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
From: James Carman [EMAIL PROTECTED] Thoughts? I would really hate to see an Apache TLP, java-based project switch off JCL in favor of a non-ASF logging API. Unless I'm mistaken, SLF4J comes from Ceki, creator of Log4J. Thus the SLF4J website and separation is as much for political reasons as anything else. (ie, if it was release as part of Log4J, people wouldn't see it as truly independent of Log4J) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Tapestry and JCL
Regardless, it's still not an ASF project. We should try to eat our own dog food IMHO. If we don't use our own libraries because we think they're sub-par, then why should anyone else? -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:44 AM To: Jakarta Commons Developers List Subject: Re: [logging] Tapestry and JCL From: James Carman [EMAIL PROTECTED] Thoughts? I would really hate to see an Apache TLP, java-based project switch off JCL in favor of a non-ASF logging API. Unless I'm mistaken, SLF4J comes from Ceki, creator of Log4J. Thus the SLF4J website and separation is as much for political reasons as anything else. (ie, if it was release as part of Log4J, people wouldn't see it as truly independent of Log4J) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
A pretty common complaint is that commons-logging is a problem. It does some wierd and awkward class loading things that ultimately result in memory leaks. Well, it's probably not me to answer (Simon?) but AFAIU most of these things were addressed with the last release of JCL. What's left is basically a bad reputation to live with. A more separated/clean approach is planned for a 2.0 release. But I think so far this has only been discussed. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]