You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Carter Kozak (JIRA)" <ji...@apache.org> on 2019/07/01 14:09:00 UTC

[jira] [Commented] (LOG4J2-2648) Public Log4j Core implementation of the JUL Logger class.

    [ 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)