[jira] [Commented] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API
[ https://issues.apache.org/jira/browse/LOG4J2-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264865#comment-16264865 ] Raman Gupta commented on LOG4J2-1705: - [~garydgregory] [~jvz] I've updated my repo at https://github.com/rocketraman/logging-log4j-kotlin. Its in pretty decent shape now I think, except location-aware logging line numbers are totally messed up. I believe this is currently a limitation of `inline` functions in Kotlin -- there currently doesn't seem to be a way to get location info for Kotlin inline functions without inspecting the stack, however this is a very slow operation. I think we should consider publishing the module as-is, with the known limitation that location info works at the file level, but not at the line level. > Kotlin wrapper for Log4j 2 API > -- > > Key: LOG4J2-1705 > URL: https://issues.apache.org/jira/browse/LOG4J2-1705 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Raman Gupta > > Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 > API that makes use of Kotlin features like delegates and string interpolation. > If there is interest in this, I'd like to contribute a patch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-1606) log4j-web deinitalizes the Logger too early if listeners defined in web.xml use it
[
https://issues.apache.org/jira/browse/LOG4J2-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264840#comment-16264840
]
Robert Turner edited comment on LOG4J2-1606 at 11/23/17 11:21 PM:
--
[~epavel] Yeah, that was roughly my approach, but hadn't got around to figuring
out how I would achieve your 4th bullet (don't create loggers before
{{contextInitialized}} is called) in our system. What approach did you use to
do this (as the traditional method of creating the loggers is from static class
members initialization, which is hard to control)?
was (Author: rtur...@e-djuster.com):
[~epavel] Yeah, that was roughly my approach, but hadn't got around to figuring
out how I would achieve your 4th bullet (don't create loggers before
contextInitialize is called) in our system. What approach did you use to do
this (as the traditional method of creating the loggers is from static class
members initialization, which is hard to control)?
> log4j-web deinitalizes the Logger too early if listeners defined in web.xml
> use it
> ---
>
> Key: LOG4J2-1606
> URL: https://issues.apache.org/jira/browse/LOG4J2-1606
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.6.2
> Environment: Java8, Linux/Mac, Tomcat
>Reporter: Lukas Vogel
>
> We use log4j in a Apache Tomcat environment.
> In the web.xml file we define a custom ServerStartup listener that
> initializes the DB etc and logs both in contextInitialized and
> contextDestroyed.
> If we use the log4j-web package the class Log4jServletContainerInitializer
> initializes the logger and adds a Log4jServletContextListener to the
> ServletContext. Since this listener is added after our listener the method
> Log4jServletContextListener#contextDestroyed is called before our listener's
> contextDestroyed method. Thus the Logger is de-initialized too early.
> We could disable auto initialization and initialize the logger ourselves but
> then doing it in the listener is too late since the WebService-framework
> (Metro glassfish) initializes the webservice endpoints before the listener.
> Since we use static logger variables in those webservice classes this would
> trigger the message "StatusLogger no log4j configuration found..." because
> the logger was not yet initialized.
> One possible patch we see is that we make an option to manually add the
> Log4jServletContextListener:
> In Log4jServletContainerInitializer we would put an "if (! Manually added)"
> around the call "servletContext.addListener(new
> Log4jServletContextListener());" and then we could manually add it to the
> listeners in web.xml
> If you have any other suggestions I would be glad to hear them.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1606) log4j-web deinitalizes the Logger too early if listeners defined in web.xml use it
[ https://issues.apache.org/jira/browse/LOG4J2-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264840#comment-16264840 ] Robert Turner commented on LOG4J2-1606: --- [~epavel] Yeah, that was roughly my approach, but hadn't got around to figuring out how I would achieve your 4th bullet (don't create loggers before contextInitialize is called) in our system. What approach did you use to do this (as the traditional method of creating the loggers is from static class members initialization, which is hard to control)? > log4j-web deinitalizes the Logger too early if listeners defined in web.xml > use it > --- > > Key: LOG4J2-1606 > URL: https://issues.apache.org/jira/browse/LOG4J2-1606 > Project: Log4j 2 > Issue Type: Bug > Components: Web/Servlet >Affects Versions: 2.6.2 > Environment: Java8, Linux/Mac, Tomcat >Reporter: Lukas Vogel > > We use log4j in a Apache Tomcat environment. > In the web.xml file we define a custom ServerStartup listener that > initializes the DB etc and logs both in contextInitialized and > contextDestroyed. > If we use the log4j-web package the class Log4jServletContainerInitializer > initializes the logger and adds a Log4jServletContextListener to the > ServletContext. Since this listener is added after our listener the method > Log4jServletContextListener#contextDestroyed is called before our listener's > contextDestroyed method. Thus the Logger is de-initialized too early. > We could disable auto initialization and initialize the logger ourselves but > then doing it in the listener is too late since the WebService-framework > (Metro glassfish) initializes the webservice endpoints before the listener. > Since we use static logger variables in those webservice classes this would > trigger the message "StatusLogger no log4j configuration found..." because > the logger was not yet initialized. > One possible patch we see is that we make an option to manually add the > Log4jServletContextListener: > In Log4jServletContainerInitializer we would put an "if (! Manually added)" > around the call "servletContext.addListener(new > Log4jServletContextListener());" and then we could manually add it to the > listeners in web.xml > If you have any other suggestions I would be glad to hear them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
