You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/07/28 14:06:00 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by sebb <se...@gmail.com>.
On 31/07/06, Henri Yandell <fl...@gmail.com> wrote:
> On 7/28/06, James Carman <ja...@carmanconsulting.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by Henri Yandell <fl...@gmail.com>.
On 7/28/06, James Carman <ja...@carmanconsulting.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Tapestry and JCL
Posted by James Carman <ja...@carmanconsulting.com>.
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: tcurdt@gmail.com [mailto:tcurdt@gmail.com] 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by Torsten Curdt <tc...@apache.org>.
> "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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by Boris Unckel <bo...@gmx.net>.
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=file&rev=0&sc=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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2006-07-31 at 13:08 -0700, Henri Yandell wrote:
> On 7/28/06, James Carman <ja...@carmanconsulting.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Tapestry and JCL
Posted by Simon Kitching <sk...@apache.org>.
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:scolebourne@btopenworld.com]
> Sent: Friday, July 28, 2006 9:44 AM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Tapestry and JCL
>
> From: James Carman <ja...@carmanconsulting.com>
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Tapestry and JCL
Posted by James Carman <ja...@carmanconsulting.com>.
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:scolebourne@btopenworld.com]
Sent: Friday, July 28, 2006 9:44 AM
To: Jakarta Commons Developers List
Subject: Re: [logging] Tapestry and JCL
From: James Carman <ja...@carmanconsulting.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Tapestry and JCL
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: James Carman <ja...@carmanconsulting.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org