We use something similar in our system. The system uses a bunch of resource bundles that are separated into logical domains, and each entry can be overridden by a local file on each machine. Plus each entry can be scoped by environment (production, test, development), machine, or application name (in case multiple applications are sharing a library component). We have log4j and spring configurers so that it is tightly integrated into the tools we use. It's saved us an eternity of time tracking down bugs from one environment to the next since we deploy the same WAR file that was accepted by the quality assurance group into production and let the configuration take care of itself.
I've often thought of creating a Google Code project to open source it, but wasn't sure if there would be enough interest. (*Chris*) On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > Yeah, I found that environment resolution was a key feature for any large > application. At Orbitz we could deploy the same bundle to any server and the > bundle would figure out where it was and configure itself for that > environment. Worked really well. > > I have also provided this type of feature in JCatapult using an API that can > be implemented however developers need. The default implementation uses > JNDI, but it is simple to change it. The nice thing about that is you can > assume at all times that the environment is available and make assumptions > around that. > > -bp > > On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote: > >> We d something similar as well, but we decided to use a simple env var in >> all environments... So the exact same EAR can deploy to any environment and >> the code within simply looks for that var and acts accordingly. Simple but >> highly effective. >> >> Frank >> >> -----Original Message----- >> From: Ian Roughley <[EMAIL PROTECTED]> >> Sent: Friday, June 27, 2008 2:59 PM >> To: Struts Developers List <dev@struts.apache.org> >> Subject: Re: environment awareness (project stage in JSF) >> >> I've actually had to implement this type of feature in multiple >> enterprise applications. However, I would say that it's not knowing the >> environment, but being able to change configuration elements per >> environment that is important (for what I did, and in rails I think this >> is the most important elements). i.e. change the SMTP, temp file dir, >> admin user email address, etc. depending on whether you are testing >> locally vs. production. >> >> If developers are using spring, there is a way to load property files >> with a hostname extension (which is one solution) - but should we always >> expect users to be using Spring? The other question is being able to >> modify struts.property properties depending on env (i.e. devMode=true in >> development and never in production). >> >> /Ian >> >> Antonio Petrelli wrote: >>> >>> 2008/6/27 James Holmes <[EMAIL PROTECTED]>: >>> >>>> http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 >>>> >>>> I like it. This is one of the features of RoR that I really found useful >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
