logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Schwarzenbach (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-378) Logging generates file named ${sys on some systems
Date Wed, 28 Aug 2013 17:18:53 GMT

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

Eric Schwarzenbach edited comment on LOG4J2-378 at 8/28/13 5:17 PM:
--------------------------------------------------------------------

What I suspect is happening is that my app's ServletContextListener contextInitialized method
is getting called before Log4jServletContextListener's on the server (where the problem does
not occur), but that they are getting called in the opposite order on my local machine (where
the problem does occur). sys:catalina.home does not depend on my app's ServletContextListener
contextInitialized method being called before Log4jServletContextListener's but sys:application-name,
I believe, does.

The javadoc seems to suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:

1) Is the fact that they get called in different orders on different machines a failure of
(some version / implementation of) Tomcat to call them in the right order? Or a failure of
the log4j code to ensure things are set up so as to guarantee this order? Or is the order
even specified and guarranteeable?

2) Is Log4jServletContextListener's contextInitialized  being called first necessarily desirable?
If Log4jServletContextListener always gets called before the application's context listener,
how is a web application to set up variables for use in the log4j configuration, particularly,
for example (which is what I am doing), to get the webapp's name from the servlet context
path to name the log files? Is there some better way to do this? (Ideally without requiring
configuration to be loaded twice...which is what I ended up happening with logback when I
tried to set it up to do this same thing.)

According to the servlet spec "The Web container registers the listener instances according
to the interfaces they implement and the order in which they appear in the deployment descriptor.
During Web application execution, listeners are invoked in the order of their registration."
Since Log4jServletContextListener doesn't appear in my web.xml, I assume it should call them
"according to the interfaces they implement". I have no idea what that is supposed to mean,
though.






                
      was (Author: ericjs):
    What I suspect is happening is that my app's ServletContextListener contextInitialized
method is getting called before Log4jServletContextListener's on the server (where the problem
does not occur), but that they are getting called in the opposite order on my local machine
(where the problem does occur). sys:catalina.home does not depend on my app's ServletContextListener
contextInitialized method being called before Log4jServletContextListener's but sys:application-name,
I believe, does.

The javadoc seems to suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:

1) Is the fact that they get called in different orders on different machines a failure of
Tomcat to call them in the right order? Or a failure of the log4j code to ensure things are
set up so as to guarantee this order? Or is the order even specified and guarranteeable?

2) Is Log4jServletContextListener's contextInitialized  being called first necessarily desirable?
If Log4jServletContextListener always gets called before the application's context listener,
how is a web application to set up variables for use in the log4j configuration, particularly,
for example (which is what I am doing), to get the webapp's name from the servlet context
path to name the log files? Is there some better way to do this? (Ideally without requiring
configuration to be loaded twice...which is what I ended up happening with logback when I
tried to set it up to do this same thing.)

According to the servlet spec "The Web container registers the listener instances according
to the interfaces they implement and the order in which they appear in the deployment descriptor.
During Web application execution, listeners are invoked in the order of their registration."
Since Log4jServletContextListener doesn't appear in my web.xml, I assume it should call them
"according to the interfaces they implement". I have no idea what that is supposed to mean,
though.






                  
> Logging generates file named ${sys on some systems
> --------------------------------------------------
>
>                 Key: LOG4J2-378
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-378
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.0-beta8
>         Environment: Issues occurs on Win7/64 system under Tomcat 7.0.42 / Oracle JDK
1.7.0_25; fails to occur on RHEL 5.2 system under Tomcat 7.0.26 / Oracle JDK 1.7.0_03
>            Reporter: Eric Schwarzenbach
>
> In a webapp I'm setting a system property in my apps ServletContextListener, and using
that system property in my log4j2.xml file, like so:
> {code}
> <appender type="FastFile" name="File" fileName="${sys:catalina.home}/logs/${sys:application-name}.log">
> {code}
> On my Windows machine, a log file named "${sys." (always 0 bytes) is being created instead
of a log file with the application-name. The same war deployed on one of our linux servers
does not create a ${sys." file and instead creates a log file with the intended application-name.

> I should note that the files DO appear in the directory that sys:catalina.home should
resolve to. They appear elsewhere when I don't use sys:catalina.home so I'm quite sure that
this variable is resolving correctly and it is the sys:application-name which is the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message