Re: Class for sending STDERR to log4j
Try something like Level.error or Level.ERROR.
On 2/23/07, Robin Walker <[EMAIL PROTECTED]> wrote:
Hello,
Looking online, I found this neat bit of code and am trying to use it to send
STDERR
to log4j so we can log all System.err using log4j. Trouble is, it requires
both a
Logger and Level to be passed into the constructor and I'm a bit confused with
regards to the "Level".
#1 - I'm not clear on what this could represent besides logger.getLevel(), so it
seems redundant to me. Granted, I am not an experienced log4j user.
#2 - If I do pass in logger.getLevel(), this code snippet errors out because
level
appears to be set to null.
#3 - Instantiating a new org.apache.log4j.Level() object doesn't seem feasible
for
reasons that I don't quite understand but probably are apparent to the more
experienced.
Below is the code snippet. Does anyone have any ideas, or other experiences
trying
to accomplish this sort of thing?
Much thanks,
-Robin
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintStream;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
/**
* 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
* JscLoggingOutputStream(Category.getRoot(),
* Priority.WARN), true));
*
* // make sure everything sent to System.out is also logged
* System.setOut(new PrintStream(new
* JscLoggingOutputStream(Category.getRoot(),
* Priority.INFO), true));
*
*
* @author mailto://[EMAIL PROTECTED]">Jim Moore
* @see Category
*/
//
public class JscLoggingOutputStream extends OutputStream {
static Logger myLogger =
Logger.getLogger(JscLoggingOutputStream.class.getName());
/**
* Used to maintain the contract of [EMAIL PROTECTED] #close()}.
*/
protected boolean hasBeenClosed = false;
/**
* The internal buffer where data is stored.
*/
protected 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.
*/
protected 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.
*/
protected Logger logger;
/**
* The priority to use when writing to the Category.
*/
protected Level level;
private JscLoggingOutputStream() {
// illegal
}
/**
* Creates the JscLoggingOutputStream 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 JscLoggingOutputStream(Logger log, Level level)
throws IllegalArgumentException {
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
if (log == null) {
System.out.println("error 1");
throw new IllegalArgumentException("cat == null");
}
if (level == null) {
System.out.println("error 2");
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 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
Class for sending STDERR to log4j
Hello,
Looking online, I found this neat bit of code and am trying to use it to send
STDERR
to log4j so we can log all System.err using log4j. Trouble is, it requires
both a
Logger and Level to be passed into the constructor and I'm a bit confused with
regards to the "Level".
#1 - I'm not clear on what this could represent besides logger.getLevel(), so it
seems redundant to me. Granted, I am not an experienced log4j user.
#2 - If I do pass in logger.getLevel(), this code snippet errors out because
level
appears to be set to null.
#3 - Instantiating a new org.apache.log4j.Level() object doesn't seem feasible
for
reasons that I don't quite understand but probably are apparent to the more
experienced.
Below is the code snippet. Does anyone have any ideas, or other experiences
trying
to accomplish this sort of thing?
Much thanks,
-Robin
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintStream;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
/**
* 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
* JscLoggingOutputStream(Category.getRoot(),
* Priority.WARN), true));
*
* // make sure everything sent to System.out is also logged
* System.setOut(new PrintStream(new
* JscLoggingOutputStream(Category.getRoot(),
* Priority.INFO), true));
*
*
* @author mailto://[EMAIL PROTECTED]">Jim Moore
* @see Category
*/
//
public class JscLoggingOutputStream extends OutputStream {
static Logger myLogger =
Logger.getLogger(JscLoggingOutputStream.class.getName());
/**
* Used to maintain the contract of [EMAIL PROTECTED] #close()}.
*/
protected boolean hasBeenClosed = false;
/**
* The internal buffer where data is stored.
*/
protected 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.
*/
protected 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.
*/
protected Logger logger;
/**
* The priority to use when writing to the Category.
*/
protected Level level;
private JscLoggingOutputStream() {
// illegal
}
/**
* Creates the JscLoggingOutputStream 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 JscLoggingOutputStream(Logger log, Level level)
throws IllegalArgumentException {
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
System.out.println("we're in here...");
if (log == null) {
System.out.println("error 1");
throw new IllegalArgumentException("cat == null");
}
if (level == null) {
System.out.println("error 2");
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 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 co
RE: Root logger appenders in log4j 1.3
Hi, Yes, perhaps there are reasons to change it, but then help me understand how to configure log4j in the following scenario. We provide a log4.xml within our app's jar so that our application logs messages during startup (say to file1 and console). We also let the users specify a separate (external to our jars) log4j xml file to configure how the app should log messages after the startup phase (say file2 and console). With 1.2, this could be done by attaching the corresponding 2 appenders to the element in each of the config files. How would I achieve the same behavior in 1.3? At this point, both file1 and file2 are growing, and every message is showing twice on the console. Thank you Sergiu -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: February 23, 2007 2:49 PM To: Log4J Users List; Log4J Users List Subject: Re: Root logger appenders in log4j 1.3 Hello Jake et al, The complete log4j manual is correct as far as log4j 1.0, 1.1, 1.2 are concerned. However, in log4j 1.3 the behavior was changed because: 1) it is not what a user would expect without reading the docs (surprise element) 2) very few people seemed to take advantage of the "pre 1.3" behaviour** ** The "pre 1.3" behavior was intended to support partial config files The different behaviors should be transparent to the user as long as she does not do partial configs. I hope this helps, At 06:15 AM 2/23/2007, Jacob Kjome wrote: >That's an interesting quote. I have to admit that I haven't read the >Log4j manual and that's new to me. In Log4j, reconfigurations are >genrally not destructive. They are cumulative. It sounds like the manual >is claiming that the ROOT logger is an exception to the rule. > >Have you tried this with Log4j-1.2.xx? Do you get the same results or do >you get the behavior described in the manual? It's certainly possible >that this contract was broken in 1.3. > >Ceki, Curt, anyone, can you shed any light on this topic? What's the >expected behavior? Is the manual right, wrong, or just being misinterpreted? > > >Jake -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - 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: Root logger appenders in log4j 1.3
Hello Jake et al, The complete log4j manual is correct as far as log4j 1.0, 1.1, 1.2 are concerned. However, in log4j 1.3 the behavior was changed because: 1) it is not what a user would expect without reading the docs (surprise element) 2) very few people seemed to take advantage of the "pre 1.3" behaviour** ** The "pre 1.3" behavior was intended to support partial config files The different behaviors should be transparent to the user as long as she does not do partial configs. I hope this helps, At 06:15 AM 2/23/2007, Jacob Kjome wrote: That's an interesting quote. I have to admit that I haven't read the Log4j manual and that's new to me. In Log4j, reconfigurations are genrally not destructive. They are cumulative. It sounds like the manual is claiming that the ROOT logger is an exception to the rule. Have you tried this with Log4j-1.2.xx? Do you get the same results or do you get the behavior described in the manual? It's certainly possible that this contract was broken in 1.3. Ceki, Curt, anyone, can you shed any light on this topic? What's the expected behavior? Is the manual right, wrong, or just being misinterpreted? Jake -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Excluding IP from log without custom filter
At 06:11 PM 2/23/2007, Chris Fellows wrote: Thanks for the fast response. LogBack uses 1.5 jdk and we're not quite ready to upgrade that to 5. Is there a way I can use log4j or commons to accomplish the type of filter I mentioned? Regards, Chris No, log4j not commons logging offer what you are looking for. Although logback is written using JDK 1.5, it ships with jars compatible with jdk 1.4. See also [1]. [1] http://www.qos.ch/pipermail/logback-user/2007-February/000133.html HTH, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No implementation defined for org.apache.commons.logging.LogFactory
Is Log4j.jar at the same level commons-logging.jar? That is, are they in the same classloader? And are you making sure to use commons-logging.jar and not commons-logging-api.jar? Jake Quoting [EMAIL PROTECTED]: > Hi, > > Not sure if this is the correct list for this but will try anyway. > > We hava a java app which throws the following when run as a db2 stored > procedure: > > java.lang.ExceptionInInitializerError > at > org.apache.axis.handlers.BasicHandler.(BasicHandler.java:43) > at org.apache.axis.client.Service.getAxisClient(Service.java:104) > at org.apache.axis.client.Service.(Service.java:113) > at > com.cdyne.ws.EmailVerNoTestEmailLocator.(EmailVerNoTestEmailLocator.java:18) > at > com.cdyne.ws.EmailVerNoTestEmailSoapProxy._initEmailVerNoTestEmailSoapProxy(EmailVerNoTestEmailSoapProxy.java:13) > at > com.cdyne.ws.EmailVerNoTestEmailSoapProxy.(EmailVerNoTestEmailSoapProxy.java:8) > at PROCEDUR5.PROC5(PROCEDUR5.java:17) > Caused by: org.apache.commons.discovery.DiscoveryException: No > implementation defined for org.apache.commons.logging.LogFactory > > However, what is odd is that if I run the app using the command line java > command in the same server with exactly the same classpath > as db2 has then everything works fine. > > I suspect it may have something to do with logging configuration in which > case db2 is doing something (or not doing something) that > creates a problem. > > Anyone any ideas what could be causing the exception ? > > Thanks in advance, > > John. > > = > John Enevoldson > > Pulsen Application AB > > Direct: +46 (0)33 17 18 72 > Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Excluding IP from log without custom filter
Thanks for the fast response. LogBack uses 1.5 jdk and we're not quite ready to upgrade that to 5. Is there a way I can use log4j or commons to accomplish the type of filter I mentioned? Regards, Chris - Original Message From: Ceki Gülcü <[EMAIL PROTECTED]> To: Log4J Users List ; log4j-user@logging.apache.org Sent: Thursday, February 22, 2007 4:05:57 PM Subject: Re: Excluding IP from log without custom filter Log4j does not do access logging. For access logs, you should be looking at the logback project. At 10:02 PM 2/22/2007, Chris Fellows wrote: >Hello, Im looking for a way to exclude a particular IP address from my >localhost_access--mm-dd.txt logs in tomcat 5.0. I gather from >searching the mail archives, I could write a custom filter, but is there a >way to do this through configuration instead? It does look like 1.3 offers >this through exclusion filters, but were not quite ready to do a full >upgrade across all our webapps. Example of logged entry to be excluded: >192.168.126.3 - - [22/Feb/2007:11:10:07 -0500] "GET / HTTP/0.9" 200 12248 >"-" "-" Thanks for any help, Chris -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Root logger appenders in log4j 1.3
It is "the Complete Log4j Manual" for as of v1.2.9, Dec, 2004, Page 68, there is " element" bullet at the bottom of the page. Note that it says "Similar to the element, declaring element will have the effect...". So it is not an exception for element. And yes, I tried with v1.2.8, and it seems to do what this quote says. In 1.3, the behavior is different. Regards Sergiu -Original Message- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: February 23, 2007 12:38 AM To: Log4J Users List Subject: Re: Root logger appenders in log4j 1.3 On Feb 22, 2007, at 11:15 PM, Jacob Kjome wrote: > > That's an interesting quote. I have to admit that I haven't read > the Log4j manual and that's new to me. In Log4j, reconfigurations > are genrally not destructive. They are cumulative. It sounds like > the manual is claiming that the ROOT logger is an exception to the > rule. > > Have you tried this with Log4j-1.2.xx? Do you get the same results > or do you get the behavior described in the manual? It's certainly > possible that this contract was broken in 1.3. > > Ceki, Curt, anyone, can you shed any light on this topic? What's > the expected behavior? Is the manual right, wrong, or just being > misinterpreted? > > > Jake > My initial take was the same as yours. The quote from "the manual" sounds incorrect but it is not in context. I assume that they mean Ceki's "The complete log4j manual", but the don't specify precisely what "manual" they are referencing and a detailed reference would be handy. I have an old beat up paperback copy, but didn't buy an electronic edition and the text may have been added in subsequent editions. - 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]
No implementation defined for org.apache.commons.logging.LogFactory
Hi, Not sure if this is the correct list for this but will try anyway. We hava a java app which throws the following when run as a db2 stored procedure: java.lang.ExceptionInInitializerError at org.apache.axis.handlers.BasicHandler.(BasicHandler.java:43) at org.apache.axis.client.Service.getAxisClient(Service.java:104) at org.apache.axis.client.Service.(Service.java:113) at com.cdyne.ws.EmailVerNoTestEmailLocator.(EmailVerNoTestEmailLocator.java:18) at com.cdyne.ws.EmailVerNoTestEmailSoapProxy._initEmailVerNoTestEmailSoapProxy(EmailVerNoTestEmailSoapProxy.java:13) at com.cdyne.ws.EmailVerNoTestEmailSoapProxy.(EmailVerNoTestEmailSoapProxy.java:8) at PROCEDUR5.PROC5(PROCEDUR5.java:17) Caused by: org.apache.commons.discovery.DiscoveryException: No implementation defined for org.apache.commons.logging.LogFactory However, what is odd is that if I run the app using the command line java command in the same server with exactly the same classpath as db2 has then everything works fine. I suspect it may have something to do with logging configuration in which case db2 is doing something (or not doing something) that creates a problem. Anyone any ideas what could be causing the exception ? Thanks in advance, John. = John Enevoldson Pulsen Application AB Direct: +46 (0)33 17 18 72 Email: [EMAIL PROTECTED]
