The problem I was having was, when on the production server, I had a properties file in my /resources folder, and I modified in on the server but noticed it was still returning the old values.
I then realized that the class loader was loading the file from the .jar itself, and not reading from the file (even though the file was updated to reflect production settings). On Wed, Apr 18, 2012 at 3:51 PM, Barrie Treloar <[email protected]> wrote: > On Thu, Apr 19, 2012 at 1:09 AM, S Ahmed <[email protected]> wrote: > > Yeah they are config files, I just wanted a simple way to reference them > in > > my code, i.e: > > > > ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); > > InputStream is = classLoader.getResourceAsStream("config.properties"); > > > > I think what I should do is reference the file based on an environmental > > variable, which I will set both locally and on the production server. > > Plus having an EV let's other projects reference things in a more uniform > > way. > > You dont want stuff that changes across different environments baked > into your builds. > > We just add the directory "./config" to the classpath and at deploy > time swap in what environment settings are needed. > (For runnable jars) > > For web apps, we use an ugly hack where the web server has a global > classpath entry pointing to a config dir. > The configs then get dropped in there. > > Both ways allow us to continue to use class loader to avoid knowing > the actual location on disk. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
