Module-specific EnvironmentProperty error

[Doug]

Hi List,

I'm trying to setup an EnvironmentProperty block in a module, so I can
define module-specific properties by environment. In a simple test, I
have copied what is in the default base Mach-II config, changed the
property name, added my own property, and attempted to load the
module. I get the following error, thrown around line 284 of
EnvironmentProperty.cfc:

An environment named 'test' is missing a required key named
'production' for the EnvironmentProperty in module 'template'.

I plan to dig further into this, but thought I'd ask the list in
parallel. It doesn't make sense because this same config works at the
base level -- the only differences are the name and the properties.

Here is what I have in the template module's properties config block:

<property name="template_environment"
type="MachII.properties.EnvironmentProperty">
<parameters>
<parameter name="defaultEnvironmentName" value="development" />
<parameter name="serverPropertyName" value="serverName" />

<parameter name="dev">
<struct>
<key name="environmentGroup" value="development" />
<key name="servers" value="localhost,local.www.daveramsey.com" />

<key name="properties">
<struct>
<key name="templateProp" value="valueInDevTemplateEnvironment" /
>
</struct>
</key>
</struct>
</parameter>
<parameter name="test">
<struct>
<key name="environmentGroup" value="staging" />
<key name="servers"
value="staging.www.daveramsey.com,dev2.www.daveramsey.com" />

<key name="properties">
<struct>
<key name="templateProp" value="valueInTestTemplateEnvironment" /
>
</struct>
</key>
</struct>
</parameter>
<parameter name="prod">
<struct>
<key name="environmentGroup" value="production" />
<key name="servers"
value="app*.www.daveramsey.com,www.daveramsey.com" />

<key name="properties">
<struct>
<key name="templateProp" value="valueInProdTemplateEnvironment" /
>
</struct>
</key>
</struct>
</parameter>
</parameters>
</property>

Thanks!

Doug
http://www.daveramsey.com

[Doug]

I found the problem ... it's a bug in EnvironmentProperty.cfc.

In configure, there is a block that is like this:

<cfif getAppManager().inModule()>
<cfset variables.REQUIRED_ENVIRONMENT_KEY_NAMES = getAppManager
().getEnvironmentGroupNames() />
<cfelse>
<cfset getAppManager().setEnvironmentGroupNames
(variables.ENVIRONMENT_GROUP_NAMES) />
</cfif>

So, in a module, the value of REQUIRED_ENVIRONMENT_KEY_NAMES is set to
the group names. Instead, that line (152) should be:

<cfset variables.ENVIRONMENT_GROUP_NAMES = getAppManager
().getEnvironmentGroupNames() />

I'll add a ticket and submit a patch.

Thanks,

Doug

[Peter J. Farrell]

Thanks for the ticket *and* contributing a patch at that. The great
part of open-source. Anyways, I verified the behavior, looked at the
patch and committed the fix. It is now fixed in the repo. Here is the
ticket that Doug submitted for future reference if some finds this in a
search:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/330

Best,
.Peter

Doug said the following on 06/24/2009 02:05 PM:

[Matthew Woodward]

Peter J. Farrell wrote:
> Thanks for the ticket *and* contributing a patch at that. The great
> part of open-source.

Just wanted to second this--thanks so much for contributing. Even just
finding a bug and letting us know about it is great, but submitting a
patch is much appreciated!

--
Matthew Woodward
ma...@mattwoodward.com
http://www.mattwoodward.com/blog

Please do not send me proprietary file formats such as Word, PowerPoint,
etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

[Peter J. Farrell]

Matthew Woodward said the following on 06/24/2009 04:07 PM:

> Peter J. Farrell wrote:
>> Thanks for the ticket *and* contributing a patch at that. The great
>> part of open-source.
> Just wanted to second this--thanks so much for contributing. Even just
> finding a bug and letting us know about it is great, but submitting a
> patch is much appreciated!

In the terms time for Team Mach-II, patches are easier for us to get an
issue fixed more rapidly because it takes less them to verify the
defect, inspect the patch, tweak and commit. No patches means we have
to figure out what the issue is first which takes more time. So kudos
to Doug (and Eli by proxy) for submitting two tickets in the past two
days with patches.

Result? Both tickets are already fixed and in the repository for
Simplicity (1.8). Not that we can guarantee turn around like that for
everything, but for straight forward tickets regarding simple things
with attached patches are the bee's knees. Try to get that kind of
defect fix service with proprietary software even with paid support! ;-)

.pjf