aspose file tools*
The moose likes Other JSE/JEE APIs and the fly likes Replacing propeties files inside jars with outside files Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Other JSE/JEE APIs
Bookmark "Replacing propeties files inside jars with outside files" Watch "Replacing propeties files inside jars with outside files" New topic
Author

Replacing propeties files inside jars with outside files

Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
This is a very newb question, but even today I don't know best practices about it lol

I know our code can use Class.getRersourceAsStream() to read these files. In example,



I don't like to bundle properties inside jars. DB configs for example, it's not good to have passwords there.

But in other situations, it's good to have a properties file with default values as example for user. But on the other hand, I don't want jar to be changed if these files must be edited.

Is there a way, for example, to place another config.properties somewhere, and it be read by getResourceAsStream() instead of the bundled one?
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10384
    
    8

Check out Java Preferences


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
It seems to not solve my concern.

Properties is good enough for simple configs, and if I need some more sofisticated I just use XML.

My problem is having a default file inside JAR - it has standard name, based on project's name -, and be able to identify if there's another file outside of it - preferably in the same folder the JAR is - and give preferance to it, ignoring then the bundled one.

The best I could find is doing this:

1) put a project_bundle.property in src folder, this file will be bundled in jar's root when deployed
2) first try to read
3) if null==inputStream, try to read

This way I'm able to give it a try to the external properties file, and if it's not found I use he bundled one.

But is there a more elegant way, so that I can bundle a project.properties inside jar but use an external project.properties if it's available?
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10384
    
    8

Hikari Shidou wrote:It seems to not solve my concern.

Care to share why you think so?
Inside/outside are jar, or more specifically jar location specific (especially the external properties file) and thus error prone. Imagine a scenario where someone moved your jar but not the external properties file. In case of preferences, it does not matter.
Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
As I said, because Properties is good enough for for me in simple configs, and if it gets more complex I just use XML.

My need is related to having a bundled file with default values, and allowing to use an external one for custom values, without having to mess in jar file.

The issue is not related to format used, it's about finding the correct file. The problem is that getResourceAsStream() gives preference to bundled file and ignores if there's another one in the same path as the jar (more precisely, if there's another one in classpath). It searches first inside jars, I need something that searches first in jar's folder.

For now I'm using this code:




Being configFileName = "project.xml", it does the following:

1) Uses default getResourceAsStream()
2) If not found, searches in PATH
3) If not found, assures to search in Working Directory
4) If really not found, simply uses "bundled.project.xml", which is the file added to jar's root
5) If Jar is corrupted or badly generated, it throws Exception with the filename



My main need is to not touch jar file after it's generated. It's baselined, it shouldn't and mustn't need to be edited at all. The advantage is that allows to quickly compare production jar file with the one baselined in Repository.

In my team ppl use to put in production codes that weren't commited to Repository, they mess in jar files and files extracted from wars. It's sad, and they also LOVE to edit jars' config files. It's their standard practice to edit a jar everytime a config must be changed. So I wanna create a better solution, but couldn't find an international best practice one regarding config files deployment.

This code I created is good in the way that config files are still bundled in jars and at the same time does extensive searches for external files. But it's kinda big and a bit complicated, and also requires bundled file to have different name from custom one.

If I could just get getResourceAsStream() to search outside before searching inside jar!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Replacing propeties files inside jars with outside files