<rdf:RDF
    xmlns:s='http://snipsnap.org/rdf/snip-schema#'
    xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
    xml:base='http://knowhow.amazers.net/rdf'>
    <s:Snip rdf:about='http://knowhow.amazers.net/rdf#dev/java+tips/Multi+statging+or+environment+configuration+in+java+projects'
         s:cUser='maz'
         s:oUser='maz'
         s:mUser='maz'>
        <s:name>dev/java tips/Multi statging or environment configuration in java projects</s:name>
        <s:content>1 Multi statging/environment configuration in java projects (using spring)&#xD;&#xA;In a typical software develoment project there exist a set of environments in the development life cycle. Typically the developer will write his code on his local system and test it. On a second stage on a development environment the result of the whole team will be intergrated and testes. On a QA-Environment (Quality Assurance or also known as User Acceptance Test (UAT)) the customer will test the software and approve. Finally on the production environment the software will be used by all intended user. In some teams/companies there might exist lot of more stages and environments to fullfil their requirements on the software development process.&#xD;&#xA;&#xD;&#xA;But it is common that among the general configuration items every single environment needs its very special configuration items. (i.e. database connection, legacy host address, etc.).&#xD;&#xA;&#xD;&#xA;This article will discuss a method as a best practice to be considered in modern software projects. The method at all is not bound to any technology or framework. But we will show a customization for java based webapplication projects using spring framework.&#xD;&#xA;&#xD;&#xA;1.1 Inbound / Outbound environment configuration&#xD;&#xA;The worst case and error prone case is that for every environment a seperate package is built with manual changed configurations. In this case it might be that by mistake the development system will access the production database or the the production database will read from the qa database.&#xD;&#xA;&#xD;&#xA;One possible easy solution would be to define a single location for the environment dependent configuration outside of the project (named herebey a oubound environment configuration) and always load the configuration in the code from this place:&#xD;&#xA;&#xD;&#xA;i.E.: ~~/etc/conf/appl1/jdbc.properties~~&#xD;&#xA;&#xD;&#xA;Although this is a valid solution, there is a big drawback that makes it not the best solution:&#xD;&#xA;&#xD;&#xA;The development team needs to take care that in case of changes all environment dependent configurations on all platforms are changed. But they do not have maintain this files by themselves. So configuration errors  are likely to happen. And it might also be that the same server/filesystem is used for more than one stage / environment.&#xD;&#xA;&#xD;&#xA;The author likes more the __inbound configuration__ method, where all configuration items are maintained as part of the project and populated to all systems. As in some cases it might be the case that the development team is not allowed to maintain the production configuration, a mix of inbound and outbound environment configuration is useful.&#xD;&#xA;&#xD;&#xA;&#xD;&#xA;&#xD;&#xA;1.1 Environment Definition {anchor:envdef}&#xD;&#xA;Every environment where the software will be run, needs to define clearly it&apos;s stage or environment name.&#xD;&#xA;&#xD;&#xA;This can be done by setting environment variables or other kind of configuration. As the value it should be used the environment name as defined by the configuration directories in the next chapter. (i.e. setting java properties: ~~-Dapp.env=__dev__~~)&#xD;&#xA;&#xD;&#xA;1.1 Embedding the configuration files&#xD;&#xA;Within software projects it is common sense to have a ~~conf~~ directory containing the configuration files.&#xD;&#xA;&#xD;&#xA;A further step is to define some further directories within the ~~conf~~ directory:&#xD;&#xA;- general&#xD;&#xA;- local&#xD;&#xA;- dev&#xD;&#xA;- qa&#xD;&#xA;- prod&#xD;&#xA;- ...&#xD;&#xA;&#xD;&#xA;The ~~conf/general~~ directory will contain all non-environment dependent configuration items. Alternatively this items will reside in the ~~conf~~ directory.&#xD;&#xA;&#xD;&#xA;All other directories will contain the environment depending configuration files. In all env directories should be  the same file names used and no other files.&#xD;&#xA;&#xD;&#xA;For example:&#xD;&#xA;&#xD;&#xA;__local__&#xD;&#xA;- jdbc.properties&#xD;&#xA;- sap-system.properties&#xD;&#xA;&#xD;&#xA;__dev__&#xD;&#xA;- jdbc.properties&#xD;&#xA;- sap-system.properties&#xD;&#xA;&#xD;&#xA;__qa__&#xD;&#xA;- jdbc.properties&#xD;&#xA;- sap-system.properties&#xD;&#xA;&#xD;&#xA;.... &#xD;&#xA;&#xD;&#xA;1.1 Using the correct configuration&#xD;&#xA;Depending on the given environment definition (see above) the configuration files should be taken from the defined directories ~~conf/${app.env}~~ (i.e. ~~conf/dev~~)&#xD;&#xA;&#xD;&#xA;1.1 Utilising in java spring based web-apllication projects&#xD;&#xA;...&#xD;&#xA;&#xD;&#xA;&#xD;&#xA;</s:content>
        <s:mTime>2010-05-09 15:45:49.071</s:mTime>
        <s:cTime>2010-05-09 14:53:50.788</s:cTime>
        <s:comments
             rdf:type='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
        <s:snipLinks>
            <rdf:Bag>
                <rdf:li rdf:resource='http://knowhow.amazers.net/rdf#dev/java tips'/>
                <rdf:li rdf:resource='#snipsnap-index'/>
                <rdf:li rdf:resource='http://knowhow.amazers.net/rdf#dev/java tips/'/>
                <rdf:li rdf:resource='http://knowhow.amazers.net/rdf#dev/java tips/Loading properties in a web application'/>
            </rdf:Bag>
        </s:snipLinks>
        <s:attachments
             rdf:type='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
    </s:Snip>
</rdf:RDF>

