logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Brouwer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-547) Update LoggerStream API
Date Sun, 23 Mar 2014 02:45:44 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944312#comment-13944312
] 

Bruce Brouwer commented on LOG4J2-547:
--------------------------------------

It was definitely a good call to write these tests. I'm running into all kinds of trouble.
The various InputStream and Reader tests were easy to fix, but I'm struggling to see what
should be done with PrintStream. Check out this call stack:

{code}
LoggerPrintStream.write(byte[], int, int) line: 113	
StreamEncoder.writeBytes() line: 221 [local variables unavailable]	
StreamEncoder.implFlushBuffer() line: 291 [local variables unavailable]	
StreamEncoder.flushBuffer() line: 104 [local variables unavailable]	
OutputStreamWriter.flushBuffer() line: 185 [local variables unavailable]	
LoggerPrintStream(PrintStream).write(char[]) line: 505	
LoggerPrintStream(PrintStream).print(char[]) line: 653	
LoggerPrintStream.print(char[]) line: 158	
LoggerPrintStream(PrintStream).println(char[]) line: 792	
LoggerPrintStream.println(char[]) line: 208	
LoggerPrintStreamCallerInfoTest.print_chararray() line: 74	
{code}

The FQCN logic trips up pretty quickly as it looks at that top element, which is the FQCN
it is looking for, so it return the next item down in the call stack, which is {{sun.nio.cs.StreamEncoder}}.
The only thing I can think of to make this work is to go back to the way this was before I
started messing around with this and LoggerPrintStream simply delegates to another PrintStream.

Should this delegate mechanism be what we use for all of these streams?

> Update LoggerStream API
> -----------------------
>
>                 Key: LOG4J2-547
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-547
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-rc1
>            Reporter: Matt Sicker
>            Assignee: Ralph Goers
>             Fix For: 2.0
>
>         Attachments: 0001-PrintStream-API-update.patch, log4j2-547-bbrouwer.patch, log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a little while
ago. The main thing I'd like to do is extract an interface from it, rename the default implementation
to SimpleLoggerStream (part of the SimpleLogger stuff), and allow log4j implementations to
specify a different implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream methods to be.
Right now, it's in Logger, but really, it could be in LoggerContext instead. I don't think
I should be required to get a Logger just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This would be so
much easier to design!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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


Mime
View raw message