Pregunta

I am using the @Value annotation with Spring Boot, but it seems like it does not completely work as I would expect.

In my @Configuration file:

@Value("${installationDirectory}")
private File m_installationDirectory;

In my application.properties:

installationDirectory=${user.dir}/install

Startup:

public static void main( String[] args ) throws IOException
{
    logger.info( "Starting application" );
    logger.info( "Java version: {}", System.getProperty( "java.version" ) );
    logger.info( "Java home   : {}", System.getProperty( "java.home" ) );
    logger.info( "Operation System: {} {} ({})", System.getProperty( "os.name" ), System.getProperty( "os.version" ), System.getProperty( "os.arch" ) );
    logger.info( "Working dir : {}", System.getProperty( "user.dir" ) );

    SpringApplication springApplication = new SpringApplication( Main.class );
    springApplication.setShowBanner( false );
    ConfigurableApplicationContext context = springApplication.run( args );
}

Output when starting:

2014-05-14 09:36:05 INFO [main] Main - Starting application
2014-05-14 09:36:05 INFO [main] Main - Java version: 1.7.0_55
2014-05-14 09:36:05 INFO [main] Main - Java home   : /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
2014-05-14 09:36:05 INFO [main] Main - Operation System: Mac OS X 10.9.2 (x86_64)
2014-05-14 09:36:05 INFO [main] Main - Working dir : /Users/wdb/Work/netty-test
2014-05-14 09:36:05 INFO [main] Main - Starting Main on bruk-00007-l.zone2.flir.net with PID 98296 (/Users/wdb/Work/netty-test/flux-server/flux-server-application/target/classes started by wdb)
2014-05-14 09:36:05 DEBUG [main] Main - Running with Spring Boot v1.0.1.RELEASE, Spring v4.0.3.RELEASE
2014-05-14 09:36:08 INFO [main] LoggingToFileMessageRepositoryDecorator - Storing messages in /Users/wdb/Library/Caches/IntelliJIdea13/compile-server/install/messages
2014-05-14 09:36:08 INFO [main] OnDiskSingleJvmImageRepository - Storing images in folder /Users/wdb/Library/Caches/IntelliJIdea13/compile-server/install/images
2014-05-14 09:36:08 INFO [main] TrafficDataIntegratorsManagerImpl - Created 3 integrators for 1 sources in 1 ms
2014-05-14 09:36:09 INFO [main] Main - Started Main in 3.928 seconds (JVM running for 4.428)

Notice that the system property user.dir points to /Users/wdb/Work/netty-test if I just print it. However, where the installationDirectory value is injected into a Spring bean, the path seems to be /Users/wdb/Library/Caches/IntelliJIdea13/compile-server/install/ instead of the expected /Users/wdb/Work/netty-test/install

Note that I am running from IntelliJ 13.1.2 with the "Working directory" set to /Users/wdb/Work/netty-test in my run configuration.

¿Fue útil?

Solución

I found the issue. I am building with Maven. The spring-boot-starter-parent has resource filtering on by default for application.properties:

<!-- Turn on filtering by default for application properties -->
<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <includes>
            <include>**/application.yml</include>
            <include>**/application.properties</include>
        </includes>
    </resource>
    <resource>
        <directory>src/main/resources</directory>
        <excludes>
            <exclude>**/application.yml</exclude>
            <exclude>**/application.properties</exclude>
        </excludes>
    </resource>
</resources>

It seems that ${user.dir} is also something that Maven will replace. If I looked at the application.properties in my target/classes, it was indeed replaced.

To fix, I needed to do the following:

First tell Maven that you want escape filtering:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-resources-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    <escapeString>\</escapeString>
  </configuration>
</plugin>

Then change the application.properties file to:

installationDirectory=\${user.dir}/install

After this, everything works fine.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top