ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-7112) EntityUtilProperties
Date Tue, 03 Apr 2018 06:45:00 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423553#comment-16423553

Jacques Le Roux commented on OFBIZ-7112:

Hi Aditya,

Please don't, and let me explain why.

It's a long time now we have the SystemProperty entity. It was a good idea, that [we spoke
about |https://markmail.org/message/gdcefnghjtezyn4b] [even |https://markmail.org/message/gdcefnghjtezyn4b]
[longer ago|https://markmail.org/message/gdcefnghjtezyn4b] before [it was implemented|http://svn.apache.org/viewvc?view=revision&revision=1238998].
I believe it's a good idea but there are 2 flaws in the current implementation.

When we discussed about it before the implementation, it was clear that only [business (ie
not system) properties should be concerned|http://example.com/]. To be clear, for me the system
properties are the properties in files at framework/start/src/main/java/org/apache/ofbiz/base/start
and some other files like freemarkerTransforms.properties, fop.properties, catalina.properties,
debug.properties, owasp.properties, security.properties, requestHandler.properties, url.properties
and maybe some others I missed :)
 # So the 1st flaw was to name this entity SystemProperty. It should have been named BusinessProperty.
We could consider rename it, but that's minor in comparison with the second flaw
 # The second flaw is that we kept the business properties files. To avoid duplication and
confusion all the business properties should be in the database and a specific UI should be
created to easier handled them.

We should also remember that when the idea was 1st expressed and discussed there were no tenants
in OFBiz (introduced in 2010). With now tenants, having business properties in data base is
necessary and (almost?) all business properties should be shareable by tenants (to be checked).

That's why I suggested to [Deprecate properties in favour of SystemProperties|https://markmail.org/message/md6fuoouan377c6w].
I also suggested to have specific multitenant and multitenant-initial readers for business
properties to separate those from other data. One thing I did not check yet is if the data
I then called "only for tenants" are the business properties; and those which are not are
system properties. A deeper analysis is required but the idea seems to fit.
TL;DR: We will not resolve the SystemProperties issues w/o no longer using properties files
but for the system properties. Of course then renaming the SystemProperty entity to BusinessProperty
is necessary. Having a specific UI for DB access for these properties is also necessary. I
foresee the webtools as the best place for this UI. It should be accessible by tenants.

And to finish the reason why I want to keep Wai's work, is sometimes you need to annul a property.
In this case the best way to do it in DB is how Wai implemented it, so it should not be removed.
Rather the duplicated properties in files should be removed and replaced by properties in
DB only.

> EntityUtilProperties
> --------------------
>                 Key: OFBIZ-7112
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-7112
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: ALL COMPONENTS
>    Affects Versions: Trunk
>            Reporter: Wai
>            Assignee: Jacques Le Roux
>            Priority: Major
>             Fix For: 17.12.01
>         Attachments: OFBIZ-7112.patch, OFBIZ-7112.patch, OFBIZ-7112.patch, OFBIZ-7112.patch,
> Ofbiz reads properties from either a properties file or the entity:SystemProperty. The
way it works previously is that ofbiz reads from the entity:SystemProperty first and if there
is no value associated with the target propertyname, it would then locate the value from the
relevant properties file.
> In other words, if there is a database entry for a property, the database entry should
override the associated properties file.
> The issue is that if a database entry exist but the value is empty, it would look for
a value from the properties file.  It should not do so.  If a database entry exists for the
propertyname of interest, the value should be taken from the database even if it holds an
empty value.

This message was sent by Atlassian JIRA

View raw message