[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917561#comment-13917561
]
Matt Sicker edited comment on LOG4J2-547 at 3/2/14 9:16 PM:
------------------------------------------------------------
I'm starting to see two ways this can go: as part of the API, or a separate
module dependent on log4j-api (similar to fluent-hc from HttpComponents). I
like the idea of going the full java.io route for spying and such (which can
help log I/O as well as provide a path for logger-less code to transition to
real loggers).
As for the one root class, of course LogManager should have the API available
to create the streams and reader/writers, but that could easily be delegated
just like how most of the methods in LogManager already delegate to a
LoggerContextFactory.
Edit: if we made a fluent API, it would definitely make sense to put it in its
own module such as fluent-logging or log4j-fluent (more consistent naming there
at least). Fluent APIs are neat, but they're also limited in functionality
(which is the point) and really belong in separate modules. Then again, I'm all
about modules lately, so I might be a bit biased. ;)
was (Author: jvz):
I'm starting to see two ways this can go: as part of the API, or a separate
module dependent on log4j-api (similar to fluent-hc from HttpComponents). I
like the idea of going the full java.io route for spying and such (which can
help log I/O as well as provide a path for logger-less code to transition to
real loggers).
As for the one root class, of course LogManager should have the API available
to create the streams and reader/writers, but that could easily be delegated
just like how most of the methods in LogManager already delegate to a
LoggerContextFactory.
> 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
