The version of Apache log4j used by SoundHelix.

[[ 🗃 ^aEp6o apache-log4j ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/aEp6o

SSH: git clone USERNAME@vervis.peers.community:aEp6o

Branches

Tags

v_1_1b5 :: contribs / JimMoore /

mail-2001-03-13T0646


Copied from
http://www.mail-archive.com/log4j-user@jakarta.apache.org/msg00445.html

--------------------------------------------------------------------------------
RE: diverting System.stderr/stdout into log4j
--------------------------------------------------------------------------------

From: Michael Smith 
Subject: RE: diverting System.stderr/stdout into log4j 
Date: Tue, 13 Mar 2001 06:46:04 -0800 

--------------------------------------------------------------------------------

There is another way!

In LogLog, completely ignore System.err.  Instead, use the following to get
the standard error stream:

PrintStream err =
  new PrintStream(new FileOutputStream(FileDescriptor.err));

When you use System.setErr, it changes System.err, but not
FileDescriptor.err, which maintains a descriptor for the original error
stream.

michael

For a sample program to test this, see below:

import java.io.*;

public class Stderr {

  public static void main(String[] args) {

    // create a print stream to represent a redirect
    PrintStream nonStandardErr = 
      new PrintStream(new ByteArrayOutputStream());
    
    // Redirect standard out and standard err
    System.setOut(nonStandardErr);
    System.setErr(nonStandardErr);
    
    // attempt to print something
    System.err.println("You should *not* see this on the console!");
	
    // the stuff that would appear in LogLog
    PrintStream logLogOut = 
      new PrintStream(new FileOutputStream(FileDescriptor.err));
    
    // attempt to print something
    logLogOut.println("You *should* see this on the console!");
  }
}



> -----Original Message-----
> From: Ceki G�lc� [mailto:cgu@qos.ch]
> Sent: Monday, March 12, 2001 7:18 PM
> To: LOG4J Users Mailing List
> Subject: RE: diverting System.stderr/stdout into log4j
>
>
>
> Hate to follow up on myself, but the System.setErr method
> reassigns the System.err variable. This can be deduced without
> experimentation because the user calls the System.err variable
> directly to print to the console, whatever it might be. Thus, the
> reference itself must change to allow the System.err variable to
> point to the new target stream.
>
> The funny part is that the err variable is declared 'public
> final' in the JDK source code. The setErr method makes a call to
> setErr0 which is declared as being 'native'. It looks like the
> native part is circumventing the JDK restrictions. I find this
> quite entertaining. Ceki
>
> At 00:58 13.03.2001 +0100, Ceki G�lc� wrote:
>
> >Running the risk of disappointing you here, although not full of
> bugs, log4j is not bug-free as bugs creep out regularly. They
> just get corrected quickly before many people are affected by them.
> >
> >The PrintStream se = System.err; LogLog.setPrintStream(see);
> combination is simple and rather bright. I initially overlooked
> the  PrintStream se = System.err; part, making me think that a
> lot of code needed to be modified to cater  for the redirected
> console case. The remedy looked worse than the illness. My fears
> are largely unfounded and the solution should work quite well if
> one is careful.
> >
> >Regards, Ceki
> >
> >ps: I wonder if System.err always refers to the real STDERR or
> if really gets reassigned with the setErr call. It's  easy to find out...
> >
> >At 23:20 12.03.2001 +0000, Joseph Panico wrote:
> >>Of course log4j is completely bug free, but that doesn't
> preclude user error. For instance, I neglected to add appenders
> in my config file (actually I intentionally left them out,
> thinking that would simply turn off logging) and then log4j went
> into an infinite loop. The setPrintStream makes sense to me.
> >>
> >>joe
> >>
> >>
> >>>From: Jim Moore <jim.moore@veritas.com>
> >>>Reply-To: "LOG4J Users Mailing List" <log4j-user@jakarta.apache.org>
> >>>To: 'LOG4J Users Mailing List' <log4j-user@jakarta.apache.org>
> >>>Subject: RE: diverting System.stderr/stdout into log4j
> >>>Date: Mon, 12 Mar 2001 18:10:37 -0500
> >>>
> >>>It doesn't.  I haven't worried about it, since log4j doesn't
> contain any
> >>>bugs and therefore it would never happen... :)
> >>>
> >>>Probably the best way to handle it is to add a
> >>>LogLog.setPrintStream(PrintStream) method, so you can do
> something like:
> >>>
> >>>// remember STDERR
> >>>PrintStream se = System.err;
> >>>
> >>>// make sure everything sent to System.err is logged
> >>>System.setErr(new PrintStream(new
> LoggingOutputStream(Category.getRoot(),
> >>>              Priority.WARN), true));
> >>>
> >>>// make sure everything sent to System.out is also logged
> >>>System.setOut(new PrintStream(new
> LoggingOutputStream(Category.getRoot(),
> >>>              Priority.INFO), true));
> >>>
> >>>// prevent infinate recursion in LogLog
> >>>LogLog.setPrintStream(se);
> >>>
> >>>
> >>>I can't think of any other way to do it in the current version besides
> >>>getting extremely kludgey by checking the stack to see if it's
> being called
> >>>from LogLog and logging out the the "real" STDERR then in the
> >>>LoggingOutputStream.  It can be done on the theory that LogLog
> wouldn't be
> >>>called very often, but still...
> >>>
> >>>-Jim Moore
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Ceki G�lc� [mailto:cgu@qos.ch]
> >>>Sent: Monday, March 12, 2001 5:15 PM
> >>>To: LOG4J Users Mailing List
> >>>Subject: RE: diverting System.stderr/stdout into log4j
> >>>
> >>>
> >>>Jim, Joseph,
> >>>
> >>>Here is a link containing Jim's code:
> >>>
> >>>http://marc.theaimsgroup.com/?l=log4j-user&m=98097669218571&w=2
> >>>
> >>>How does this code handle the infinite recursion problem mentioned by
> >>>Joseph? Ceki
> >>>
> >>>At 17:03 12.03.2001 -0500, Jim Moore wrote:
> >>>>Go to the mailing list archives (theAimsGroup.com is the
> best) and search
> >>>>for the thread with the subject of "Capturing System.err"
> >>>>
> >>>>-Jim Moore
> >>>>"I think so, Brain; but if we gave peas a chance, won't the
> lima beans get
> >>>>jealous?" - Pinky
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Joseph Panico [mailto:joe_panico@hotmail.com]
> >>>>Sent: Monday, March 12, 2001 4:43 PM
> >>>>To: log4j-user@jakarta.apache.org
> >>>>Subject: diverting System.stderr/stdout into log4j
> >>>>
> >>>>
> >>>>Folks,
> >>>>
> >>>>We use a number of third-party packages that do
> stderr.print... at various
> >>>>random places in their code. I'm finding it quite useful to
> divert these
> >>>>messages into our log4j heirarchy. I do this by replacing
> stderr/stdout
> >>>with
> >>>>
> >>>>my own PrintStreams that log the lines to a special log4j
> Category-- as
> >>>>suggested on this list a while back. The only
> fly-in-the-ointment with this
> >>>
> >>>>scheme is LogLog. If there is a problem with log4j such that
> it cannot log
> >>>>for some reason, then log4j internals use LogLog to attempt
> to print an
> >>>>error message. This obviously leads to an infinite recursion.
> Has anyone
> >>>>else been bothered by this? Would it make sense to add
> interface to LogLog
> >>>>which would set the PrintStream it uses to log its error messages to?
> >>>>
> >>>>thanks for any ideas
> >>>>
> >>>>joe
[See repo JSON]