[
https://issues.apache.org/jira/browse/LOG4J2-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876216#comment-16876216
]
Carter Kozak commented on LOG4J2-2648:
--------------------------------------
We recommend installing the log4j-jul LogManager as described here:
[https://logging.apache.org/log4j/2.0/log4j-jul/index.html] then using JUL via
Logger.getLogger(MyApplication.class). Is that infeasible or undesirable in
this case?
A log4j2-specific jersey feature could cut out a lot of overhead compared to
the JUL based implementation, but that would be a bit more involved to
implement.
> Public Log4j Core implementation of the JUL Logger class.
> ---------------------------------------------------------
>
> Key: LOG4J2-2648
> URL: https://issues.apache.org/jira/browse/LOG4J2-2648
> Project: Log4j 2
> Issue Type: Improvement
> Components: JUL adapter
> Reporter: Jure Skelin
> Priority: Major
>
> In Glassfish I would like to do something like this:
> {code}
> public class MyApplication extends ResourceConfig {
> private static final Logger log =
> LogManager.getLogger(MyApplication.class);
> public MigrationApplication() {
> register(new LoggingFeature(new CoreLogger(log)));
> }
> }
> {code}
> {{java.util.logging.Logger}} is already implemented by the
> {{org.apache.logging.log4j.jul.CoreLogger}},
> +but the constructor is package private+.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
