How to programmatically resolve property placeholder in Spring

Question

I currently work on a web application based on Spring 3.1.0.M1, annotations based, and I have a problem with resolving property placeholders in one specific place of my application.

Here is the story.

1) In my web application context (loaded by DispatcherServlet), i have

mvc-config.xml:

<!-- Handles HTTP GET requests for /resources/version/**  -->
<resources mapping="/${app.resources.path}/**" location="/static/" cache-period="31556926"/> 

...

<!-- Web properties -->
<context:property-placeholder location="
    classpath:app.properties
    "/>

2) Inside app.properties, there are 2 properties, among others:

app.properties:

# Properties provided (filtered) by Maven itself
app.version: 0.1-SNAPSHOT
...

# Static resources mapping
app.resources.path: resources/${app.version}

3) I have a JSP custom tag in my JSP 2.1 templates. This tag is responsible for full resource path construction depending on environment settings, app version, spring theme selection etc. Custom tag class extends spring:url implementation class, so it may be considered a usual url tag but with some additional knowledge about proper path.

My problem is that I cannot get ${app.resources.path} correctly resolved in my JSP custom tag implementation. JSP custom tags are managed by servlet container, not Spring, and therefore dont participate in DI. So I cannot just use usual @Value("${app.resources.path}") and get it resolved by Spring automatically.

All I have there is the web application context instance, so I have to resolve my property programmatically.

So far I tried:

ResourceTag.java:

// returns null
PropertyResolver resolver = getRequestContext().getWebApplicationContext().getBean(PropertyResolver.class);
resolver.getProperty("app.resources.path");


// returns null, its the same web context instance (as expected)
PropertyResolver resolver2 = WebApplicationContextUtils.getRequiredWebApplicationContext(pageContext.getServletContext()).getBean(PropertyResolver.class);
resolver2.getProperty("app.resources.path");


// throws NPE, resolver3 is null as StringValueResolver is not bound
StringValueResolver resolver3 = getRequestContext().getWebApplicationContext().getBean(StringValueResolver.class);
resolver3.resolveStringValue("app.resources.path");


// null, since context: property-placeholder does not register itself as PropertySource
Environment env = getRequestContext().getWebApplicationContext().getEnvironment();
env.getProperty("app.resources.path");

So now I'm kinda stuck with that. I know that the ability to resolve my placeholder is somewhere in the context, I just don't know the correct way to do it.
Any help or ideas to check are highly appreciated.

Eds · Answer 1 · 2014-12-12T22:14:41.567

55

Since Spring 3.0.3 there is EmbeddedValueResolverAware which will work same way as mentioned by another post which uses appContext.getBeanFactory().resolveEmbeddedValue("${prop}") call.

To solve the problem:

Make your class to implement EmbeddedValueResolverAware interface and you will get resolver injected for you
Then where you will be able to retrieve properties as demonstrated in a code snippet:
```
String propertyValue = resolver.resolveStringValue("${your.property.name}");
```

Then your bean does not need to depend on ApplicationContext to retrieve properties you need.

edited Dec 12 '14 at 22:14

answered Apr 19 '13 at 14:15

Eds

781
1
5
7

4

This is a very simple way to solve the issue. For any future readers, just add the interface EmbeddedValueResolverAware to the spring-managed class in which you want to be able to resolve properties programmatically, implement the setter method, and use the code @Eds wrote to resolve. – Alex Aug 22 '14 at 01:19
In fact Alex deserves the thumb up for his comment. Don't you want edit the answer? – Heri Dec 11 '14 at 20:58
This is the only approach I've seen that seems acceptable for writing shared components/config that have to work for multiple spring apps. You don't want said code to have a dependency on how a particular app sources its property configuration from files or other means. – S Balough Oct 11 '17 at 12:24
Thanks @Alex that worked as simple as I wanted, also with Spring 5, where the ApplicationContext.getBeanFactory() method does not work anymore. Just remember to wrap your property in "${...}" as described, easy to forget and wonder why you get only the key back;) – Gregor Aug 20 '18 at 17:24

score 26 · Answer 2 · answered Jan 25 '13 at 18:55

26

Since version 3.0, Spring keeps a list of String resolver in the beanFactory. You can use it like this:

String value = appContext.getBeanFactory().resolveEmbeddedValue("${prop}");

The javadoc states this method as for resolving embedded values such as annotation attributes so maybe we are circumventing its usage, but it works.

answered Jan 25 '13 at 18:55

thibr

607
6
13

Thank you very much indeed ! Was looking for some time now for a clean way to query the environment. – Jan Goyvaerts May 13 '13 at 12:27

score 15 · Accepted Answer · answered Mar 03 '11 at 01:15

15

I think rather than focusing on inner working of context place holder, you can simply define a new util:properties like this:

<util:properties id="appProperties" location="classpath:app.properties" />

and in your code, use it like this:

Properties props = appContext.getBean("appProperties", Properties.class);

OR like this wherever you can do DI:

@Value("#{appProperties['app.resources.path']}")

answered Mar 03 '11 at 01:15

Ritesh

7,472
2
39
43

Thank you, Ritesh. I think I can use this solution, in case if nothing more elegant will be found. – Max Alexejev Mar 03 '11 at 02:39
Marked this answer as Accepted, but it is anyways interesting to find pure programmatic solution. – Max Alexejev Mar 09 '11 at 18:13
@Max Alexejev You can also extend PropertyPlaceholderConfigurer and capture resolved properties that are passed in second argument to processProperties method. But then you will have to use bean configuration instead of context:property-placeholder. – Ritesh Mar 09 '11 at 18:50
I think this answer is more "elegant": http://stackoverflow.com/a/11647231/120794. Also works with spring 2.5. – Alberto de Paola Mar 17 '14 at 20:03

score 5 · Answer 4 · answered Jan 21 '15 at 15:31

One option is to add a PropertySource (here MapPropertySource to exemplify an in-memory configuration) to a ConfigurableEnvironment and ask it to resolve properties for you.

public class Foo {

    @Autowired
    private ConfigurableEnvironment env;

    @PostConstruct
    public void setup() {
        env.getPropertySources()
           .addFirst(new MapPropertySource("my-propertysource", 
               ImmutableMap.<String, Object>of("your.property.name", "the value")));
        env.resolvePlaceholders("your.property.name");
    }
}

Optionally annotate the Foo class with @Configuration to enjoy the power of programmatic configuration in favor of XML.

Excellent! That's exactly what I was looking for, thank you – Stefan May 30 '18 at 07:36 — Stefan, May 30 '18 at 07:36

Supun Wijerathne · Answer 5 · 2021-06-10T15:36:51.617

2

Just to add a complete answer, I'm adding this.

You can do it with a custom class like this.

import org.springframework.context.EmbeddedValueResolverAware;
import org.springframework.util.StringValueResolver;
import org.springframework.lang.Nullable;

public class MyValueResolver implements EmbeddedValueResolverAware {
    //this will be injected using the setter injection.
    //Spring already has an implementation org.springframework.beans.factory.config.EmbeddedValueResolver
    //Or you can implement your own and use @Primary
    @Nullable
    private StringValueResolver resolver;

    @Override
    public void setEmbeddedValueResolver(StringValueResolver resolver) {
        this.resolver = resolver;
    }

    public String readMyProperty(String propertyString){
        return resolver.resolveStringValue(propertyString);
    }
}

This propertyString should be passed as "${my.property}".

Given that in .properties file it is presented as

my.property=myPropertyValue

edited Jun 10 '21 at 15:36

answered Jan 20 '20 at 08:15

Supun Wijerathne

11,964
10
61
87

And where to get the `StringValueResolver`? Please clearify. – Arman Jun 09 '21 at 08:33
@Arman it's already added, import org.springframework.util.StringValueResolver; – Supun Wijerathne Jun 10 '21 at 05:25
I guess my question was not clear enough. I know that `StringValueResolver` is known to Spring, but in order to use the `MyValueResolver` it has to be constructed somehow. Thus how do I obtain an instance of `StringValueResolver`? – Arman Jun 10 '21 at 14:09
1

very sorry for the misunderstanding, So here what happens is this StringValueResolver type will be injected, So in Spring it already has implementations of StringValueResolver (Ex: EmbeddedValueResolver class). Or you can implement your own (then had to use @Primary or other way to remove the conflict). I will add this description as a comment for my code snippet. – Supun Wijerathne Jun 10 '21 at 15:33

score 1 · Answer 6 · answered Mar 04 '11 at 04:15

There is one more possible solution: make tag classes @Configurable via AspectJ and enable either compile-time or load-time weaving. Then, I could use usual Spring @Value annotations in my custom tags. But, really, I don't want to set up weaving infrastructure just because of a couple of classes. Still searching for a way to resolve placeholder via ApplicationContext.

How to programmatically resolve property placeholder in Spring

6 Answers6

Linked