Re: [slf4j-user] JUL to LOG4J
Well ..., I have been struggling with the same thing myself. I once created a spring bean to be able to do call this from a spring configuration. But for now I just settled with calling this in the initialization class of my Wicket applications. I am also interested in better solutions. Regards, Erik. J G wrote: Hi Erik, Thanks for the response. What's the typical pattern for calling this initialization method? I want to make this as lightweight as possible and would prefer not to have to create a servlet just for the container to initialize sl4fj. Are there any other strategies or patterns people use? Thanks. > Date: Fri, 24 Jul 2009 12:31:25 +0200 > From: e.vanoos...@grons.nl > To: user@slf4j.org > Subject: Re: [slf4j-user] JUL to LOG4J > > Having the jar on your classpath is not sufficient. You also need to > execute (e.g. sometimes during initialization): > > SLF4JBridgeHandler.install(); > > Regards, > Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] JUL to LOG4J
Having the jar on your classpath is not sufficient. You also need to execute (e.g. sometimes during initialization): SLF4JBridgeHandler.install(); Regards, Erik. J G wrote: Hello, I am trying to use a 3rd party framework(solr) and have its logging rerouted to log4j and stored in my log4j.xml file. I am running tomcat 5.5 and have enabled tomcat route all of its logging to log4j which is working fine. However, I can't get solr(which utilizes java.utl.logging) to work similarly. After reading the documentation and similar mailing list messages my understanding is that all I would have to add to Tomcat's classpath(tomcat/common/lib) is the slf4j-api.jar and the slf4j-jdk14.jar. I feel as if I am mising some configuration/concept or combination of the two which is why it's not working. If there is configuration that needs to take place, anything you can provide is appreciated. Any additional information,references or concepts I am missing are appreciated too. Thanks. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] [POLL] Requiring JDK 1.5 for SLF4J
yes Ceki Gulcu wrote: Do you accept SLF4J dropping JDK 1.3 compatibility and require JDK 1.5 instead? ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Redirecting Outputstream to the logger
Hi,
We are currently using the implementation attached below. It was found
on the web for free use. It bears no copyright statement, only the
author's name so I guess it is good for open sourcing properly.
The implementation is written for log4j, adapting it for slf4j should be
trivial.
Regards,
Erik.
Papick Garcia Taboada wrote:
Hi,
I have an API that outputs some usefull information to an OutputStream.
I would like to pipe this to slf4j.
Is there a nice wrapper for that?
brgds,
Papick
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---8<
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
import java.io.OutputStream;
import java.io.IOException;
/**
* An OutputStream that flushes out to a Category.
*
* Note that no data is written out to the Category until the stream is
* flushed or closed.
*
* Example:
* // make sure everything sent to System.err is logged
* System.setErr(new PrintStream(new
* LoggingOutputStream(Logger.getRootCategory(),
* Level.WARN), true));
*
* // make sure everything sent to System.out is also logged
* System.setOut(new PrintStream(new
* LoggingOutputStream(Logger.getRootCategory(),
* Level.INFO), true));
*
*
* @author Jim Moore
* @see org.apache.log4j.Category
*/
//
public class LoggingOutputStream extends OutputStream {
/**
* Used to maintain the contract of [EMAIL PROTECTED] #close()}.
*/
private boolean hasBeenClosed = false;
/**
* The internal buffer where data is stored.
*/
private byte[] buf;
/**
* The number of valid bytes in the buffer. This value is always
* in the range 0 through buf.length; elements
* buf[0] through buf[count-1] contain valid
* byte data.
*/
private int count;
/**
* Remembers the size of the buffer for speed.
*/
private int bufLength;
/**
* The default number of bytes in the buffer. =2048
*/
public static final int DEFAULT_BUFFER_LENGTH = 2048;
/**
* The category to write to.
*/
private Logger logger;
/**
* The priority to use when writing to the Category.
*/
private Level level;
/**
* Creates the LoggingOutputStream to flush to the given Category.
*
* @param log the Logger to write to
* @param level the Level to use when writing to the Logger
* @throws IllegalArgumentException if cat == null or priority ==
* null
*/
public LoggingOutputStream(Logger log, Level level)
throws IllegalArgumentException {
if (log == null) {
throw new IllegalArgumentException("cat == null");
}
if (level == null) {
throw new IllegalArgumentException("priority == null");
}
this.level = level;
logger = log;
bufLength = DEFAULT_BUFFER_LENGTH;
buf = new byte[DEFAULT_BUFFER_LENGTH];
count = 0;
}
/**
* Closes this output stream and releases any system resources
* associated with this stream. The general contract of
* close
* is that it closes the output stream. A closed stream cannot
* perform
* output operations and cannot be reopened.
*/
public void close() {
flush();
hasBeenClosed = true;
}
/**
* Writes the specified byte to this output stream. The general
* contract for write is that one byte is written
* to the output stream. The byte to be written is the eight
* low-order bits of the argument b. The 24
* high-order bits of b are ignored.
*
* @param b the byte to write
* @throws java.io.IOException if an I/O error occurs. In particular, an
IOException may be
* thrown if the output stream has been closed.
*/
public void write(final int b) throws IOException {
if (hasBeenClosed) {
throw new IOException("The stream has been closed.");
}
// would this be writing past the buffer?
if (count == bufLength) {
// grow the buffer
final int newBufLength = bufLength + DEFAULT_BUFFER_LENGTH;
final byte[] newBuf = new byte[newBufLength];
System.arraycopy(buf, 0, newBuf, 0, bufLength);
buf = newBuf;
bufLength = newBufLength;
}
buf[count] = (byte) b;
count++;
}
/**
* Flushes this output stream and forces any buffered output bytes
* to be written out. The general contract of flush is
* that calling it is an indication that, if any bytes previously
* written have been buffered by the implementation of the output
* stream, such bytes should immediately be written to their
* intended destination.
*/
public void flush() {
if (count == 0) {
retur
Re: [slf4j-user] Java 5 version of SLF4J?
Simon Kitching wrote: > A push is quick, and cleaning up a callstack afterwards is normally done in > fixed-time, regardless of what was on the stack. If params are passed in > registers, it is even quicker. So IMO, SLF4J's approach is fine from a > performance approach. Sorry if my mail wasn't clear on that. > > IMO, creating the Object[] is worth avoiding, however, which rules out real > varargs implemetations [1]. The cost is not just creating, but also > garbage-collection afterwards. Yes, that is true but negligible as well. Newer JVM's (I believe starting from JSE5) will clean up shortly, or unused variables in fixed time as well. Objects can even be created on the call stack! Regards, Erik. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Simon,
What you describe under [1] is called escape analysis. Under most
circumstances most code and most data is unused. This can be detected,
and some compilers actually do this. As I said, I am not sure the JVM is
capable of doing this. BTW, a runtime compiler such as hotspot has many
more options to do escape analysis then a static compiler.
> That would be seriously smart optimisation though.
I think you underestimate the cleverness of the JVM people :)
Apart from the potential performance penalty, I still think log5j has a
nicer interface. I would use it if was available for slf4j.
> I think the lack of varargs support is a feature, and good api design.
Well, I certainly do not agree there. But anyway, there are enough other
reasons for not changing the slf4j interface.
Regards,
Erik.
Simon Kitching wrote:
> Hi Erik,
>
> You're right that the correspondence between bytecode and actual machine
> instructions is not direct. And in fact, the machine instructions
> could even vary during a program's run if the JVM is doing dynamic
> optimisation.
>
> But in this specific case,
> (a) Whether the formatting parameters are used or not depends upon the
> current setting of the logging threshold level for that category. There
> is no way the caller can determine that, so AFAICT the params will
> really have to be passed somehow. [1]
> (b) If the params are used, then they are passed as an object array to
> java.util.Formatter so an object array does need to be created at that
> point. *Possibly* a clever runtime optimiser could pass the params in
> registers, and delay creating of the object array until after the
> threshold test is done. That would be seriously smart optimisation
> though. For a start, doing this means changing the way that callers
> invoke the method, so would need to dynamically be patched into every
> callsite, not just optimise the internal implementation of a method. And
> different Logger objects can theoretically have different concrete
> implementations at runtime, so the mechanism used to invoke the call
> would need to vary depending upon the concrete implementation
> referenced. I can't see that being feasable.
>
> [1] Unless the runtime optimiser sees that the first thing the called
> method does is invoke isXXXEnabled, before using any params. When the
> calling site is using a final reference to the logger object, it would
> then be possible to migrate that call up into the calling site, and the
> effect would be like wrapping every call in isXXXEnabled, which would be
> nice. I have no idea whether any existing JVMs do this; it's fairly
> clever work. Hmm.. it would also mean presumably rewriting the called
> method so that the isXXXEnabled does not get called multiple times. But
> that would then break other callers. Ouch, this makes my head hurt :-)
>
> I'd be willing to bet that in everything except specialist jvms (and
> maybe there too), the log5j approach has a significant performance
> penalty due to the creation of an object array for each call, and
> therefore manually wrapping in isXXXEnabled is needed.
>
> But
>// standard SLF4J or JCL
>if (log.isDebugEnabled())
> log.debug(String.format("...", arg1, arg2, arg3, arg4));
> and
>// log5j only
>if (log.isDebugEnabled())
> log.debug("...", arg1, arg2, arg3, arg4);
> are identical in performance, and not much different aesthetically.
>
> The mere existence of the varargs method, however, is a performance trap
> just waiting for users to fall into, tempting them to omit the
> isDebugEnabled call. A small trap, but nevertheless there. By *not*
> providing a varargs option, the SLF4J/JCL API instead makes it obvious
> that the isDebugEnabled is necessary. I think the lack of varargs
> support is a feature, and good api design.
>
> Regards,
>
> Simon
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Simon,
You should never confuse Java byte code with compiled byte code. I
understand there are a few superfluous byte codes, but in the end the
JVM determines how to compile it to CPU instructions. Unfortunately I am
not aware of what the JVM actually does with unused values. Does it do
escape analysis already?
Regards,
Erik.
Simon Kitching schreef:
> Erik van Oosten schrieb:
>
>> Christopher,
>>
>> As I wrote already on Feb 17:
>> There is another aproach, as taken by http://code.google.com/p/log5j/.
>> It is
>> a wrapper around log4j. I wish they had made it for SLF4J!
>>
>> I am still waiting for someone to this for SLF4J. It should not be hard. I
>> did not yet find the time myself :(
>>
>>
>
> Sigh. Broken broken broken.
>
> Re the "feature" for determining which category to create a logger for,
> see the documentation for Exception.getStackTrace. There is no guarantee
> that valid info about the callstack is available. So this code will work
> fine under unit testing, then may start emitting messages to the wrong
> categories when run in a high-performance environment. That will be fun
> to debug...
>
> Re the printf-style formatting:
>
> log.debug("format str", arg0, arg1, arg2);
>
> is exactly equivalent to:
>
> push "format str" onto stack
> tmp = new Object[3];
> tmp[0] = arg0;
> tmp[1] = arg1;
> tmp[2] = arg2;
> push tmp onto stack
> invoke log.debug
> (and of course garbage-collect the tmp object later..)
>
> So in practice, for good performance you need
> if (log.isDebugEnabled())
> around each call anyway. In which case, the printf-style stuff gives no
> performance benefits at all; if something is going to be logged then the
> formatting is nowhere near the bottleneck step.
>
> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
> slightly better, as it avoids the "new Object[]" call. But for best
> performance, isDebugEnabled should be used anyway.
>
> Regards,
> Simon
>
> ___
> user mailing list
> user@slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
>
--
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Christopher, As I wrote already on Feb 17: There is another aproach, as taken by http://code.google.com/p/log5j/. It is a wrapper around log4j. I wish they had made it for SLF4J! I am still waiting for someone to this for SLF4J. It should not be hard. I did not yet find the time myself :( Regards, Erik. [EMAIL PROTECTED] wrote: > > Ceki, > > I do understand your reasoning, and thank you for your quick response. > > -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] SLF4J - Java 5 version ?
Ceki, There is another aproach, as taken by http://code.google.com/p/log5j/. It is a wrapper around log4j. I wish they had made it for SLF4J! Regards, Erik. Ceki Gulcu-2 wrote: > > In short, do not expect any changes to the org.slf4j.Logger interface, > except > maybe changes in indentation or comments. I am afraid the whole deal is by > now > cast in stone, with the key thrown to the bottom of an unnamed ocean. > > Chris wrote: >> Are there any plans on making a java 5 version of SLF4j (particularly to >> make >> use of varargs)? > -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/SLF4J---Java-5-version---tp15043595p15532493.html Sent from the Slf4J - user mailing list archive at Nabble.com. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] [ANN] JCL to Slf4j migration in a Maven environment
Hello slf4j-ers, I took no-commons-logging to the next level and called it Version 99 Does Not Exist. http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html Have fun! Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/ ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] [ANN] JCL to Slf4j migration in a Maven environment
Hi Ceki, Hopefully it will not be necessary in 5 years :) But, yes I want to keep it around for at least 5 years. I host it at home together with another site which needs to be up for at least 5 years. The hostname is a free DNS service from http://www.no-ip.com/, which proved to be very reliable in the past. My uplink is no so wide, but within a couple of months it will go to 10Mbit/s. Only when the repository becomes so popular that the other site is starving for bandwidth I will have to shut it down (or find another hosting party). If you want absolute certainty, you can now also download the complete repository from http://no-commons-logging.zapto.org/. Regards, Erik. Ceki Gulcu-2 wrote: > > Hi Erik, > > Thank you for sharing this nifty hack. Do you think the no-commons-logging > repository at http://no-commons-logging.zapto.org/mvn2/ can stand the test > of > time? How likely it is to still be there in 5 years? > > Cheers, > > > -- > Ceki Gülcü > -- View this message in context: http://www.nabble.com/-ANN--JCL-to-Slf4j-migration-in-a-Maven-environment-tf4109103.html#a11705974 Sent from the Slf4J - user mailing list archive at Nabble.com. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
[slf4j-user] [ANN] JCL to Slf4j migration in a Maven environment
Hi, I wrote my own version of a commons-logging release to fool Maven and completely exclude JCL from my application. Read about the why and how on my blog: http://day-to-day-stuff.blogspot.com/2007/07/no-more-commons-logging.html Regards, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://www.day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/-ANN--JCL-to-Slf4j-migration-in-a-Maven-environment-tf4109103.html#a11685030 Sent from the Slf4J - user mailing list archive at Nabble.com. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
