Sorry for a delay in replying. I was tied up speaking at a conference the last couple of days.
There are a few ways you can solve this...
If you don't have too many properties then they could be supplied as properties via the bin/jvmsettings.cnf like this...
But this is not ideal, a better solution is to the make the configuration a real file resource in your module. If you then deploy the module expanded rather than jarred you can just update the config file via deployment automation (or manually).
An even better way to go is to do it the ROC-way...
I would split the problem into two, have the primary module map the config resource to a named instance resource. I would have a number of different implementation modules with the named instance resource provided. I'd then have an import in the primary module for the instance space (which would all share the same identifier for the impl config space).
You can then deploy the primary to all your instances, and just supply the appropriate impl and (since the impl spces all have the same space identifier the import) they'll happily work together.
Does this make sense?
PS If you wanted to get really fancy, you could make the primary space examine the execution context (hostname, or property?) then make a specific request for a different config for each one, but still provide these in impl spaces. Contextual indirection to the config resource.