ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brohl <michael.br...@ecomify.de>
Subject Re: [PROPOSAL] Environment variable configuration
Date Fri, 03 Nov 2017 09:10:00 GMT
Just an update triggered by the question from Swapnil [1]: our 
configuration mechanism mentioned below is now on Gradle so it would be 
compatible with 16.11 and later.




Am 05.07.17 um 17:56 schrieb Michael Brohl:
> Hi Gil,
> we have similar challenges and modified OFBiz to deal with it easily. 
> We offered to contribute this long time ago (2008) but it was decided 
> against [1]. It was suggested to use patches instead but I think it's 
> too complicated to manage several patch sets for different environments.
> We now use a staged configure mechanism which uses a base build file, 
> auto detected machine name and provided parameters to decide which 
> configurations should be pulled for the environment. It's currently 
> Ant based and therefore does not fit into the current build mechanism 
> (on the todo list).
> I like your approach also and I think it should be evaluated and 
> discussed.
> Best regards,
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
> [1] 
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>> Hello all,
>> Working with different hosting companies, we used to have issues when 
>> deploying OFBiz concerning technical configuration of the different 
>> environments.
>> We are writing this mail to get feedback from the community and 
>> eventually propose to improve OFBiz on this matter.
>> For a customer, we are working with 4 instances of a release 13.07 
>> OFBiz, and are currently using a set of patches (with 
>> addonmanager...) to manage environment specific configurations.
>> During each production deployment, the hosting company receive from 
>> our jenkins a precompiled archive containing OFBiz codebase, and then 
>> apply the set of patches to configure it to the environment needs, 
>> recompile and relaunch...
>> This way of doing can cause issue when patch could not apply, after a 
>> codebase modification (pretty rare but it happens).
>> We are not satisfied with this way of doing, we are currently 
>> thinking about using environment variables to configure technical 
>> environment properties (those are on the hosting company 
>> responsibility), and to keep functional specifics into the code base.
>> If you have some experience or advice in this matter, you are welcome.
>> For our case, we currently have enhanced OFBiz to be able to get 
>> environment variable from the operating system within property file 
>> and some other configuration files (with default value if not set).
>> Examples :
>> *In Property file :
>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or 
>> ofbiz if unset
>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable 
>> OTHER_CONF or ${partyId} if unset
>> *In entityengine.xml :
>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://}"

>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>> That allow us to keep functional parameters stored within git 
>> branches. Our jenkins now is able to build our 4 configured and 
>> compiled instances and deliver it to the hosting company, that just 
>> have to set/check environment variable (database access, activeMQ, 
>> log location, instance id, etc.) before starting OFBiz app. Now we 
>> cannot have configuration failure during deployment.
>> We will be glad to contribute it, if it's the good way to go !
>> Best Regards !
>> Gil Portenseigne

View raw message