I'm currently developing an application which requires access to an API with credentials. I didn't want to put them hard coded in the application so I created a configuration.properties file for them.
At the moment this file is located in src/main/resources and access it with the following code.
<context:property-placeholder location="classpath:configuration.properties" ignore-unresolvable="true" />
This means that if I change something in the configuration I need to redeploy the WAR.
My question is: Where do I put this configuration file so that I don't need to redeploy in case of a change in the configuration?
I don't want to put it somewhere random on my computer so that I can share my code with other people without to much trouble with the file's location.
I solved it by placing my properties file in Tomcat "D:\Documents\workspace.metadata.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps"
And Access it with the following property-placeholder
<context:property-placeholder location="file:${catalina.base}/conf/configuration.properties" ignore-unresolvable="true" />
I think you're already close.
I agree its a good way to have one .war file and reuse it everywhere without adopting it to a specific environment. That means you cannot include it in the .war
What I would do is creating configuration zip files with the assembly plugin (if there are multiple variations). For example from /src/main/config/env1
Then use an environment variable to point to that folder.
The property placeholder configurer thing in spring then references that location through that system property instead of the classpath:
these zip files can be used to be deployed with the .war file (via ssh using the ant runner plugin or some other way)
That can also be used for the logging configuration. Spring has a resolver that will even reload the log config if you change it on the file system.
Related
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.
I'm new to Java (around 2 months Java experience after coming from a .Net background). I've been asked to support a Java application which uses Spring, J2EE, and an Oracle database.
We have an issue with our deployment process which I'm struggling to understand.
The Java application in question has database connection details in an application.properties file. Its location appears to be configured from a Spring configuration file using the following line:
<context:property-placeholder location="classpath:config/application.properties,classpath:config/bookings.properties" ignore-resource-not-found="true" />
On our Development Tomcat server, the application (called Bookings) looks in this location for the application.properties file:
/usr/share/tomcat/webapps/Bookings/WEB-INF/classes/config
Which is what I would expect, looking at the Spring configuration.
However, on Production Tomcat, the application looks in a different location:
/usr/share/tomcat/lib/config
(In this directory, the file is called bookings.properties.
The original developer has left the company and I have no idea why it would look in a different location for the file (and a different filename).
Any ideas what I can look at, or where this could be configured? It should be noted that both files (application.properties and bookings.properties) are present on both Tomcat servers, so I don't understand the discrepancy?
We have re-deployed the same WAR file to both development and production, and the discrepancy still exists, i.e. the servers still look in different places.
classpath is a directory where you could put some resources (to make it simple, further details on the link).
that's a variable and it's added to the launch command, sometimes it's a bit hidden. But that's the way it works.
May be you can watch in $TOMCAT_DIR\bin\catalina.sh to see how the classpath is defined.
In your case, the folders contained in your classpath are different between development server and production server. That's totally normal.
However, you say that in production the file is named bookings.properties.
But with this line :
<context:property-placeholder location="classpath:config/application.properties,classpath:config/buyer-request.properties" ignore-resource-not-found="true" />
we see that you never try to load a file named booking.properties.
So ask yourself why the file is called booking.properties. And rename it application.properties to see what happen.
Hope this help
I am trying to use jpa/hibernate framework with a simple java console application without a container. According to jpa documentation the persistence.xml file should be placed under the folder META-INF on the src folder.
The issue came when trying to package the application as a simple jar file then the persitence.xml file will be within the jar file generated (since it should be placed on the src folder).
In this situation the persistence.xml file is not easy accessible to modify the application configuration like the DB URL, time out,the hibernate logs...
I tried to put the META-INF/persistence.xml outside the src folder and added it to the CLASSPATH but an error saying Could not find any META-INF/persistence.xml file in the classpath is always thrown.
Is there any way to keep the persistence.xml editable and accessible once the application is packaged and deployed on production like any other classic configuration file (eg .properties files).
Thank you
I think you don't need to make persistence.xml editable since you can provide additional properties when calling Persistence.createEntityManagerFactory() (or using similar Hibernate-specific mechanisms).
So, you can use persistence.xml for static configuration only, and configure dynamic properties using your own configuration mechanism.
How can I load the configuration information for hibernate dynamically from a config file. Netbeans currently hard codes that information into an xml file that is then compiled into the jar. I'm a newbie to Java/Netbeans coming from PHP land and am use to a central bootstrap that pulls from a .ini or something similar, but netbeans tends to hardcode this information upon generation of the models,etc in an xml file that is then compiled in the jar. I'm looking for conventional methods of setting up configuration for various client machines using various database configurations. I don't want to have to compile the app on each machine it must be installed on.
The configuration file is read using the Configuration class. By default, it uses the hibernate.cfg.xml file found in the classpath, but you can use the configure method taking a file as parameter, and store the config file on the file system rather than in the jar.
You can also put the static mapping, which never changes between configs, in a file inside the jar, and put the varying config inside an external file. Look at the javadoc for Configuration to know how to add resources and config files to the configuration.
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">