Develop Reference

Spring boot external properties file in "current directory" is ignored

from the manual:
24.3 Application property files SpringApplication will load properties from application.properties files in the following locations and add
them to the Spring Environment:
A /config subdirectory of the current directory.
The current directory
A classpath /config package
The classpath root
It mentions current directory twice but this really doesn't mean anything:
I tried putting it in the root of my project (i.e. above src in the folder that matches the output of java.io.File( "." ).getCanonicalPath() and System.getProperty("user.dir");), and I tried putting it with the war files (i.e. in build\libs)
But the only place to put it that actually works is the default location (src\main\resources).
So what does "current directory" even mean and where do the files really go?
I need to find the correct external location for the files so I don't have to build database credentials into the app.
The guides say that putting application.properties in current directory will work and I found the exact current directory to put it in but it still doesn't work, which I can verify by the output of: System.out.println(System.getProperty("spring.datasource.url")); which is null It does output the correct value only with an embedded properties file.

According to ConfigFileApplicationListener:
// Note the order is from least to most specific (last one wins)
private static final String DEFAULT_SEARCH_LOCATIONS =
"classpath:/,classpath:/config/,file:./,file:./config/";
file:./ resolve to the working directory where you start the java process.

I agree with Stephane Nicoll's argument that we generally don't need this for development and test but needed for production where properties file is generally externalized and the one present in source code is not used. This is what works for me ,
java -jar myjar.jar --spring.config.location=file:D:\\RunRC\\application.properties
Directory - D:\\RunRC - mentioned in above command is sample from my machine.
I keep using properties file of source code i.e. from \src\main\resources\ in development and test but in production , I comment out entries and if I am starting my jar or war from D:\\RunRC then I provide Current Directory as shown in above java command and keep properties file there.
Just doing - #PropertySource({ "application.properties"}) or #PropertySource({ "file:application.properties"}) doesn't pick it up from the directory where jar or war is kept.
For database credentials, I would suggest to use OS specific environment variables and use syntax similar to - #PropertySource({"file:${CONF_DIR}database.properties" }) where CONF_DIR is existing environment variable pointing to that directory.
Hope it helps !!

I understand that the current directory is the root directory of your project. However, you can change this with -Dspring.config.location=your/config/dir/.
Have a look at this post enter link description here

If you search for "current directory java", you'll end up here with this question. The intention is that if you put an application.properties in the same directory as the application, it will be picked up by default.
You will not use that feature in development or for test as you shouldn't rely on that feature. But when running your app in production, it might be handy to put environment-specific settings in a configuration file that sits next to the application itself.

Current directory refers to where we execute our jar. Creating an executable jar via Spring Boot maven plugin and placing application.properties just beside the jar file will work. An example :here

Maven configuration: pass file inside a classpath jar as an argument

Several maven plugins need/support passing a java.io.File as a configuration parameter, wherein we specify the relative/absolute location of the file for the plugin to locate and use.
Is there a way I can specify a property file in the plugin configuration where the file has to be found from inside a jar in the classpath? I'm particularly wanting this to know and use with the aspectj-maven-plugin, where I can specify the Xlintfile value to be the custom XlinkDefault.properties file location. The file, in my case, will be found inside a classpath jar.
I use maven-2.2.1 by the way.

No, not in general; there's no magic that will turn something that's not a file on disk into a java.io.File. Many Maven plugins (e.g., maven-checkstyle-plugin's configLocation are designed to allow more flexible input for just these cases:
This parameter is resolved as resource, URL, then file. If successfully resolved, the contents of the configuration is copied into the ${project.build.directory}/checkstyle-configuration.xml file before being passed to Checkstyle as a configuration.
As a workaround, if the plugin cannot be changed, dependency:unpack may be a way to get a classpath resource into a local file (see Maven: extract files from jar).

Specify a parameter for using files inside a Jar

Say log.properties is in the test.jar. I would like to specify the file parameter using some file inside the jar, is this doable?
-DLog=target/classes/log.properties

Though question is not that clear to me, I will try to answer:
If you have are loading your parameter'd file with:
getClass().getClassLoader().getResourceAsStream(fileParameter);
then even if your file is inside jar (in classpath) it should work. And you should be able to pass parameter something as -DLog=log.properties, so that it will search all the possible paths in classpath.

Why does the Java compiler say my file was not found in the class path when I can clearly see it in the class path?

I am using java -classpath $CLASSPATH ..., where $CLASSPATH has been set to /file1path/file1:/file2path/file2 and so on. Despite this, Java complains that file1 is not found. I tried to set -Dfile1=file:///fullpath/file1, but it still says it cannot find the file. Is there any reason why this might happen other than that I am not seeing a simpler problem like a typo or something (which I have checked for many times)?
More specifically, this.getClass().getClassLoader().getResourceAsStream(configurationFileName) is returning null.
The file that is not being found is a configuration file (.properties), not a JAR file.

You set a classpath to point to a directory containing something or an archive containing resources. I don't believe you can add a resource directly to the classpath.
Try setting your classpath to /file1path instead of /file1path/file1

The classpath should specify the directory where your package hierarchy rooted.
package org.djna, file system : C:/myhome/javastuff/org/djna/Myclass.java
classpath is set to c:/myhome/javastuff
If you are trying to open files from your application using getResourceAsStream() or some such the the details of the path depend on whether or not the filename has a leading /. Read the docs caefully and all will become clear.

How to change the path of displaytag.properties?

Currently i have placed the Displaytag.properties in 'src' directory, and it is working fine. Is it posssible to have this file on some different location like src/comp/bre/sub/config ?

From the docs for the DisplayTag library:
For the whole web application, create
a custom properties file named
"displaytag.properties" and place it
in the application classpath.
Displaytag will use the locale of the
request object to determine the locale
of the property file to use; if the
key required does not exist in the
specified file, the key will be loaded
from a more general property file.
So in your case make sure your build scripts (or IDE) copy your displaytag.properties file from src/comp/bre/sub/config the onto the classpath.
In an IDE this is normally as simple as specifying that a particular directory contains source code. In ANT just make sure the displaytag.properties file ends up in your /WEB-INF/classes.

Find the code which loads this properties file and add the new path. You can also place it in a folder yourProject/src/resources/ and add it to the classpath. Therefore, your properties file will be placed in the binary folder once the code will be compiled.