Introduction

Spring XML can read environment variables, but the cleanest mechanism depends on how your application is already configured. In practice, the usual choices are placeholder resolution with the Spring environment or direct SpEL access through the systemEnvironment map.

Use Property Placeholders in XML

If you already use placeholder resolution, you can inject values with ${...} syntax:

1<beans xmlns="http://www.springframework.org/schema/beans"
2       xmlns:context="http://www.springframework.org/schema/context"
3       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4       xsi:schemaLocation="
5         http://www.springframework.org/schema/beans
6         http://www.springframework.org/schema/beans/spring-beans.xsd
7         http://www.springframework.org/schema/context
8         http://www.springframework.org/schema/context/spring-context.xsd">
9
10    <context:property-placeholder />
11
12    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
13        <property name="url" value="jdbc:postgresql://${DB_HOST}:${DB_PORT}/appdb" />
14        <property name="username" value="${DB_USER}" />
15        <property name="password" value="${DB_PASSWORD}" />
16    </bean>
17</beans>

With a Spring environment configured normally, placeholders can resolve from property sources such as environment variables, system properties, and property files.

This is usually the best option because it keeps the XML concise and looks the same whether the value comes from a file or the environment. It also makes deployment differences easier to audit, because the bean definition stays stable while only the external configuration source changes between environments.

Add Default Values When Needed

If an environment variable may be missing, provide a fallback:

<property name="url" value="jdbc:postgresql://${DB_HOST:localhost}:${DB_PORT:5432}/appdb" />

That prevents the context from failing just because a non-production machine does not define the variable.

Default values are especially useful for local development, test containers, and shared XML config that runs in several environments.

Use SpEL for Explicit Environment Access

If you want to read environment variables directly rather than through placeholder resolution, use Spring Expression Language:

1<bean id="serviceConfig" class="com.example.ServiceConfig">
2    <property name="apiKey" value="#{systemEnvironment['API_KEY']}" />
3    <property name="region" value="#{systemEnvironment['APP_REGION'] ?: 'us-east-1'}" />
4</bean>

This is more explicit about where the value comes from. It is also useful when you want logic such as a fallback expression in the same attribute.

The tradeoff is readability. Heavy use of SpEL can make XML harder to scan than simple placeholders.

Choose One Style Consistently

Both approaches work, but mixing them casually makes configuration harder to reason about. A practical guideline is:

• use ${...} for standard configuration properties
• use SpEL only when you need explicit environment-map access or inline logic

That keeps most bean definitions simple while still leaving an escape hatch for unusual cases.

Environment Variables Versus System Properties

Spring can resolve both environment variables and JVM system properties, but they are not the same thing:

• environment variables come from the OS process environment
• system properties come from JVM startup flags such as -Dname=value

If a deployment pipeline uses one and you code for the other, the placeholders will not resolve as expected. Make sure the runtime convention matches the XML.

Common Pitfalls

The biggest mistake is assuming ${MY_VAR} will resolve automatically without the necessary placeholder configuration in older Spring XML setups. If placeholders are not enabled, Spring treats the value literally.

Another issue is forgetting that environment variables may not exist in every environment. Without a default or a required deployment contract, context startup can fail.

Developers also sometimes confuse environment variables with JVM system properties and spend time debugging the wrong input source.

Finally, do not hide too much logic in XML expressions. If configuration rules become complex, move them into property files, Java config, or a dedicated configuration component.

Summary

• Spring XML can inject environment values through ${...} placeholders or SpEL.
• 'context:property-placeholder is the usual starting point for placeholder-based injection.'
• Use default values for variables that may be absent outside production.
• 'systemEnvironment gives explicit access to OS environment variables in SpEL.'
• Keep the configuration style consistent so the XML stays readable and predictable.