Yes thanks Joe,
I was (almost) sure I had read something in Commons for properties reloading
but could not put my hand on it
Jacques
From: "Adrian Crum" <[email protected]>
Thanks for the reminder Joe!
-Adrian
On 1/29/2012 5:26 PM, J. Eckard wrote:
Apache Commons Configuration can do this.
http://commons.apache.org/configuration/userguide/howto_multitenant.html#Multi-tenant_Configurations
---
http://osdir.com/ml/user.ofbiz.apache.org/2010-03/msg00343.html
Subject: Re: Brainstorming about the Framework: General - msg#00343
List: user.ofbiz.apache.org
Something I've thought about from time to time but never followed through all
the way to make sure there are no glaring problems:
switch UtilProperties to use something like Commons Configuration.
This would essentially put all configuration variables into one namespace,
where they would be accessed via XPath expressions.
You could pull and merge from various sources like properties files or XML
files, get (optional) automatic saving / reloading,
and (optional) property overriding.
The main reason for this would be to have a single file you could use for
deployment (dev.xml, staging.xml, production.xml,
etc) - drop this in your hot-deploy component and have it override the values
in framework / applications.
-Joe
On Jan 27, 2012, at 3:49 AM, Adrian Crum wrote:
I have been thinking about Properties handling too, not from a multi-tenant
perspective, but from a convenience perspective.
It seems to me the way we handle properties right now could be simplified.
Instead of calling a static utility method to get a
property or using a special mini-language element, the service or screen
rendering context should contain a Map called
"properties" - which provides a convenient means of accessing all configuration
properties. So, instead of:
<property-to-field resource="general.properties" property="currency.uom.id.default"
field="rateCurrencyUomId"/>
you would use:
<set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/>
and in Java, instead of:
String currencyUom = UtilProperties.getPropertyValue("general.properties",
"currency.uom.id.default");
you would use:
String currencyUom = dctx.properties.get("currency.uom.id.default");
Configuration Properties files could be read in at startup via an
ofbiz.component.xml element or elements.
The properties Map is read-only after startup.
When all of the configuration properties are handled in a centralized way, then
extending the design to use the entity engine as
an additional configuration property data source will be trivial.
The SystemProperty entity you proposed needs to be simplified:
SystemProperty
--------------
propertyKey, id-vlong-ne*
propertyValue, very-long
Properties file entries contain only key+value pairs, so the entity should do
the same.
-Adrian
On 1/27/2012 6:40 AM, Hans Bakker wrote:
Problem:
------------
1. If you would like to have different tenants on your system and want to have
different property settings for each tenant
laike language or currency etc, that is currently not supported.
2. the properties are not very well organized, to say the least.
Proposal:
------------
1. create the following entity SystemProperty with fields:
systemPropertyId(key)
parentSystemPropertyId
description
ofbizPropertyName(index)
systemPropertyValue
Initially load the systemPropertyid from the ofbiz propertyId so
accounting.fixedasset.autocreate=Y will have 3 records using
the parent id but only the lowest level will have the
accounting.fixedasset.autocreate name and value=Y
when we have this working we can slowly reorganize these records without having
to change the programs.
2. add the delegator parameter to the getPropertyValue method and change the
method system wide.
the getPropertyValue method will first look in this entity with the provided
delegator and when the property is null or not
found, use the properties file property as currently is done.
3. resolve anywhere where this method is called and where the delegator is not
available.
4. add a webtools option to set the properties.
Please provide comments or counter proposals......
Regards,
Hans
