= Proposal title = || '''Date''' || 2011/05/25 || || '''Contact(s)''' || Jesse Eichar (Camptocamp SA)|| || '''Last edited''' || || || '''Status''' || Motion passed || || '''Assigned to release''' || 2.7.0 || || '''Resources''' || Available || || '''Ticket #''' || #513 || == Overview == In order to permit deployment of a Geonetwork instance to multiple environments and assist in development this proposal adds the ability to configure geonetwork for multiple target deployment platforms (for example, test and production) with a minimum of duplication and allow configuration selection to be chosen via System properties or !ServletConfig/Context parameters. === Proposal Type === * '''Module''': Jeeves === Links === * '''Documents''' * '''Email discussions''': * '''Other wiki discussions''': === Voting History === * Vote proposed by Jesse Eichar on 31 May 2011, result was +1 Simon and Jeroen, +0 Francois. ---- == Motivations == In many organizations that deploy geonetwork instances geonetwork needs to be deployed in several different environments. For example if one is making a customized geonetwork one might have a test server and a production server. Obviously they cannot share the same resources so the configurations of the two servers are likely very similar but with a few key differences. Currently you essentially need different configurations depending on which environment you are deploying to. The pain can be somewhat alleviate by extracting the changes into separate files and using include tags to import them. However this can require fairly substantial changes to the default geonetwork configuration files and if one is attempting to follow the Geonetwork development it can mean conflicts with the geonetwork configuration files when merging in changes from a new version of Geonetwork. In addition there are certain types of changes one may want that cannot be accommodated by using the import strategy. == Proposal == As such I propose a new method for handling multiple deployment platforms. The standard configuration files contain the default settings and multiple override configurations can be defined to override certain parts of those defaults. The override that is applied can be selected via one of System properties, !ServletConfig initial parameters or !ServletContext initial parameters. So depending on the server/environment where the geonetwork is deployed a different configuration can be selected with minimal duplication of configuration. The parameter/property that is checked for the definition of the override file is '''jeeves.configuration.overrides.file'''. If the property is not found then the no overrides are applied to the default configuration. The following is an example of a override file: {{{ #!xml logfile1.properties logfile2.properties fr ${fr} localhost true xml main-db jeeves.resources.dbms.DbmsPool admin admin oracle.jdbc.driver.OracleDriver jdbc:oracle:thin:@${host}:1521:fs 10 ${lang} ExtraText de }}} As this example indicates the primary tags of interest are: logging - defines the log files to use as log4j configuration files properties - defines common properties throughout the override file - defines the file the override segment applies to replaceAtt - defines a override that updates an attribute of a particular node replaceXML - defines a override that replaces all children of a particular node replaceText - defines a override that sets the Text of a particular node addXML - defines a override that add xml as children of a given node removeXML - defines a override that removes XML from a node === Backwards Compatibility Issues === 100% backwards compatible === New libraries added === No new libraries. == Risks == == Participants ==