• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Keeping the properties outside the build

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


We are migrating the legacy application in spring hibernate.we have use maven for dependency management.My structure of the application is as below currently

src/main/java -> java file
src/main/rersource-> all properties file
src/main/test-> all test cases

After creating the war and deploying in a tomcat. The  application is running fine.

Now problem is

We want all these resources  not to be as part of build because we have separate team who will responsible for changing properties like  hibernate database passwords and database url etc...
Developer will just checked in the code in bitbucket and jenkins will create war and deploy in tomcat.

Other Team will have liberty change the those properties.

Q1)How can i referred external properties from war file?





 
Saloon Keeper
Posts: 15488
363
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your application's context XML, add an Environment element that specifies the path of the configuration file that holds all settings for the environment in which your application is running. You can use a JNDI lookup to get this file path, and then just read the file like you would normally.

Let's say your environment specific configuration file is located at /etc/opt/myapp/environment.properties. You can then add the following entry in your application's context XML:

Get it in your application like this:
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do what Stephan said. This is how I build all of my webapps.

I have 2 fundamental and virtually inviolable rules for my applications

1. It should be possible to build a production-ready unit without using an IDE. Usually that means I use Maven, but sometimes Ant, Gradle, or whatever.

2. The exact same byte-for-byte WAR/JAR/EAR should be installed in production as was used for development and testing.

To do that, I do as Stephan has outlined and put my environmental information in Tomcat's JNDI dictionary.

Note that in the case of database connections, you should be using Tomcat database connection pool, so in that particular case, you should never have coded the connection URL, database user ID or password in the webapp at all. If you were placing pool meta-data or other configuration elements in a META-INF/context.xml file in the WAR, that's OK for development, but then you'd override that using the production server's Context element used to deploy the webapp.
 
sat kadam
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I kept my path as below is tomcat context.xml



in java code





This throws nullpointerexception while reading.Please help what is wrong


 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You would use the class loader if you want to get a static resource that is bundled with your application. The properties file is not bundled with your application, it's placed in each environment separately by an administrator (the entire point of this topic). Use Files.newInputStream() or Files.newBufferedReader() to open the file.
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, I don't recommend creating file paths using "directory+filename". It can lead to problems when people forget the file delimiter.

A better approach is "new File(directory, filename)". This is OS-independent, which can be useful if you develop on Windows but deploy to Linux servers (or, as I used to do, Solaris servers), and you don't have the confusion that can come if someone forgets that trailing "\".
I believe that you can create an inputstream/reader straight from the File object, but if not, the complete path in text format can be obtained via its getAbsolutePath() method. Which is also handy if you want to report the path in your logs

Also, I recommend coding Java file paths in the universal format ("C:/opt/apps/ukuatt/sharedlib/properties"). That way you don't get clobbered if you put them some place where you need doubled backslashes.

You should be able to name your environment entries like this: "env.commons.loggings.grp.propertiespath", which is both easier to read and more like how you'd do it in a properties file.
 
Bartender
Posts: 1152
20
Mac OS X IntelliJ IDE Oracle Spring VI Editor Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The exact same byte-for-byte WAR/JAR/EAR should be installed in production as was used for development and testing.



I've worked on a few projects where the customer has had one company hosting the solution, and others developing the software.
On these projects the environment configuration (properties) has to be outside of the main artefacts (EAR/JAR).

Of course, when issues happen (and they always do) the blame game; its your environment against no its your software!  
 
sat kadam
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks all for response.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic