在web.xml中使用表达式语言（EL）访问JVM变量

Question

I have two web applications running on the same WebSphere 8.5.5 server. The first application is able to use expression language (EL) in the web.xml to access JVM variables like so:

<context-param>
    <param-name>log4jConfigLocation</param-name>
    <param-value>/WEB-INF/config/log4j-${app.env}.xml</param-value>
</context-param>

This allows me to set a JVM variable named app.env on the server that determines which log4j configuration file is used. This variable is set to rad, test, or production according to the environment.

Furthermore, because these applications will run in a clustered environment but log to the same network share, I need to use EL in the log4j configuration file to differentiate the log files. This is achieved using EL in the log4j config files like this:

<appender name="file" class="com.example.util.CustodianDailyRollingFileAppender">
    <param name="maxNumberOfDays" value="10" />
    <param name="compressBackups" value="yes" />
    <param name="File" value="/netshare/logs/${app.serv}_app.log" />
    <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="[%d] %-5p %c - %m%n" />
    </layout>
</appender>

The app.serv JVM variable is set to "1" on the first server in the cluster and "2" on the second, this results in a log file for each server being created named 1_app.log and 2_app.log respectively.

The first application uses Servlets 2.4 and Spring Framework 3.0.4.

In the second application I'm trying to use this same scheme for my log files but, I'm using Servlets 3.0 and not using Spring Framework, instead trying to stick to JEE6. However, the EL is not being evaluated in the web.xml or the log4j configuration files.

If I put EL in the second application's web.xml then log4j throws an exception because it can't find the configuration file at the location defined because the EL hasn't been evaluated:

<context-param>
    <param-name>log4jConfiguration</param-name>
    <param-value>/WEB-INF/log4j2-${app.env}.xml</param-value>
</context-param>

This results in an exception because log4j is looking for log4j2-${app.env}.xml instead of log4j2-rad.xml.

Similarly, if I hard code the config location and attempt to use EL in the log4j2 configuration the EL does not get evaluated and I end up with log file named ${app.serv}_app.log when it should be evaluating the EL and naming the file 1_app.log.

Which brings up my questions:

1) What is the difference between Application 1 and Application 2 that is causing EL in my web.xml and log4j configuration to not be evaluated?

2) How can I make EL work in my web.xml and log4j configuration files in Application 2?

Answer 1

I think I've managed to answer my own questions:

1) What is the difference between Application 1 and Application 2 that is causing EL in my web.xml and log4j configuration to not be evaluated?

The difference was two-fold:

First, Applicaton A was a Spring application making use of the Log4JConfigListener class that comes with Spring. Log4JConfigListener is aa ServletContextListener that basically just helps the Log4j configuration classes to find the configuration files. Additionally, before it does this, it resolves any placeholders used in the Log4J config location context parameter in the web.xml. I was able to reproduce this behavior myself by implementing my own ServletContextListener that did essentially the same thing that Spring does.

Second, Application A was using Log4j 1.2.x and Application B was attempting to use Log4j 2.x. Initially, I thought that Log4j 2.x simply didn't do the same placeholder resolution that Log4j 1.2.x did in it's OptionConverter class. So, I solved this problem by reverting to Log4j 1.2.x. Since, I made the change back to Log4j 1.2.x, I've noticed that there appear to be adapter classes in the log4j-1.2-api-2.x.jar. This jar was NOT present on my classpath for Application B and may have made the difference had they been there. I may investigate this at a later date but, for now, I'm happy to have it working using Log4j 1.2.x.

2) How can I make EL work in my web.xml and log4j configuration files in Application 2?

Question 2 is answered above, with a ServletContextListener that resolves expressions prior to passing the file location to the Log4j configurers and with Log4j 1.2.x instead of Log4j 2.x. Again, I emphasize that Log4j 2.x may have the same behaviors if log4j-1.2-api-2.x.jar is on the classpath but I can't personally verify this at this time.