Spring Boot on Open Liberty - "IllegalArgumentException: Could not resolve placeholder" substituting "LOG_DIR" env var value in application.properties

Question

I have Spring Boot API that I run on Liberty or OpenLiberty server.

In Liberty server.env file I have settings for logging like:

log_dir=C:\mydir

log_level=INFO

Then in my application.properties file, I have setting like:

logging.file.name=${log_dir}

logging.level.org.springframework=${log_level}

I would expect that when the application starts, the log_dir and log_level will be resolved successfully.

However, instead I get error IllegalArgumentException: Could not resolve placeholder 'log_dir' in '${log_dir}'.

Interestingly, it only happens on log_dir but not on log_level.

The only way to resolve it I found is to hardcode the setting for log_dir so in my application.properties I hardcode it like logging.file.name=C:\mydir instead of logging.file.name=${log_dir}.

Note that I do not have to hardcode value for log_level and it gets resolved just fine.

But that of course is not the good solution.

ADDITIONAL INFO

I am setting log_dir... in server.env since this is our requirement and the app is deployed to different environments where each may log files at different level and locations. Beside, some of the information, we dont want to share in code repository but keep safe on server side.

I do not use liberty-maven-plugin.

I do use spring-boot-maven-plugin and it is set as:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <!-- to expose build info in actuator/info -->
        <execution>
            <goals>
                <goal>build-info</goal>
            </goals>
        </execution>
    </executions>
</plugin>

I am packaging the app as a war file, so in my pom.xml, I have:

<packaging>war</packaging>

My Liberty server.xml uses following features:

  <featureManager>
    <feature>javaee-8.0</feature>
    <feature>microProfile-3.3</feature>
    <feature>jndi-1.0</feature>
    <feature>localConnector-1.0</feature>
    <feature>jca-1.7</feature>
    <feature>jdbc-4.2</feature>
    <feature>springBoot-2.0</feature>
    <feature>servlet-4.0</feature>
    <feature>adminCenter-1.0</feature>
  </featureManager>

UPDATE

More interesting finding. Depending on how do I call the "log_dir" variable in server.env, I get following results:

• log_dir=C:/me/myapi.log - I get problem described above

  log.dir=C:/me/myapi.log - It works as expected

  logDir=C:/me/myapi.log - It works as expected

I am not sure why is Spring Boot deployed on Liberty having issues resolving log_dir but no issues resolving log_level?

Or why is Spring Boot deployed on Liberty having issues resolving log_dir but no issue resolving log.dir or logDir?

Answer 1

Workaround Liberty's unsetting of LOG_DIR by enabling server.env variable expansion

The LOG_DIR environment variable is special to Liberty. The Liberty 'server' script, after reading the value and storing it in yet another variable, unsets the environment variable as it launches the Liberty server JVM process.

In order to not repeat yourself, and specify the location in a single place, so this value can both:

• be used as the LOG_DIR value, to configure the location of Liberty logs, AND
• be used as a normal environment variable, e.g. referenced in Liberty server.xml config, or in this case referenced within Spring Boot application.properties

You can simply write your server env like:

server.env (Windows)

LOG_DIR=C:\mydir
liberty_log_dir=!LOG_DIR!

server.env (Unix)

# enable_variable_expansion
LOG_DIR=/c/mydir
liberty_log_dir=${LOG_DIR}

and in both cases you can reference from, e.g. SpringBoot application.properties via:

logging.file.name=${liberty_log_dir}

NOTES

1. The Unix-style support was added to Open Liberty version 22.0.0.1
2. I switched 'log_dir' from the original question to 'LOG_DIR', the env var Liberty is looking for. I'd recommend against the use of 'log_dir' on Windows. In most contexts this will be one and the same as 'LOG_DIR' since Windows env variables are case-insensitive, but even so can still be confusing, e.g. in Unix environments on Windows, and even just generally confusing.

Answer 2

As strange as it sounds I found that if I call the variable:

• logdir=C:/logs/myapi.log >>>> WORKS FINE
• log.dir=C:/logs/myapi.log >>>> WORKS FINE
• log_dir=C:/logs/myapi.log >>>> FAILS with IllegalArgumentException: Could not resolve placeholder 'log_dir' in value "${log_dir}
• MYAPI_log_dir=C:/logs/myapi.log >>>> FAILS with IllegalArgumentException: Could not resolve placeholder 'MYAPI_log_dir' in value "${MYAPI_log_dir}

As we have discovered previously issuew with Liberty and use of "." in variable names such as log.dir, I decided to use logdir instead of log_dir or log.dir which is working as expected.

Thanks to everyone on your comments.