I am deploying artifacts with configuration files as well. I have
different config files for each production server, so I am creating a
different artifact for each production server with the proper config files.
I create a generic war and then overlay it, adding the config files for
each production site. Just a thought for you.
On Wed, Apr 18, 2012 at 2:14 PM, S Ahmed <sahmed1...@gmail.com> wrote:
> 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 <baerr...@gmail.com>
> wrote:
>
> > On Thu, Apr 19, 2012 at 1:09 AM, S Ahmed <sahmed1...@gmail.com> 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: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
