logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Soutter" <ge...@molten.com.au>
Subject RE: FYI/PATCH: Log4j bug masks part of Orion's stack traces
Date Wed, 27 Mar 2002 01:01:53 GMT
Hi Ceki,

> >1) If VectorWriter doesn't form a complete PrintWriter, it 
> is clearly 
> >broken. There are other applications apart from Orion out there that 
> >implement printStackTrace, and they may legally use _any_ method of 
> >PrintWriter. We are in danger of standing by while the house 
> burns down 
> >if we ignore this fact. ;-) Hmmm. If you documented that 
> log4j does not 
> >support applications which override printStackTrace(), this 
> may be OK. 
> >But, are you willing to do this?
> 
> VectorWriter is broken not because it does not implement a 
> complete PrintWriter. This is actually apparent from your 
> next example. Read on.

VectorWriter is broken because it violates the contract for PrintWriter
- it _throws away_ valid stack trace info! 

No amount of talking around it will change that fact.

> >2) If VectorWriter simply adds anything passed to a print(*) 
> method to 
> >the Vector, it is clearly broken. For example, Orion passes multiple 
> >lines delimited by /r/n into print(String). If you add that to the 
> >vector as a single entry, it will break the (implied, since 
> there is no
> >Javadoc) contract of ThrowableInformation.getThrowableStrRep() which 
> >says that each String in the Array contains a single line of stack 
> >trace. And, this will then cause formatting problems for any 
> Appenders 
> >which rely on this when they are trying to format the stack trace.
> 
> As your example so clearly demonstrates, VectorWriter is 
> broken because there is no formal specification on the format 
> of stack traces as generated by Exceptions, at least not 
> until JDK 1.4. Since there is no such spec, there cannot be a 
> specification on how the Exception.ptintStackTrace method 
> should be implemented.

Nope. Two wrongs don't make a right. See below.

> So although there is no good reason for Orion to generate two 
> lines per print(String) call, it could certainly do that. 
> That has nothing to do with VectorWriter not being a complete 
> PrintWriter 

Yes it does! I called methods which threw away my data. The "fix" still
has that problem, just for some of the other methods. I can write a
printStackTrace() which calls print(Integer) and log4j will _throw it
away_. How is that not a bug?

> but it has everything to do with the imprecise 
> definition (or lack thereof) of how the VectorWriter will be 
> invoked by the Exception.
> 
> Agree so far?

Obviously not. Although I take your point that what is written to
printStackTrace is not formally defined.

> Log4j still supports JDK 1.1. There is no intention to jump 
> to or require 1.4 in the near future.

I did not suggest you _require_ 1.4. I was suggesting log4j include
support for 1.4 features, and I assumed you would figure out that meant
providing a fall back for <= 1.3. Obviously requiring 1.4 would be a bad
move.

> As for the slow but steady solution, it seems to circumvent 
> the problem of the Exception.ptintStackTrace implementation 
> (i.e. it's interaction with VectorWriter ).  Are we sure it 
> will work on Mac OS? On ThisOrThat OS?

Well, considering I haven't tested it, probably not. My code was meant
as an _example_. Also, using line.separator is obviously open to
problems if you pass log events from one machine to another. That's why
I put in \r\n. 

If you want to implement a proper fix, seems like you have two options.

1) If, as you seem to believe from what you say above, you do not
believe it is possible to parse a stack trace in general, then give up
on providing access to the individual lines of a stack trace. In this
case, you need to change ThrowableInfomation.getThrowableStrRep() to
return a String rather than String[] and modify all the classes that
depend on it. Course that will break a lot of peoples code... mucky...

2) If it is possible to parse a stack trace in general, figure out a way
to turn full access to _all_ methods of a PrintWriter into an array of
Strings (one for each line of the trace), on multiple platforms, without
throwing away any data provided to the PrintWriter, and without allowing
individual strings to contain line endings.

> Thanks to you, we have identified a problem with log4j 
> interacting with Orion. We have a fix.  Can you please verify 
> that it works? I would greatly appreciate that. Ceki

You agreed VectorWriter is broken, and it still has the two bugs I
already mentioned. So, it's not a _fix_, it's an Orion-specific _hack_.
Are you sure you want me to spend time testing this hack? I would have
thought you would want to discover a better solution...

Cheers,

Geoff


--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message