Custom PropertyEditor for Resource

[Marten Deinum]

The problem with the second approach is that you aren't deploying the same to your Test, Acceptance and Production environment. You have to recreate the artifacts and this can be troublesome in some businesses.

There is actually a third option, which is part option 1.

3) Specify a system variable which points to the configuration directory (i.e. config_path) and reference this from your PPHC.

<property name="location" value="${config_path}/jdbc.properties" />

That way you can deploy the same war/ear/.... to the server and only have different properties files, stored in a path configured at the server.

[denis.zhdanov]

The problem with the second approach is that you aren't deploying the same to your Test, Acceptance and Production environment. You have to recreate the artifacts and this can be troublesome in some businesses.

The main point here is that all delivery units have the same codebase but different settings. Agreed that that may be inappropriate for particular situations.

There is actually a third option, which is part option 1.

3) Specify a system variable which points to the configuration directory (i.e. config_path) and reference this from your PPHC.

<property name="location" value="${config_path}/jdbc.properties" />

That way you can deploy the same war/ear/.... to the server and only have different properties files, stored in a path configured at the server.

Good point!

[Marten Deinum]

Well I worked for a lot of banks and insurance companies and they just don't like it if you need to build a new artifact when you move to a new server (Test/Accept/Production). They just want to copy the war/ear to the new server, maybe edit a properties file for different datasource/jms settings but that is it. The codebase has to be the same because that is the one that has been tested by the test department. Next to that it also saves you 2 build cycles and if you have CI in place they can just grab a nightly build and test it if they want.. .

[denis.zhdanov]

Well I worked for a lot of banks and insurance companies and they just don't like it if you need to build a new artifact when you move to a new server (Test/Accept/Production). They just want to copy the war/ear to the new server, maybe edit a properties file for different datasource/jms settings but that is it. The codebase has to be the same because that is the one that has been tested by the test department. Next to that it also saves you 2 build cycles and if you have CI in place they can just grab a nightly build and test it if they want.. .

I can say that Deutsche Bank is ok to the different deliveries per platform

I don't say that your approach is worse, I just say that every approach has pros and cons.