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?
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.
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!
Villains always have antidotes. They're funny that way. Here's an antidote disguised as a tiny ad:
Devious Experiments for a Truly Passive Greenhouse!