Comments on: Loading environment specific spring configurations.

By: Job

Job — Sat, 12 Sep 2009 09:54:59 +0000

EnvironmentResolver just lookups the system property that identifies the environment, i’m now on vacance but will add the code to this entry.
It is true that all environment specific contexts are being packaged. This is because we want to be able to create one war/ear file that passes by the different test environments and goes into production instead of creating a specific build for a certain environment.

But you could also put the configurations in a shared lib if you like

By: Stevo Slavic

Stevo Slavic — Thu, 10 Sep 2009 23:10:13 +0000

Example with tags was stripped off from “… use wildcards like having in data layer context…”, so I’ll rephrase that part: …use wildcards like having import resource statement reference classpath resource like following: “classpath:com/foo/bar/ctx/env-specific-datasource-config-*.xml” in an (aggregator) data layer context

By: Stevo Slavic

Stevo Slavic — Thu, 10 Sep 2009 23:02:09 +0000

Since environment resolver is needed, correct me if I’m wrong in assuming that all environment specific contexts are being packaged together in one deployment package regardless of the actual deployment environment. If my assumption is correct, it’s not same but to me this is too similar to bundling test classes with the application in e.g. production deployment unit package, only in this case these are likely different development/test environment specific contexts, but still test stuff, being packaged with production code, which IMO is wrong thing to do.

If my assumption is wrong, and there is a deployment package for each environment and each deployment package contains only one variation of environment specific context(s), then I don’t see need for environment resolver and extending Spring stuff but I do see some downsides. Why not configure build tool to have in deployment unit package for each environment these environment specific contexts either placed at same classpath location so they can be referenced in same way regardless of the environment, or employ naming convention and use wildcards like having in data layer context? I prefer former (less wildcards less flexibility but more control) so with e.g. Maven 2 as build tool together with help of maven assembly plugin one can at one go build deployment artifacts for multiple different environments, each having only what’s needed for that environment, be it configuration file or environment specific Spring context, all being referenced/loaded in same way regardless of the environment with no need to extend Spring (so less code, less potential bugs and fewer things to worry about during maintenance, like worrying what has to be done when migrating to Spring 3) and no need to configure environment variables or similar stuff for environment resolver (so easier deployment). Adding support for new environment is as flexible as in your/Joris’s solution, one just has to create new environment specific context and extend build tool configuration (in maven2 assembly case by adding new assembly descriptor).

By: Job

Job — Thu, 10 Sep 2009 09:09:17 +0000

i changed to article to link yours btw.

By: Job

Job — Thu, 10 Sep 2009 09:04:38 +0000

He Joris,

yeah i think you started this kind of solution in firm, but is worked differently with a parent context. But the basic idea is indeed from there And give me a call when you have time to drink those beers, good luck and gz in anvance.

By: Joris Kuipers

Joris Kuipers — Wed, 09 Sep 2009 11:22:44 +0000

Such a solution was first introduced in the FIRM application many years ago
I’ve also described some solutions (incl. one that’s very similar to yours) in this blog post:
http://blog.springsource.com/2007/06/25/code-samples-from-springone-beyond-the-obvious-talk/

Joris

PS When I find some time I’ll plan a date with you for those beers you still owe me Might take a while though, as I’m becoming a father again this month…