Actually I just realized that I have 2 sys: variables and that the first
is in fact resolving. The files do appear in the directory that
sys:catalina.home should resolve to (and appear elsewhere when I don't
use sys:catalina.home).
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.
So I'll add my previous comments to the issue.
On 8/28/2013 12:13 PM, Eric Schwarzenbach wrote:
Remko:
I've created issue LOG4J2-378 for this as you requested. I did not
include my comments about suspecting ServletContextListener
contextInitialized method ordering to be relevant since you replied
that it was string substitution issue in the FastFile appender.
However you did not reply to my question of why that would produce
different behavior on two different systems, so I'm still unclear
whether contextInitialized ordering is relevant.
Eric
On 8/26/2013 11:47 PM, Eric Schwarzenbach wrote:
On 8/26/2013 7:48 PM, Remko Popma wrote:
Looks like a string substitution issue in the FastFile appender
(renamed to
RandomAccessFile appender in the next release, btw, so you'll need to
change your config when you upgrade).
Why would that behave differently on one server vs another?
>
Can you file a JIRA ticket for this?
Sure.
Thanks,
Remko
On Tuesday, August 27, 2013, Eric Schwarzenbach wrote:
I'm using log4j 2.0-beta8 in a webapp, and running it under Tomcat.
I'm setting a system property in my apps ServletContextListener,
and using
that system property in my log4j2.xml file, like so:
<appender type="FastFile" name="File" fileName="${sys:catalina.home}**
/logs/${sys:application-name}.**log">
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 (also tomcat 7, though a slightly
different version) does not create a ${sys." file and instead
creates a log
file with the intended application-name.
What I think must be happening is that my app's ServletContextListener
contextInitialized method is getting called before
Log4jServletContextListener's on the server, but that they are getting
called in the opposite order on my local machine. 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 the 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 the 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
