Since you are new to ColdSpring with MG, I thought I would pass this
CS configuration snippet to you:
<bean id="AppConfig" class="ModelGlue.Bean.CommonBeans.SimpleConfig">
<property name="config">
<map>
<entry key="dsn"><value>myDSN</value></entry>
<entry key="dsu"><value>DSuser</value></entry><!--
datasource username -->
<entry key="dsp"><value>DSpass</value></entry><!--
datasource pass -->
<entry
key="uriroot"><value>http://localhost:8500/liantcm/</value></entry>
</map>
</property>
</bean>
This is good place to keep such settings for MG apps. You'd then pass
your configuration bean into other beans (CFC instances) managed by
ColdSpring and injected into ModelGlue like this:
<bean id="HerbGateway" class="liantcm.model.HerbGateway">
<constructor-arg name="appConfig">
<ref bean="appConfig" />
</constructor-arg>
</bean>
Here's an article I wrote on autowiring in MG, if that something you
also need to get up to speed on:
http://aria-media.com/blog/index.cfm/2006/9/22/The-Mystery-of-AutoWiring
Unfortunately the comment spammers took over my blog and I haven't
found the time to upgrade / transfer / and lock it down again. So I
haven't blogged in a long time!
On Wed, Apr 22, 2009 at 3:46 PM, 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?
> >
>
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 76 303 4477
[email protected]
--~--~---------~--~----~------------~-------~--~----~
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 .
-~----------~----~----~----~------~----~------~--~---
