 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.


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

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

From: Jim Moore 
Subject: RE: diverting System.stderr/stdout into log4j 
Date: Mon, 12 Mar 2001 14:54:13 -0800 

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

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

I hope to see you at my ApacheCon 2001 presentation 
entitled "Log4j, A Logging Package for Java".

See http://ApacheCon.Com/2001/US/ for more details.

----
Ceki Gülcü          Web:   http://qos.ch     
av. de Rumine 5     email: cgu@qos.ch (preferred)
CH-1005 Lausanne           ceki_gulcu@yahoo.com
Switzerland         Tel: ++41 21 351 23 15

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


