contribution: configurable OFBiz configuration :-)

[Michael Brohl]

Hi all,

we have changed the OFBiz configuration mechanism for our latest projects
and I think this change could be useful also for the OFBiz standard.

The problem:
Our customers often have several server systems for one project, at least
a development, a test and a production server. Some of them have even
more, up to five systems.
All servers have different IP addresses, sometimes different port
settings, different cache settings etc. This is hard to handle and it is
error-prone to edit the configuration sets for every system after the
project is checked out to the target server. Additionally it would be more
convenient to edit the settings at a central place instead of many
different files in the project.
So we thought about a more elegant solution for it.

The solution:
The solution is simple and implemented with the tools the project already
contains: Ant and some template configuration files.

We have moved all necessary configuration files from their origin to a
special folder called templates and removed the values from them. The
values are written in a separate build.properties file. A new Ant target
creates the target configuration files from the templates an the
build.properties file and copies them to the original location. These
files are in the svn ignore list so that they are not checked in by
accident.

For every system we have additional property files like test.properties,
live.properties etc. If we want a configuration other than the default
from build.properties, the ant configuration target ist executed with the
corresponding machine name (e.g. ant -Dmachine.name=live build.xml
configure-and-build). These files only contain the changes from the build
properties file.

If a property file local.properties exists, it will be processed after
build.properties to have a local developers configuration available.

The following changes have to be made:

1. create a new folder configure and the folders templates and properties
under it
2. create the configuration templates and corresponding build.properties
file from the original configuration files
3. delete the original files after adding them to svn:ignore to avoid
checking them back in
4. create a new build file in the configure folder to do the
configuration.
5. add a new configuration target to the main build file

This is a simple but powerful solution and we are quite happy with it. We
would like to contribute this solution as a patch if you find it as useful
as we  do.
I appreciate your feedback!

Regards,

Michael Brohl


Michael Brohl
Leitung Consulting eCommerce
Agrenon GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: [phone]
Fax: [phone]
Mobil: [phone]


Company and Management Headquarters:
Agrenon GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland, Fon: [phone], Fax: [phone], www.agrenon.com

Court Registration: Amtsgericht Bielefeld HRB 36795
Chief Executive Officer: Dirk Osterkamp

----------------------------------------------------------------------------------------------------
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
----------------------------------------------------------------------------------------------------


Besuchen Sie uns!

live@lynx:
Releasewechsel SAP BI 7.0 &
Produktroadmap SAP

19. Juni 2008
Beginn: 15.00 Uhr
Geschäftsstelle Bielefeld

[Malin Nicolas]

Hi Michael,

This system exist on Neogia project with config directory. At the root
of the project, we put a site.properties that read all config files on
the site directory.

I think, we can contribut all idea to ofbiz projet, if you want ;)

Nicolas

If

Michael Brohl a écrit :

> Hi all,
>
> we have changed the OFBiz configuration mechanism for our latest projects
> and I think this change could be useful also for the OFBiz standard.
>
> The problem:
> Our customers often have several server systems for one project, at least
> a development, a test and a production server. Some of them have even
> more, up to five systems.
> All servers have different IP addresses, sometimes different port
> settings, different cache settings etc. This is hard to handle and it is
> error-prone to edit the configuration sets for every system after the
> project is checked out to the target server. Additionally it would be more
> convenient to edit the settings at a central place instead of many
> different files in the project.
> So we thought about a more elegant solution for it.
>
> The solution:
> The solution is simple and implemented with the tools the project already
> contains: Ant and some template configuration files.
>
> We have moved all necessary configuration files from their origin to a
> special folder called templates and removed the values from them. The
> values are written in a separate build.properties file. A new Ant target
> creates the target configuration files from the templates an the
> build.properties file and copies them to the original location. These
> files are in the svn ignore list so that they are not checked in by
> accident.
>
> For every system we have additional property files like test.properties,
> live.properties etc. If we want a configuration other than the default
> from build.properties, the ant configuration target ist executed with the
> corresponding machine name (e.g. ant -Dmachine.name=live build.xml
> configure-and-build). These files only contain the changes from the build
> properties file.
>
> If a property file local.properties exists, it will be processed after
> build.properties to have a local developers configuration available.
>
> The following changes have to be made:
>
> 1. create a new folder configure and the folders templates and properties
> under it
> 2. create the configuration templates and corresponding build.properties
> file from the original configuration files
> 3. delete the original files after adding them to svn:ignore to avoid
> checking them back in
> 4. create a new build file in the configure folder to do the
> configuration.
> 5. add a new configuration target to the main build file
>
> This is a simple but powerful solution and we are quite happy with it. We
> would like to contribute this solution as a patch if you find it as useful
> as we  do.
> I appreciate your feedback!
>
> Regards,
>
> Michael Brohl
>
>
> Michael Brohl
> Leitung Consulting eCommerce
> Agrenon GmbH
> Johanniskirchplatz 6
> 33615 Bielefeld
> Deutschland
> Fon: [phone]
> Fax: [phone]
> Mobil: [phone]
>
>
> Company and Management Headquarters:
> Agrenon GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland, Fon: [phone], Fax: [phone], www.agrenon.com
>
> Court Registration: Amtsgericht Bielefeld HRB 36795
> Chief Executive Officer: Dirk Osterkamp
>
> ----------------------------------------------------------------------------------------------------
> This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
> ----------------------------------------------------------------------------------------------------
>
>
> Besuchen Sie uns!
>
> live@lynx:
> Releasewechsel SAP BI 7.0 &
> Produktroadmap SAP
>
> 19. Juni 2008
> Beginn: 15.00 Uhr
> Geschäftsstelle Bielefeld
>  

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[David E Jones]

This has been discussed before and decided against.

An easier solution would be to just put all of the configuration  
properties in a single file, except that:

1. different components need different configuration and we don't want  
to assume in this way which components or combinations of them will be  
used

2. the file would become enormous unless we trim down available  
configuration options, and doing that effectively would require  
knowing more or less exactly what the system is to be used for (ie  
limit the scope and exclude part of the current OFBiz user base)

What we do at Hotwax, and I think what most do (though I don't know)  
is create a patch for each server if differences between the servers  
are needed. However, in the common case of a pool of servers running  
together to create a large instance of OFBiz these per-server  
configurations are generally not needed because all of the URLs that  
need to be configured are the external/outside URLs that hit the load  
balancer, and those are the same for all instances in the pool.

On side note I should mention that the direction has been discussed  
and generally agreed on that application level properties should be  
done away with (like payment.properties, and many others) and that  
information should go into the database. The main reason behind that  
is to support differing initial data for common setups that can simply  
be loaded into the system when it is run and you can get started  
quickly and without having to dive into files... oh and also that you  
can maintain things through a UI instead of through editing properties  
files.

-David


On Jun 10, 2008, at 2:45 AM, Michael Brohl wrote:

> Hi all,
>
> we have changed the OFBiz configuration mechanism for our latest  
> projects
> and I think this change could be useful also for the OFBiz standard.
>
> The problem:
> Our customers often have several server systems for one project, at  
> least
> a development, a test and a production server. Some of them have even
> more, up to five systems.
> All servers have different IP addresses, sometimes different port
> settings, different cache settings etc. This is hard to handle and  
> it is
> error-prone to edit the configuration sets for every system after the
> project is checked out to the target server. Additionally it would  
> be more
> convenient to edit the settings at a central place instead of many
> different files in the project.
> So we thought about a more elegant solution for it.
>
> The solution:
> The solution is simple and implemented with the tools the project  
> already
> contains: Ant and some template configuration files.
>
> We have moved all necessary configuration files from their origin to a
> special folder called templates and removed the values from them. The
> values are written in a separate build.properties file. A new Ant  
> target
> creates the target configuration files from the templates an the
> build.properties file and copies them to the original location. These
> files are in the svn ignore list so that they are not checked in by
> accident.
>
> For every system we have additional property files like  
> test.properties,
> live.properties etc. If we want a configuration other than the default
> from build.properties, the ant configuration target ist executed  
> with the
> corresponding machine name (e.g. ant -Dmachine.name=live build.xml
> configure-and-build). These files only contain the changes from the  
> build
> properties file.
>
> If a property file local.properties exists, it will be processed after
> build.properties to have a local developers configuration available.
>
> The following changes have to be made:
>
> 1. create a new folder configure and the folders templates and  
> properties
> under it
> 2. create the configuration templates and corresponding  
> build.properties
> file from the original configuration files
> 3. delete the original files after adding them to svn:ignore to avoid
> checking them back in
> 4. create a new build file in the configure folder to do the
> configuration.
> 5. add a new configuration target to the main build file
>
> This is a simple but powerful solution and we are quite happy with  
> it. We
> would like to contribute this solution as a patch if you find it as  
> useful
> as we  do.
> I appreciate your feedback!
>
> Regards,
>
> Michael Brohl
>
>
> Michael Brohl
> Leitung Consulting eCommerce
> Agrenon GmbH
> Johanniskirchplatz 6
> 33615 Bielefeld
> Deutschland
> Fon: [phone]
> Fax: [phone]
> Mobil: [phone]
>
>
> Company and Management Headquarters:
> Agrenon GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland,  
> Fon: [phone], Fax: [phone], www.agrenon.com
>
> Court Registration: Amtsgericht Bielefeld HRB 36795
> Chief Executive Officer: Dirk Osterkamp
>
> ----------------------------------------------------------------------------------------------------
> This e-mail may contain trade secrets or privileged, undisclosed, or  
> otherwise confidential information. If you have received this e-mail  
> in error, you are hereby notified that any review, copying, or  
> distribution of it is strictly prohibited. Please inform us  
> immediately and destroy the original transmittal. Thank you for your  
> cooperation.
> ----------------------------------------------------------------------------------------------------
>
>
> Besuchen Sie uns!
>
> live@lynx:
> Releasewechsel SAP BI 7.0 &
> Produktroadmap SAP
>
> 19. Juni 2008
> Beginn: 15.00 Uhr
> Geschäftsstelle Bielefeld

[Adrian Crum]

David E Jones wrote:
> On side note I should mention that the direction has been discussed and
> generally agreed on that application level properties should be done
> away with (like payment.properties, and many others) and that
> information should go into the database. The main reason behind that is
> to support differing initial data for common setups that can simply be
> loaded into the system when it is run and you can get started quickly
> and without having to dive into files... oh and also that you can
> maintain things through a UI instead of through editing properties files.

An interesting idea. Would a single entity be used for that, or would
each application have its own entity?

-Adrian

[David E Jones]

On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On side note I should mention that the direction has been discussed  
>> and generally agreed on that application level properties should be  
>> done away with (like payment.properties, and many others) and that  
>> information should go into the database. The main reason behind  
>> that is to support differing initial data for common setups that  
>> can simply be loaded into the system when it is run and you can get  
>> started quickly and without having to dive into files... oh and  
>> also that you can maintain things through a UI instead of through  
>> editing properties files.
>
> An interesting idea. Would a single entity be used for that, or  
> would each application have its own entity?

No one has gone through a modeling exercise yet, so I don't know  
exactly what the entities would look like. In essence the each  
property in the relevant properties files needs to be considered and  
added where it makes the most sense, either to existing entities or  
new ones. For payment.properties most of the information would go in  
the ProductStorePaymentSetting entity or in entity(ies) related to it.  
They would replace the  
ProductStorePaymentSetting.paymentPropertiesPath field which is  
currently used to refer to a payment.properties file (of a different  
name, ie allowing multiple files for multiple payment processors... a  
"hack" if you will).

-David

[David E Jones]

On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On side note I should mention that the direction has been discussed  
>> and generally agreed on that application level properties should be  
>> done away with (like payment.properties, and many others) and that  
>> information should go into the database. The main reason behind  
>> that is to support differing initial data for common setups that  
>> can simply be loaded into the system when it is run and you can get  
>> started quickly and without having to dive into files... oh and  
>> also that you can maintain things through a UI instead of through  
>> editing properties files.
>
> An interesting idea. Would a single entity be used for that, or  
> would each application have its own entity?

No one has gone through a modeling exercise yet, so I don't know  
exactly what the entities would look like. In essence the each  
property in the relevant properties files needs to be considered and  
added where it makes the most sense, either to existing entities or  
new ones. For payment.properties most of the information would go in  
the ProductStorePaymentSetting entity or in entity(ies) related to it.  
They would replace the  
ProductStorePaymentSetting.paymentPropertiesPath field which is  
currently used to refer to a payment.properties file (of a different  
name, ie allowing multiple files for multiple payment processors... a  
"hack" if you will).

-David

[Adrian Crum]

David E Jones wrote:

> On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> On side note I should mention that the direction has been discussed
>>> and generally agreed on that application level properties should be
>>> done away with (like payment.properties, and many others) and that
>>> information should go into the database. The main reason behind that
>>> is to support differing initial data for common setups that can
>>> simply be loaded into the system when it is run and you can get
>>> started quickly and without having to dive into files... oh and also
>>> that you can maintain things through a UI instead of through editing
>>> properties files.
>>
>> An interesting idea. Would a single entity be used for that, or would
>> each application have its own entity?
>
> No one has gone through a modeling exercise yet, so I don't know exactly
> what the entities would look like. In essence the each property in the
> relevant properties files needs to be considered and added where it
> makes the most sense, either to existing entities or new ones. For
> payment.properties most of the information would go in the
> ProductStorePaymentSetting entity or in entity(ies) related to it. They
> would replace the ProductStorePaymentSetting.paymentPropertiesPath field
> which is currently used to refer to a payment.properties file (of a
> different name, ie allowing multiple files for multiple payment
> processors... a "hack" if you will).

I was thinking we could add a bit of code to the UtilProperties class
that would check a common entity in addition to properties files. It
would be a simple change to make, and applications could still get their
settings through UtilProperties.getProperty(...) method calls. Screens
could be created to manage groups of properties.

-Adrian

[David E Jones]

On Jun 10, 2008, at 12:22 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> On side note I should mention that the direction has been  
>>>> discussed and generally agreed on that application level  
>>>> properties should be done away with (like payment.properties, and  
>>>> many others) and that information should go into the database.  
>>>> The main reason behind that is to support differing initial data  
>>>> for common setups that can simply be loaded into the system when  
>>>> it is run and you can get started quickly and without having to  
>>>> dive into files... oh and also that you can maintain things  
>>>> through a UI instead of through editing properties files.
>>>
>>> An interesting idea. Would a single entity be used for that, or  
>>> would each application have its own entity?
>> No one has gone through a modeling exercise yet, so I don't know  
>> exactly what the entities would look like. In essence the each  
>> property in the relevant properties files needs to be considered  
>> and added where it makes the most sense, either to existing  
>> entities or new ones. For payment.properties most of the  
>> information would go in the ProductStorePaymentSetting entity or in  
>> entity(ies) related to it. They would replace the  
>> ProductStorePaymentSetting.paymentPropertiesPath field which is  
>> currently used to refer to a payment.properties file (of a  
>> different name, ie allowing multiple files for multiple payment  
>> processors... a "hack" if you will).
>
> I was thinking we could add a bit of code to the UtilProperties  
> class that would check a common entity in addition to properties  
> files. It would be a simple change to make, and applications could  
> still get their settings through UtilProperties.getProperty(...)  
> method calls. Screens could be created to manage groups of properties.

I would really like to not see this happen, as it would only be a  
slight improvement over what exists now, but it wouldn't be a real  
data model and the result would be as disorganized and difficult to  
understand and use as the current flat properties file. I guess it's  
not too bad, but we don't have to stick to a single flat list of  
properties in the database... we have a lot more flexibility there.

Anyway, the data modeling and queries and UIs should be a vast  
improvement over what exists now, and I'm thinking well worth the  
effort as well.

-David

[Adrian Crum]

David E Jones wrote:

>
> On Jun 10, 2008, at 12:22 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
>>>> David E Jones wrote:
>>>>> On side note I should mention that the direction has been discussed
>>>>> and generally agreed on that application level properties should be
>>>>> done away with (like payment.properties, and many others) and that
>>>>> information should go into the database. The main reason behind
>>>>> that is to support differing initial data for common setups that
>>>>> can simply be loaded into the system when it is run and you can get
>>>>> started quickly and without having to dive into files... oh and
>>>>> also that you can maintain things through a UI instead of through
>>>>> editing properties files.
>>>>
>>>> An interesting idea. Would a single entity be used for that, or
>>>> would each application have its own entity?
>>> No one has gone through a modeling exercise yet, so I don't know
>>> exactly what the entities would look like. In essence the each
>>> property in the relevant properties files needs to be considered and
>>> added where it makes the most sense, either to existing entities or
>>> new ones. For payment.properties most of the information would go in
>>> the ProductStorePaymentSetting entity or in entity(ies) related to
>>> it. They would replace the
>>> ProductStorePaymentSetting.paymentPropertiesPath field which is
>>> currently used to refer to a payment.properties file (of a different
>>> name, ie allowing multiple files for multiple payment processors... a
>>> "hack" if you will).
>>
>> I was thinking we could add a bit of code to the UtilProperties class
>> that would check a common entity in addition to properties files. It
>> would be a simple change to make, and applications could still get
>> their settings through UtilProperties.getProperty(...) method calls.
>> Screens could be created to manage groups of properties.
>
> I would really like to not see this happen, as it would only be a slight
> improvement over what exists now, but it wouldn't be a real data model
> and the result would be as disorganized and difficult to understand and
> use as the current flat properties file. I guess it's not too bad, but
> we don't have to stick to a single flat list of properties in the
> database... we have a lot more flexibility there.
>
> Anyway, the data modeling and queries and UIs should be a vast
> improvement over what exists now, and I'm thinking well worth the effort
> as well.

I agree that having a data model would be better. But still, an hour or
two of coding and we could have configuration screens for the existing
properties.

-Adrian