The new Certification Class of Learn Spring Security is out:


Table of Contents

1. Overview

This tutorial will show how to set up and use Properties in Spring – via XML and <property-placeholder> or Java configuration and @PropertySource.

Before Spring 3.1, adding new properties files into Spring and using property values wasn’t as flexible and as robust as it could be. Starting with Spring 3.1, the new Environment and PropertySource abstractions have simplified then entire process.

Now, if you want to go beyond the how to use properties and into how to actually do project configuration for a Spring application, definitely explore this write-up as well.

Further reading:

Spring Expression Language Guide

This article explores Spring Expression Language (SpEL), a powerful expression language that supports querying and manipulating object graphs at runtime.

Read more

Learn to work with Properties in Spring

2. Register a Properties File in XML

In XML, new properties files can be made accessible to Spring via the <context:property-placeholder … > namespace element:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="" 

      <context:property-placeholder location="" />


The file should be placed under /src/main/resources so that it will be available on the classpath at runtime.

2.1. Multiple <property-placeholder>

In case multiple <property-placeholder> elements are present in the Spring context, there are a few best practices that should be followed:

  • the order attribute needs to be specified to fix the order in which these are processed by Spring
  • all property placeholders minus the last one (highest order) should have ignore-unresolvable=”true” to allow the resolution mechanism to pass to others in the context without throwing an exception

3. Register a Properties File via Java Annotations

Spring 3.1 also introduces the new @PropertySource annotation, as a convenient mechanism for adding property sources to the environment. This annotation is to be used in conjunction with Java based configuration and the @Configuration annotation:

public class PropertiesWithJavaConfig {

   public static PropertySourcesPlaceholderConfigurer
     propertySourcesPlaceholderConfigurer() {
      return new PropertySourcesPlaceholderConfigurer();

As opposed to using XML namespace element, the Java @PropertySource annotation does not automatically register a PropertySourcesPlaceholderConfigurer with Spring.

Instead, the bean must be explicitly defined in the configuration to get the property resolution mechanism working. The reasoning behind this unexpected behavior is by design and documented on this issue.

One other very useful way of registering a new properties file is using a placeholder to allow you to dynamically select the right file at runtime; for example:


4. Using / Injecting Properties

Injecting a property with the @Value annotation is straightforward:

@Value( "${jdbc.url}" )
private String jdbcUrl;

A default value of the property can also be specified:

@Value( "${jdbc.url:aDefaultUrl}" )
private String jdbcUrl;

Using properties in Spring XML configuration:

<bean id="dataSource">
  <property name="url" value="${jdbc.url}" />

Both the older PropertyPlaceholderConfigurer and the new PropertySourcesPlaceholderConfigurer added in Spring 3.1 resolve ${…} placeholders within bean definition property values and @Value annotations.

Finally – to obtain the value of a property with the new Environment API:

private Environment env;

A very important caveat here is that using <property-placeholder> will not expose the properties to the Spring Environment – this means that retrieving the value like this will not work – it will return null:


4.1 Properties Search Precedence

By default, in Spring 4, local properties are search last, after all, environment property sources, including properties files. A quick sidenote here is that local properties are properties that are configured manually/programmatically via the setter APIs in the base PropertiesLoaderSupport class (setProperties, setLocation, etc).

This behavior can be overridden via the localOverride property of the PropertySourcesPlaceholderConfigurer, which can be set to true to allow local properties to override file properties.

In Spring 3.0 and before, the old PropertyPlaceholderConfigurer also attempted to look for properties both in the manually defined sources as well as in the System properties. The lookup precedence was also customizable via the systemPropertiesMode property of the configurer:

  • never – Never check system properties
  • fallback (default) – Check system properties if not resolvable in the specified properties files
  • override – Check system properties first, before trying the specified properties files. This allows system properties to override any other property source.

Finally, note that in case a property is defined in two or more files defined via @PropertySource the last definition will win and override the previous ones. This makes the exact property value hard to predict, so if overriding is important, the PropertySource API can be used instead.

Before going low level with the configuration, let’s do some practical work working with properties files.

5. Properties with Spring Boot

Before we go into more advanced configuration options for properties, let’s spend some time looking at the new properties support in Spring Boot.

Generally speaking, this new support involves less configuration compared to standard Spring, which is of course one of the main goals of Boot.

5.1. – the Default Property File

Boot applies it’s typical convention over configuration approach to property files. This means that we can simply put an “” file in our “src/main/resources” directory, and it will be auto-detected. We can then inject any loaded properties from it as normal.

So, by using this default file, we don’t have to explicitly register a PropertySource, or even provide a path to a property file.

We can also configure a different file at runtime if we need to, using an environment property:

java -jar app.jar --spring.config.location=classpath:/

5.2. Environment Specific Properties File

If we need to target different environments, there’s a build-in mechanism for that in Boot.

We can simply define an “” file in the “src/main/resources” directory – and then set a Spring profile with the same environment name.

For example, if we define a “staging” environment, that means we’ll have to define a staging profile and then

This env file will be loaded and will take precedence over the default property file. Note that the default file will still be loaded, it’s just that when there is a property collision the environment specific property file takes precedence.

5.3. Test Specific Properties File

We might also have a requirement to use different property values when our application is under test.

Spring Boot handles this for us by looking in our “src/test/resources” directory during a test run. Again, default properties will still be injectable as normal, but will be overridden these ones if there is a collision.

5.4. The @TestPropertySource Annotation

If we need more granular control over test properties, then we can make use of the @TestPropertySource annotation.

This allows us to set test properties for a specific test context, taking precedence over the default property sources:

public class IntegrationTests {
    // tests

If we don’t want to use a file, we can specify names and values directly:

@TestPropertySource("foo=bar", "bar=foo")
public class IntegrationTests {
    // tests

We can also achieve a similar effect using the properties argument of the @SpringBootTest annotation:

@SpringBootTest(properties = {"foo=bar", "bar=foo"})
public class IntegrationTests {
    // tests

5.5. Hierarchical Properties

If we have properties which are grouped together, we can make use of the @ConfigurationProperties annotation which will map these property hierarchies into Java objects graphs.

Let’s take some properties used to configure a database connection:


And then let’s use the annotation to map them to a database object:

@ConfigurationProperties(prefix = "database")
public class Database {
    String url;
    String username;
    String password;

    // standard getters and setters

Spring Boot applies it’s convention over configuration approach again, automatically mapping between property names and their corresponding fields. All that we need to supply is the property prefix.

If you want to dig deeper into configuration properties, have a look at the in-depth article.

5.6. Alternative – YAML Files

YAML files are also supported.

All the same naming rules apply for test specific, environment specific, and default property files. The only difference is the file extension, and a dependency on the SnakeYAML library being on your classpath.

YAML is particularly good for hierarchical property storage; the following property file:

secret: foo

Is synonymous to the following YAML file:

  url: jdbc:postgresql:/localhost:5432/instance
  username: foo
  password: bar
secret: foo

It’s also worth mentioning that YAML files do not support the @PropertySource annotation, so if use of the annotation was required it would constrain us to using a properties file.

5.7. Properties from Command Line Arguments

As opposed to using files, properties can be passed directly on the command line:

java -jar app.jar --property="value"

You can also do this via system properties, which are provided before the -jar command rather than after it:

java"value"-jar app.jar

5.8. Properties from Environment Variables

Spring Boot will also detect environment variables, treating them as properties:

export name=value
java -jar app.jar

5.9 Randomization of Property Values

If we don’t want determinist property values, RandomValuePropertySource can be used to randomise the values of properties:


5.10. Additional Types of Property Sources

Spring Boot supports a multitude of property sources, implementing a well thought ordering to allow sensible overriding. It’s worth consulting the official documentation, which goes further than the scope of this article.

6. Behind the Scenes – the Spring Configuration

6.1. Before Spring 3.1

Spring 3.1 introduced the convenient option of defining properties sources using annotations – but before that, XML Configuration was necessary for these.

The <context:property-placeholder> XML element automatically registers a new PropertyPlaceholderConfigurer bean in the Spring Context. For backward compatibility, this is also the case in Spring 3.1 and above if the XSD schemas are not yet upgraded to point to the new 3.1 XSD versions.

6.2. After Spring 3.1

From Spring 3.1 onward, the XML <context:property-placeholder> will no longer register the old PropertyPlaceholderConfigurer but the newly introduced PropertySourcesPlaceholderConfigurer. This replacement class was created to be more flexible and to better interact with the newly introduced Environment and PropertySource mechanism.

For applications using Spring 3.1 or above, this should be considered the standard.

7. Configuration using Raw Beans in Spring 3.0 – the PropertyPlaceholderConfigurer

Besides the convenient methods of getting properties into Spring – annotations and the XML namespace – the property configuration bean can also be defined and registered manually. Working with the PropertyPlaceholderConfigurer gives us full control over the configuration, with the downside of being more verbose and most of the time, unnecessary.

7.1. Java configuration

public static PropertyPlaceholderConfigurer properties() {
  PropertyPlaceholderConfigurer ppc
    = new PropertyPlaceholderConfigurer();
  Resource[] resources = new ClassPathResource[]
    { new ClassPathResource( "" ) };
  ppc.setLocations( resources );
  ppc.setIgnoreUnresolvablePlaceholders( true );
  return ppc;

7.2. XML configuration

    <property name="locations">
    <property name="ignoreUnresolvablePlaceholders" value="true"/>

8. Configuration using Raw Beans in Spring 3.1 – the PropertySourcesPlaceholderConfigurer

Similarly, in Spring 3.1, the new PropertySourcesPlaceholderConfigurer can also be configured manually:

8.1. Java configuration

public static PropertySourcesPlaceholderConfigurer properties(){
  PropertySourcesPlaceholderConfigurer pspc
    = new PropertySourcesPlaceholderConfigurer();
  Resource[] resources = new ClassPathResource[ ]
    { new ClassPathResource( "" ) };
  pspc.setLocations( resources );
  pspc.setIgnoreUnresolvablePlaceholders( true );
  return pspc;

8.2. XML configuration

    <property name="locations">
    <property name="ignoreUnresolvablePlaceholders" value="true"/>

9. Properties in Parent-Child Contexts

This question keeps coming up again and again – what happens when your web application has a parent and a child context? The parent context may have some common core functionality and beans, and then one (or multiple) child contexts, maybe containing servlet specific beans.

In that case, what’s the best way to define properties files and include them into these contexts? What’s more – how to best retrieve these properties from Spring? Here is the simple breakdown.

9.1. If the properties file is defined in XML with <property-placeholder>

If the file is defined in the Parent context:

  • @Value works in Child context: NO
  • @Value works in Parent context: YES

If the file is defined in the Child context:

  • @Value works in Child context: YES
  • @Value works in Parent context: NO

Finally, as we discussed before, <property-placeholder> does not expose the properties to the environment, so:

  • environment.getProperty works in either context: NO

9.2. If the properties file is defined in Java with @PropertySource

If the file is defined in the Parent context:

  • @Value works in Child context: YES
  • @Value works in Parent context: YES
  • environment.getProperty in Child context: YES
  • environment.getProperty in Parent context: YES

If the file is defined in the Child context:

  • @Value works in Child context: YES
  • @Value works in Parent context: NO
  • environment.getProperty in Child context: YES
  • environment.getProperty in Parent context: NO

10. Conclusion

This article shows several examples of working with properties and properties files in Spring.

As always, the entire code backing the article is available over on Github. This is an Maven based project, so it should be easy to import and run as it is.

Go deeper into Spring Security with the course:


  • Chris Beams

    Thanks for the write-up, Eugen. See here for more detail on using the Environment API directly within @Configuration classes (over the use of @Value):

  • endless

    Any idea how to force PropertySourcesPlaceholderConfigurer use system property override? Currently it seems to ignore that and take the value from the property file.

  • Vlad Tanasescu

    Great article! shouldn’t “” be “” (with an s). For those reading this, remember it won’t work if you use ‘new’ on your component.

  • pl47ypus

    great post(!), however, the suggested solution seams to work only when you define the PropertySourcesPlaceholderConfigurer in the same context of the injected bean. i’ll explain:

    in my application i have one application context file: app.xml and two mvc context files: x-servlet.xml and y-servlet.xml. my PropertySourcesPlaceholderConfigurer is configured in the app.xml (which is the parent context of both servlet contexts). the servlet contexts manage @Controller instance that use @Value injection.

    the problem is that spring doesn’t inject embedded values from parent contexts (bean-factories).

    i don’t want to declare the PropertySourcesPlaceholderConfigurer in each *-servlet.xml separately.
    any ideas?

    • That’s an interesting use-case – can you please open an issue on github and I’ll take a look.

    • Sravan

      My immeadiate answer to this problem is to have a dummy bean which stores all the properties across the application in the root context. As we know the beans from root context are available to child, It may solve the problem. But I am not sure how good this design is….

    • I updated the article with a clear breakdown of what works and what doesn’t for parent-child contexts. Let me know if this answers your question. Cheers.

  • Manuel Ortiz

    What happens with properties defined at runtime with the -D prefix (eg: -DapiVersion=1.0)? Do they override those defined on files? Are they recognized by the @Value annotation?

    • Hey Manuel – sorry for the late response – yes, a runtime property will override a local one and will be correctly resolved by @Value. Of course, this is only the default – this behavior can be overridden both in XML and in the Java config.

  • Hi! Do you know if there are any way in Spring to load a list of properties like in Apache Common, repeating the property key, e.g. prop=a, prop=b and prop=c would result in a list like {‘a’, ‘b’, ‘c’}. Or something like prop.1=a, prop.2=b, prop.3=c.

    I tried to find something but all that have come to my mind envolves subclassing the property placeholder. 🙁


    • No way to do that as far as I know; having a single property such as: prop.something=a,b,c would be one thing, but loading multiple properties at once, based on a prefix – that’s really an edge case. You could try to roll your own placeholder – or maybe you can step back and see if, since you need that kind of query operation over your data – maybe properties is not the right way to store that data.

      • Thanks for your reply! 🙂

        Do you really think that this is unusual?

        I have a RPC like system where each node can reply to 1 to N operation types. My ideia is that each node reads the operations it handles from a property file. The requests are stored in a message queue system. So the node polls for requests based in the operations it has been assigned.

        With that approach I could choose to tackle the overall load of the system. If an operation A is requested twice than an operation B, I can start a node dedicated to the first one and so on.

        Do you have any sugestion about how to do that node configuration?

        See ya! Thanks again for your help.

        • I am assuming the nodes don’t have any sort of persistence to keep this data (rather then in properties). For light node configuration, you can take a look at Zookeeper – that’s what it’s meant to do.
          Properties are meant to have a single operation – get one by name – and it looks like you basically need more intelligent query operations over them. This is why I said that this is a corner case – not in the sense that it’s extremely rare, but that queries over properties are – in my view – a code smell – a signal that that may not be the right way to store my data (in your case, the operations to be handled), and that I may need real persistence, not just properties files.
          Hope that helps – let me know how it goes,

  • thanks for detailed explanations, that helped me to understand better this mechanism. I, for example, was using .properties files – loaded and parsed at application start-up, this is working all the time, but I should write all the parsing stuff, which is not a tragedy, but it works every time, even if it’s not very pretty 🙂

    • Glad it helps – the Spring support is also a lot more flexible than parsing property files manually.

      • yes, I know and I agree, but I had situations when @Value was not instantiated at applications start, etc. now 🙂 everything looks cleaner to me

  • Anup

    What a post very informative ..!!.However I wish to add a use case which probably your post does not adher to .

    Use case :- I have a use case where in I wish to read the values from the property files from my java code .Some way similiar to Env.getProperty.(). I cant use @Value which assigns a value to a variable bcoz the I have to read the value directly from the .property files .@Value allows me to hardcode a key against a variable.

    In regards to env.getProperty() I am not sure whether Env.getProperty() allows us to add data dynamically to the the value read from .property file .

    For example , xyzKey= Welcome {0} to the site.

    where I wish to replace {0} with dyanamic data.

    This is propably handled by resource Bundle class of JAVA which is imbibed in ResourceBundleMessageSource class of Spring

    Only drawback of this way of loading property file is to mention the locale to get the property.

    messageSource.getMessage(‘xyzKey’,new String{‘Anup’}, new Locale(“en”,”US”) );

    This is a drawback because my application is not locale specific but still I got to Locale class and respective naming convention

    • Hey Anup, thanks for the interesting usecase – I’ll take a look and get back to you.

    • Hey Anup – so let me see if I understand your usecase correctly. Are you’re trying to set values of these properties at runtime? Or are you just trying to read the properties from the file?
      If you’re trying to set values of properties at runtime – what is the reason for that?
      If you are just reading the properties – why do you need another mechanism (other than env.getProperty()?)


      • Anup

        Hey Eugen,

        I wish to read the properties from file .However as mentioned in the previous post ,I cant use env.getProperty() because I wish to put dynamic data in the message that I read from the properties using placeholders. To adher to this use case I had to use which internally uses ResourceBundle which in turn allows us to insert Dynamic data in the messages against a particular key in properties file.

        For example in my property file i have this entry
        xyzKey= Welcome {0} to the site.

        So while reading it in my code I use the below code :-

        messageSource.getMessage(‘xyzKey’,new String{‘Anup’}, new Locale(“en”,”US”) );

        which would read the value against ‘xyzKey’ and relpace {0} with ‘Anup’ on the fly.


        • I see – well, in that case, you can have a property with that value, but you will of course have no resolution of {0} = you’ll need to handle that yourself. If you also need resulution for the placeholder, then properties are not your best bet, as they are not meant to solve this kind of problem.
          Properties are simple – they have clear purpose and do it well, but they do have their constraints and cannot be used for everything.
          Hope this helps.

  • Boxing Cat

    In 7.2 not

  • Tonio Caputo

    Nice article, all in one, thanks for it !!!!

    One thing its worth to mention, a use case I faced sometime ago not present in this article, how to use a ‘placeholder’ in an import statement, useful when the property value is not known at start time (if not you can just add it as a java property).

    Since spring 3.1 (as you probably already know) you can implement ApplicationContextInitializer and add properties (placeholders) you can use in your imports at runtime, may be its also useful in other use cases I can’t figure out right now.

    Hope this info is useful, and again thanks for your article.

    • Hey Tonio – thanks for the suggestion – yes, I’ve been using that extensivelly and now I added it to the article as well. Cheers,

  • Duane

    I can’t seem to download the Spring Properties Tutorial sample project. When I click on the link, it tells me I need to subscribe, but when I enter my email, it redirects me to a page that says I’m already subscribed, with no way I can see to download the sample project.

    • Hey Duane – if you’re already subscribed, that’s the way it should behave, yes. However, you should also receive the email with the download link, regardless of the fact that you’re subscribed. Hope that makes sense – and do let me know if that’s not the case. Cheers,

  • Jayakumar Jayaraman

    Very useful. Mainly ignore-unresolvable=”true” helped me when I had multiple files and struggled to fix a error due to this.

  • Alex

    Hi Eugen,
    Thank you for your informative overview.
    Could you maybe add a java config use case for the ConfigurableEnvironment interface? It seems to allow for adding PropertySource’s via the getPropertySources() method. I’m thinking of a situation in which the properties file name is based on the application name – retrievable via the ApplicationContext.after deployment. This would allow a user to deploy one .war application multiple times by copying the .war file and have each instance fetch its own properties from a common location.

    • Hey Alex – thanks for the suggestion. Yes, ConfigurableEnvironment does have that option, but you will almost never have to set such an environment up manually.
      As for different properties that are environment specific – I would recommend doing it differently. There are a few good ways you can set this up without needing to change the behavior of the low level getPropertySources method. I covered one way to do this configuration here, but it’s definitely not the only option.
      Hope it helps. Cheers,

  • Gianluca

    How i can save my property?.. (update it)

    • Hi. Properties aren’t mean to be updated dynamically – they’re a basic type of configuration for which static files are OK. For complex applications that might not be enough, in which case you can of course implement a simple persistent key-val solution for these kinds of dynamic properties. Cheers,

  • Aurélien Leboulanger


    what happens if i have a property reference in my properties file ?

    for Example :

    test = ok

    test2 = ${test}

    does the reference is resolved when i to load the value with @Value(“${test}”) ?

    it’s works perfectly when i declare my placeholder in xml, but not when i declare it with javaConfig

    • Hey Aurélien – while I haven’t tested it, this shouldn’t work – it’s interesting that it does with XML. Regardless, it’s beyond what simple properties are meant to be used for, and getting into custom configuration territory. Cheers,

  • rui li

    Is it possible for dynamic load properties files? let’s say, we have some value pairs defined in a property file, how can we make sure the new value pairs can be loaded by spring without restart.

    • There’s no out of the box support for that – properties fit the static usecase better. If you need something dynamic, there are ways/hacks to make them dynamic but better yet, just don’t use properties files. Maybe a simple key-value persistence would fit the bill and would allow for a more natural kind of access. Hope it helps. Cheers,

  • Monika

    Hi Eugen, I am new to Spring, I downloaded the above example and run it . Its showing

    Constructor Injection – Property Value resolved to: val
    in afterPropertiesSet via @Value: val
    in afterPropertiesSet Environment: null
    in test via @Value: val
    in test Environment: null

    Enviroment is null. Can u please have a look again.


    • Hey Monika, thanks for pointing that out. First – I did the original testing manually, so now we have some new tests that are actually bootstrapping a parent and a child contexts and specifically looking for these values in each. And with that, I also updated the 6th value to NO. Cheers,

  • Ignacio Cañon

    great post, I’m facing a very strange problem with properties, I have several classes and my intention is to load one different property file for each one. So I have each class annotated with @PropertySource and locating its own property file. But When I run the tests every instance shows values from the same property file, like overriding. Using a single location in PropertySource annotation is not enough for telling spring to load only from that file?
    Thanks in advance

    • Hey Ignacio,
      First – I’m assuming that each properties file holds a different set of properties.
      Second – make sure that when you bootstrap your Spring context, the other configuration files are actually not instantiated (you can do that by either debugging, or trying to retrieve the bean from the context afterwards).
      And finally – you can reproduce the problem in a simple github project, and I’d be happy to have a look. Cheers,

  • Reshma

    If you could please clarify as to what is the local property indicate to in the below mentioned section of your tutorial will be helpful ..

    4.1 Properties Search Precedence

    By default, in Spring 4, local properties are search last,

    • Hey Reshma – definitely an interesting questions. I explained what local properties are in the article – hope that clears things up. Cheers,

  • Kisna

    Some challenges we faced:
    1. no way to fail when @Value does not resolve, sometimes defaults to the placeholder string constant, only solution is to verify these with afterPropertiesSet method
    2. figuring out which configuration file property value was injected into a @Value, custom logging
    3. no way to fail when there are multiple configuration files, example, one in jar and one in a classpath folder, namespacing with right package does not help here either
    4. Spring silently ignoring multiple , use PropertySourcesPlaceholderConfigure

    • Hey Kisna – those are some interesting points. Let’s go over them.
      1 – that should definitely not be the case; if there’s no value and you’re providing no default, the bootstrapping process should fail with a java.lang.IllegalArgumentException: Could not resolve placeholder
      2 – what value gets injected does of course depend on your configuration and the properties files that you’re using/defining; and yes, you could potentially check that in afterPropertiesSet, or, better – via a test (not at runtime)
      3 – no, value doesn’t support that kind of check; my suggestion here is to – as much as possible – chose one way of providing these properties files and stick with it; if you mix and match – yes, you’ll have to be careful not to provide the same property twice
      4 – support for multiple property-placeholder elements is actually a good thing in a lot of usecases; but if you want to stick with one, that should be pretty easy, since you’re the one defining them
      Hope that helps. Cheers,

  • Jithin

    I have defined 2 property placeholder conf with same order .Behaviour what i was found is that if i define a property in the 2nd file with default value it is not picking from the file.if i didnot specify the default value it is taking from the file.can anybody help.“

    private String charLenght;
    If i specify the default values as 128, charLenth field is assigned with 128
    If i am not specifying the default value. ie:
    private String charLenght; In this case, it is reading from the property file and assigned with 256

    • Hey Jithin – a couple of notes here.
      First – defining both of these placeholders with the same order is not a good idea – that’s why you have an order there – to be able to specify which is first and which is second.
      Then – the way the property resolution works there will also depend on how your Spring Context is bootstrapped (single, multiple, child, etc).

      Finally – the way to get this answers is by having a test that actually reproduces the problem in a simple project. Once you have that, post about it on StackOverflow and send me the link and I’d be happy to have a look. Cheers,

  • Suraj Khanduri

    Hi Eugen, As Spring has deprecated ServletContextPropertyPlaceholderConfigurer in favor of PropertySourcesPlaceholderConfigurer, I am not getting how to set some parameters like ‘systemPropertiesModeName’, ‘searchContextAttributes’,’contextOverride’ with PropertySourcesPlaceholderConfigurer. ServletContextPropertyPlaceholderConfigurer supports these parameters but PropertySourcesPlaceholderConfigurer not. Thanks for any help.

    • Hey Suraj, sorry for the late reply here.
      As far as I know, these aren’t all supported within the new impl, but depending of course on what you’re trying to do, you may not need these specific ones.
      Here’s one that is still supported:
      Hope that helps.

  • Inam

    @baeldung:disqus no mention of @Resource annotation method?

    • Hey Inam – that’s interesting – how are you using @Resource to work with properties. Other than maybe injecting the beans themselves, I’m not sure how that would be useful.

      • Inam

        Yes, you can inject props file as a bean and can autowire it wherever you need in @Component classes.

        • So, let me take a step back here.
          Are you referring to the fact that you’re able to inject a java.util.Properties? Or are you referring to a Spring bean?

          The first option is not ideal – that will make available the entire set of properties of the JVM, but not Spring properties (which is what we want).

          And if you’re injecting the Spring bean – sure, you can do that (you don’t need @Resource to do it, you can simply use @Autowire) – but, again – why do you need that.

          So – maybe an example would clear things up – let me know if you have one.

  • david lopes

    Sr. I got problem when I try to get Integer values from my property files. How can get theses values beside String type?.
    I posted my question here >>

    • Grzegorz Piwowarek

      David, are you sure that a file with properties is found by Spring? Spring should be able to inject Integers without any problems

  • Dmitry Kravchenko

    Doesn’t work. Throws NoSuchMethodError: org.hibernate.Session.getFlushMode()Lorg/hibernate/FlushMode

    • Hey Dmitry – I just updated the link to a more up-to-date version of the codebase, so feel free to give that a try. Everything should be running fine there.