Introduction

Using Spring application properties in Logback configuration is a common requirement for environment-specific log paths and patterns. The key detail is that Spring property resolution works with logback-spring.xml, not plain logback.xml. If this file naming rule is missed, property lookups fail silently or fall back to defaults.

logback.xml vs logback-spring.xml

Spring Boot can extend Logback features only when the config file is named logback-spring.xml. That enables tags such as springProperty and profile-specific sections.

Use this file name:

• 'src/main/resources/logback-spring.xml'

Avoid this when you need Spring properties:

• 'src/main/resources/logback.xml'

This naming choice is the first troubleshooting step for unresolved placeholders.

Read Spring Properties in Logback

springProperty maps property values from Spring environment into Logback variables.

1<?xml version="1.0" encoding="UTF-8"?>
2<configuration>
3    <springProperty scope="context" name="appName" source="spring.application.name"/>
4    <springProperty scope="context" name="logDir" source="app.log.dir" defaultValue="logs"/>
5
6    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
7        <file>${logDir}/${appName}.log</file>
8        <encoder>
9            <pattern>%d %-5level [%thread] %logger - %msg%n</pattern>
10        </encoder>
11    </appender>
12
13    <root level="INFO">
14        <appender-ref ref="FILE"/>
15    </root>
16</configuration>

The defaultValue helps keep startup stable when a property is missing.

Example application.properties

Define properties in your Spring config as usual.

spring.application.name=orders-service
app.log.dir=/var/log/orders

At startup, Logback resolves these values through Spring environment.

Profile-Specific Logging Configuration

With logback-spring.xml, you can use profile blocks.

1<springProfile name="dev">
2    <logger name="com.example" level="DEBUG"/>
3</springProfile>
4
5<springProfile name="prod">
6    <logger name="com.example" level="INFO"/>
7</springProfile>

This avoids separate logging files per environment and keeps configuration centralized.

Property Source Precedence

Resolved value depends on Spring property precedence. For example:

• Command-line arguments may override file values.
• Environment variables can override defaults.
• External config files may override bundled config.

When logs write to unexpected location, inspect active property sources first.

Debugging Unresolved Variables

If ${logDir} appears literally in output path or logs do not initialize:

1. Confirm file is named logback-spring.xml.
2. Confirm property key exists.
3. Add fallback default values.
4. Check active profile and external config overrides.

You can also start app with debug flags to inspect property resolution path.

Safer Log Path Design

For container deployments, avoid hardcoding host-specific paths where filesystem write permission is unknown. Use configurable path with default suitable for container runtime.

Also ensure rolling policy is configured to prevent unbounded disk growth.

1<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
2    <fileNamePattern>${logDir}/${appName}.%d{yyyy-MM-dd}.log</fileNamePattern>
3    <maxHistory>14</maxHistory>
4</rollingPolicy>

logging.config Interactions

If your application also sets logging values through command-line flags or external config files, verify how those values interact with Logback placeholders at startup. The final resolved path may differ from what static config review suggests.

A practical check is logging effective values during startup in a bootstrap logger and confirming they match expected environment variables. This reduces confusion when containers inject runtime settings that override local defaults.

Example with Environment Override

You can keep application.properties default and override with environment variable in deployment platforms.

app.log.dir=${APP_LOG_DIR:logs}

Then in deployment:

export APP_LOG_DIR=/var/log/orders

This pattern makes logging location configurable without changing binary artifacts and helps keep one image reusable across environments.

Migration Tip

When moving from older static logback setups, migrate one property at a time and validate output files after each change. Incremental migration prevents broad logging outages caused by one unresolved placeholder.## Common Pitfalls

• Using logback.xml while expecting springProperty to work.
• Missing fallback value and failing startup on absent property.
• Assuming one profile while another is active at runtime.
• Hardcoding log directories that are not writable in containers.
• Ignoring property-source precedence during troubleshooting.

Summary

• Use logback-spring.xml when accessing Spring properties in Logback.
• Resolve values with springProperty and sensible defaults.
• Keep environment behavior consistent with profile-specific blocks.
• Debug unresolved paths by checking file name and property precedence.
• Design log paths and rolling policies for operational safety.