Al, Give this a go.
http://www.brucephillips.name/blog/index.cfm/2008/1/1/The-Grade-Schoolers-Guide-To-ColdSpring--Part-3-Providing-Default-Values-To-ColdSpring On Wed, Apr 22, 2009 at 12:58 PM, Al <[email protected]> wrote: > > ANT is, unfortunately, not currently an option. (I'm trying to get us > there, but there's only so fast I can turn this ocean liner, and I'm > not the only one at the wheel.) > > Is there a way to import information into Coldspring.xml? > > On Apr 22, 10:10 am, Doug Hughes <[email protected]> wrote: > > Al - > > > > I think you're headed in the right direction. Essentially, what you're > > saying is that your configuration settings need to change in your > ColdSpring > > XML as you deploy from development to staging and production. > > > > The way we tend to handle that at Alagad is to keep the development > version > > of ColdSpring.xml in our SVN repo. So, the developers would always use > the > > development version of the ColdSpring config. (There are gradiations on > > this, but they're not really relevant to your question.) > > > > We then automate the deployment process to staging and production using > > Ant. As a part of the deployment process we modify the ColdSpring > > configuration to use our production settings. > > > > So, for example, if we had a component for sending email we might have > two > > objects configured in coldspring, an EmailSender and a MockEmailSender. > In > > development anything that needed to send email would use the EmailSender. > > When we deploy to staging or production we might replace instances of the > > MockEmailSender with EmailSender. Actually, in all honesty, I simply > don't > > configure the mail server in development and look in the undeliverable > mail > > folder to make sure messages are getting created correctly. However, > there > > are other instances where settings need to change between development and > > staging or production and we use Ant to make those settings. > > > > In particular, we tend to use CFAnt as a part of our Ant deployment > process > > so we can make settings changes to the ColdFusion server as well. For > > example, we can configure datasources, turn on trusted caching, clear the > > template cache, configure event gateways, start them, etc, all from one > > script. And, because it's Ant, running it from Eclipse is really, > really, > > easy. > > > > I hope that helps! > > > > Doug Hughes, President > > Alagad Inc. > > [email protected] > > 888 Alagad4 (x300) > > Office: 919-550-0755 > > Fax: 888-248-7836 > > > > > > > > On Wed, Apr 22, 2009 at 9:46 AM, Al <[email protected]> wrote: > > > > > I'm wondering how people manage differing configuration settings for > > > the same app in different environments. > > > > > Let me expand on what I mean. > > > > > We have three tiers of servers: DEVELOPMENT, TEST, and PRODUCTION > > > (hereafter D, T, P). For each of our applications we will have > > > settings that vary based on environment. For instance, we may have a > > > "test e-mail" to trap any outgoing e-mail and re-route it to the > > > address in the setting rather than letting it go to the actual > > > recipient. (Helps prevent messages being sent to live people from an > > > app being tested.) In D that would probably be set to the development > > > team, in T it would be set to the test team, and in P it would be > > > NULL. Every app has a couple or half-dozen such settings. > > > > > In the past, MG1.1, I'd create three separate ModelGlue.xml files and > > > they'd each have differences in their CONFIG blocks, but everything > > > else would be the same. (They would be renamed to ModelGlue.xml on > > > each server during deployment.) That worked okay, but it meant that > > > whenever an event-handler or message-listener got changed, I'd have to > > > change three files. Not the end of the world, but we did have cases > > > where people with less attention to detail forgot to change the > > > production version, for instance. > > > > > I then started using GetModelGlue().GetConfigBean() and having only > > > one version of ModelGlue.xml and a config.xml for each of my three > > > environments. A little more work, but I only had to change all three > > > if I was adding a configuration setting; the application plumbing was > > > just the one file. That works much better. > > > > > However, I'm now forging ahead with developing using MG2. > > > Configuration settings are in Coldspring.xml. That's fine, but I'm > > > also looking to leverage Coldspring's power to define my components. > > > Obviously, they'll be the same no matter what environment the > > > application is in, but the config blocks will have to differ. This > > > puts me back to the same basic problem I had with the versions of > > > ModelGlue.xml for each environment. > > > > > So, before I go too far down the rabbit hole, what do other people do > > > to manage multiple configurations of a single application?- Hide quoted > text - > > > > - Show quoted text - > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
