1

We have a Grails application that connects to a Documentum docbase using the dfc.jar and dctm.jar APIs. These jars expect a dfc.properties file to be on the classpath to configure the docbase settings. This is fine when working in one environment, but we are building war files for dev, test, and prod environments, each with their own dfc.properties configurations.

The Grails environment configuration works great for handling other environment specific settings within the app, but I can't figure out a way to either override the dfc.properties file on a per environment basis or configure the Documentum API to retrieve it's settings from someplace else.

I have considered having environment specific properties files and then running a shell script before each war build to copy them to the dfc.properties file, but that feels like too much of a hack. I would like to be able to just do three war builds without muddying it up copying different versions of properties files around.

 grails dev war
 grails test war
 grails prod war

Any suggestions on how to approach this multi-environment configuration issue would be greatly appreciated.

GeoGriffin
  • 1,065
  • 11
  • 26
  • Perhaps you could investigate keeping the properties file outside of the war file, but adding it to the classpath at runtime. For instance, most web servers have a location where you can put jar files that are to be shared among applications. Assuming that you have different dev, test, and prod server, the properties file could just live on the server. You'd probably need another somewhere under your Grails test directory for when you do "grails test-app". – GreyBeardedGeek May 18 '12 at 05:16
  • I think solution described in link below is applicable for your case. http://stackoverflow.com/questions/10629151/how-do-i-derive-physical-path-of-a-relative-directory-inside-config-groovy/10629778#10629778 – Aram Arabyan May 18 '12 at 09:06
  • @GreyBeardedGeek I think separating the `dfc.properties` out so that it deploys separately from the environment specific war file breaks the all-in-one nature of the war. I think that opens us up to the possibility that one version of the war deploys, but the corresponding `dfc.properties` isn't updated. – GeoGriffin May 18 '12 at 12:38
  • @AramArabyan I'm not sure if that helps. These aren't properties that are pulled in directly by Grails. Grails is using the DFC API that expects the `dfc.properties` file specifically to be on the classpath. I might be missing something from the other solution. Can you elaborate on how it might apply here? – GeoGriffin May 18 '12 at 12:43

1 Answers1

0

Add this line to the top of your dfc.properties inside WEB-INF/classes and store the externalized version outside the application server:

#include D:\Documentum\config\dfc.properties

As long as you can externalize any other environmental configurations, you will only need one war.

As a bonus, you can still include application-specific keys in the WEB-INF version if you wanted to, and it would be merged with the external copy. This way, multiple applications can be configured separately, but with, say, the same docbroker/global registry settings.

Tiksi
  • 471
  • 1
  • 6
  • 15