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

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

If we were going to put the streaming interface in -core or -api, then I agree 
with Gary that there is no use for another JAR. If, however, we decide this 
streaming API isn't part of the core of log4j (as I am of the opinion), then I 
vote to put that in a -streaming JAR. That would include StreamingLogManager.

I personally don't mind the extra JAR if it requires me to explicitly choose to 
include it for the desired functionality (like slf4j or jcl). I'm a big user of 
Spring and I felt the same way when they broke that up into a whole bunch of 
JARs. Now it just seems like common practice to have smaller, more targeted 
JARs. Sometimes it can be a pain to know which jar has a particular class, but 
[http://search.maven.org] class search makes that easy to figure out. 

Do you think we can gain consensus to just remove it completely until after 2.0 
is released? Maybe some time will help us settle on a direction.

> 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, 
> Add_caller_info_tests.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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to