We Keep Coding

Get absolute path to project directory in application.properties

I am writing a Quarkus application which reads data over http. In my application.properties file, I have this line:
my.resource=http://path/to/file
Every time I run the app, it has to download the file so I created a smaller version of the file locally for developing purpose. The problem is that I don't know how to put it in the properties file.
Ideally, I want something like this:
my.resource=http://path/to/file
%dev.my.resource=file://${project-dir}/sample_data/file
And I have to use the absolute path because I used new URI(resource).toURL() method which requires an absolute URI.
Thanks in advance.

Application properties is something that is used when your application is deployed to adopt your application to the target environment, does the user of the deployed application know anything about project directory? Project directory is something that makes sense when you are developing your application. having said that using project directory in that file does not make sense at all.

Edit Java Configuration File inside WAR in Tomcat

I compiled a Java application into a WAR file, there is a configuration file inside the WAR file. The configuration file is required to change something after deployed to the production server, because it still contains the UAT server parameters.
However, I don't know where to edit the configuration file after deployed in Tomcat. Please help. Thanks.

It doesn't sound like a correct design. You should -
Load configuration file based on some System parameter (e.g. -Denvironment=UAT or PROD). This will be the decision factor for loading the right configuration file.
Do not package the file inside war itself, if possible externalize it to some other directory where amending is lot easier.

Wildfly Deployment going to temp folder

I am facing a little strange issue while deploying web service to WAR file.
If I deploy the application via Netbeans IDE it is going under \standalone\deployments directory.
However, if I deploy the war file from Admin Console it is always getting deployed at \standalone\tmp directory.
Please guide on this issue. The deployment should go under \standalone\deployments directory only.

The deployment should go under \standalone\deployments directory only
You are quite not right.
It is not an issue. It is what it is.
standalone/deployment folder stand there only for "hot-deployment" functionality available only with standalone mode.
So, Netbeans uses it. You can do the same just by saving EAR or WAR into standalone/deployment and server will pick it. (default scan interval is 5 sec.)
but Admin console or CLI is only (and standard) way to deploy application on domain. In domain mode deployment folder is not in use and there is no deployment scanner.
Then when you use console it goes common way - deploys as on domain regardless is it domain or standalone server.
Updated / follow-up:
In general it is better to keep .properties file(s) out of deployment, in separate location. It is main idea behind them - to be able to change properties without application rebuilding and redeploying. Usually properties are different in different environments (DEV/UAT/PROD)
So there are 2 most popular solutions:
store properties in different location add that location to class path and access them through ClassLoader.getResourceAsStream() mechanism
store properties in different location, pass that location through system (or -D) variable and access them as file. for JBoss you can place your .properties under configuration directory. there is already JBoss variable. Kind of jboss.config.dir (or such, you can find it in Admin console, I do not have JBoss right now).
But of course sometime it still needed to access resources inside WAR/EAR - in that situation it is pretty much the same as first solution above.
Just be sure your .properties file(s) are accessible through to ClassLoader (in class path) and use them from ClassLoader.getResourceAsStream (or if you use Spring point it as "classpath:" not as "file:".

Java: Accessing properties file inside a war

I already searched StackOverflow for "properties inside war", but none of the results worked for my case.
I am using Eclipse Galileo and GlassFish v3 to develop a set of web services. I am using a "dynamic web project" with the following structure
Src
-java_code_pkg_1
-java_code_pkg_2
-com.company.config
--configfile.properties WebContent
-META-INF
-WEB-INF
--log4jProperties
--web.xml
--applicationContext.xml
--app-servlet.xml
I want to access the "configfile.properties" inside one of the source files in "java_code_pkg1". I am using the Spring Framework and this file will be instantiated once the application starts on the server.
I have tried the following with no luck
getResourceAsStream("/com.company.config/configfile.properties");
getResourceAsStream("/com/company/config/configfile.properties");
getResourceAsStream("com/company/config/configfile.properties");
getResourceAsStream("/configfile.properties");
getResourceAsStream("configfile.properties");
getResourceBundle(..) didn't work either.
Is it possible to access a file when it's not under the WEB-INF/classes path? if so then how?

Properties props = new Properties();
props.load(this.getClass().getResourceAsStream("/com/company/config/file.properties"));
works when I'm in debug mode. I can see the values in the debugger, but I get a NullPointerException right after executing the "props.load" line and before going into the light below it.
That's a different issue. At least now I know this is the way to access the config file.
Thank you for your help.

If you are in a war, your classpath "current directory" is "WEB-INF/classes". Simply go up two levels.
getResourceAsStream("../../com/company/config/configfile.properties");
It is horrible but it works. At least, it works under tomcat, jboss and geronimo and It works today.
P.S. Your directory structure is not very clear. Perhaps it is:
getResourceAsStream("../../com.company.config/configfile.properties");

Check the location of the properties file in WAR file.
If it is in WEB-INF/classes directory under com/company/config directory
getResourceAsStream("com/company/config/configfile.properties") should work
or getResourceAsStream(" This should work if the config file is not under WEB-INF/classes directoy
Also try using getClass().getClassLoader().getResourceAsStream.

Are you sure the file is being included in your war file? A lot of times, the war build process will filter out non .class files.

What is the path once it is deployed to the server? It's possible to use Scanner to manually read in the resource. From a java file within a package, creating a new File("../applications/") will get you a file pointed at {glassfish install}\domains\{domain name}\applications. Maybe you could alter that file path to direct you to where you need to go?

Since you are using Spring, then use the Resource support in Spring to inject the properties files directly.
see http://static.springsource.org/spring/docs/3.0.x/reference/resources.html
Even if the class that requires the properties file is not Spring managed, you can still get access to the ApplicationContext and use it to load the resource
resource would be something like, classpath:settings.properties, presuming that your properties file got picked up by your build and dropped in the war file.
You can also inject directly, from the docs:
<property name="template" value="classpath:some/resource/path/myTemplate.txt">

How to differentiate between test and production properties in an application?

We're developing a big J2ee e-sales solution. It's got a lot of integrations: CMS, ERP, Mail server etc. All these systems are divided into test and production environments.
We need to deploy our application to our test servers with test configuration and when deployed to our production servers it should use the production configuration. How do we make our application select the correct properties?
The thing we've tried so far is this:
All our property files contain test properties and production properties
test.mvxapi.server = SERV100TS
test.mvxapi.username = user
test.mvxapi.password = password
test.mvxapi.port = 6006
test.mvxapi.cono = 600
mvxapi.server = SERV10001
mvxapi.username = user
mvxapi.password = password
mvxapi.port = 6001
mvxapi.cono = 100
The Util that reads these properties has a switch: isTest() which prefixes the key with "test."
public String getProperty(String property)
{
return properties.getProperty(prefix + "" + property);
}
The switch is set by another property which is created by our build server. When the .EAR is built the script for our production servers injects (input to build.xml) "isProduction=true" into system.properties.
<propertyfile file="${buildDir}/system.properties">
<entry key="isProduction" value="${systemType}"/>
</propertyfile>
I'm not sure this is the best way to do it. If for some reason "isProduction=false" is committed wrongly to our production environment all hell is loose.
I've read people have properties locally on the server. But we really don't want to have files spread around. We have cluster of production servers. Making sure every server has the right property file doesn't seem fail-safe

What you want to avoid is having the config file inside the EAR, the problem with this is that you need different EAR's for different environments, and also, changing the config file requires a rebuild.
Rather deploy the same EAR to every server but configure each server with a different URL resource. iow, add a JNDI URL resource to all the servers you deploy to that point to the config file for that resource. If you have read only SVN access to your repo then create the config files on the svn repo, or any repo you can access via a URL. The cool thing here is that all your configuration is centralized and thus managing them is easy.
What I've done (by customizing with spring) is make sure that JNDI URL resource optional. So, if it's there, the app will use it, if not, it won't. The app starts up whether it's there or not. That way, even when running with no JNDI resource available, the app still works (development environment for example).

You deploy an EAR? Then put the properties needed in JNDI.

I can't say if this is the best way, however, what we do is include a client and server jar which houses the properties accordingly. We then include those jars in the EAR file. So during our build process we include the appropriate (QA, TEST, PROD) jars for the environment in which we are deploying to.
The downside is we have to manage three sets of environment jars and the build team has to be careful not to deploy the incorrect one. In fact, it has happened once that we had a PROD jar deployed to our QA environment and QA data was getting put into production....yes that sucked and was a major mess to clean up.
I will be watching this discussion because I often wonder how we can make this process better/safer. Great Post +1

In a previous J2EE project, we've been doing exactly that. The build process (an ant script) put together the right config files, added them to a certain jar which was then put into the EAR file for production environments, test, training, QA, etc.
The file name of the EAR file contained the name of the target environment, so it was basically impossible to deploy a file to the wrong environment. If we built for target 156p2 (factory 156, production env. 2), this would be part of the file name of the EAR file and ant would include config_156p2.xml. If the target was incorrect, the EAR file's name would be wrong and as a last failsafe the guy who deployed it would notice.
The build file had to contain this: one ant target to start the build for each environment which would set a property that told ant which config file to include.
The only difference between the EAR files would then be the config files. Everything else was identical. There is a possibility, of course, that someone might have written a wrong value to a config file for a certain environment. However, in practice this never happened in several years, even with some pretty junior developers and about fifteen target environments (different test, QA, training and production servers in different countries).

We have 3 folders for this purpose in our projects, each one contains configuration files (filenames are the same between the folders):
personal: contains paths to test db, server, etc
test: contains paths to the servers shared with my colleagues
production: contains... well you guessed
When I build my project I add the suited profile to Intellij Idea project build, in the desidered module, this basically means that i am adding a different folder to the project structure, but because filenames are the same what changes are only profile properties.

Very old post still responding in case someone checks it. In each application server you can set System properties e.g
Wildfly Management Console --> Configuration --> System Properties
There I add a variable SERVER_ENVIRONMENT with value as DEV/UAT/PROD.
In my java code I use:
System.getProperty ("SERVER_ENVIRONMENT")
which gives me value from the server.

Like #Alberto-Zaccagni said you can have separate folders with properties files that exist only in respective environment. Your code checks for existence of folder starting with PROD then UAT then DEV and when it finds a path exists it uses the properties files there.