I made some clear propositions in my first answer to this thread.
Essentially, I'm against deprecating file based properties and be in favor of a general fallback solution (SystemProperty -> .properties) for all properties *except* properties which cannot be read from the database (system startup properties etc.)
It is extremely helpful to maintain file based properties along with templates and a build solution to populate system specific sets of settings (we had a discussion about it). This cannot be achieved reasonably with pure database based properties.
And again some remark: the initial problem was simply SystemProperty demo data overriding file based properties, which can be solved by preventing to load them by default.
Thanks, Michael Am 05.04.18 um 11:41 schrieb Taher Alkhateeb:
If my understanding is correct from Scott's suggestion, then this entails substantial work as we need to: - Identify "everything else" which is not a system configuration property. Maybe some examples - Find, and fix code related to properties which should not exist in both db and files (remove fallback mechanism). Again, some examples would be good. - Figure out the implications from code design. - Also, I'm assuming this has nothing to do with JVM system properties correct? For example, take a look at StartupControlPanel.loadGlobalOfbizSystemProperties(...). So, to me the change in this proposal is still not crystal clear. AND reading this thread I see objections on the idea from both myself and Michael. So a clear strategy for what to do exactly and where would help. A big idea without a clear implementation strategy might lead to confusion. On Thu, Apr 5, 2018 at 12:10 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:Thanks Scott, This is indeed essentially it. I'll get into details in a new thread. Notably about how to load data. Jacques Le 05/04/2018 à 10:39, Scott Gray a écrit :My understanding is that Jacques is essentially proposing that: - Properties should either exist in the db or in files but not both - System configuration properties should go in files (I assume everything that isn't applicable to multi-tenanting) - Everything else should go to the db If properties are only expected to exist in one of the two places, then the fallback behavior discussion becomes obsolete. Hope that helps. Jacques, sorry if I've misunderstood anything, please feel free to clarify. Regards Scott On 5 April 2018 at 07:26, Taher Alkhateeb <slidingfilame...@gmail.com> wrote:There is no need to copy paste! I already read the jira and expressed my confusion which is still the case. Your text is long and talks about many things and does not provide a concrete proposal or a patch. What do you want to do? Rename system properties? Move properties? What are they? Create tenant readers? Do further analysis? What is the proposal? And why is the design discussion in a JIRA and not here? On Thu, Apr 5, 2018, 9:34 AM Jacques Le Roux <jacques.le.r...@les7arts.com wrote:OK, here is a copy of my comment in OFBIZ-7112 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 1. So the 1st flaw was to name this entity SystemProperty. It shouldhavebeen named BusinessProperty. We could consider rename it, but that'sminorin comparison with the second flaw 2. The second flaw is that we kept the business properties files. To avoid duplication and confusion all the business properties should be inthedatabase and a specific UI should be created to easier handled them. We should also remember that when the idea was 1st expressed anddiscussedthere 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 < https://markmail.org/message/opldepaevls3y3ob> for business propertiestoseparate 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 notaresystem properties. A deeper analysis is required but the idea seems tofit.------------------------------------------------------------------------------------------------------------------------ ------------------------------TL;DR: We will not resolve the SystemProperties issues w/o no longerusingproperties files but for the system properties. Of course then renamingtheSystemProperty 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 bytenants.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 DBonly.Jacques Le 05/04/2018 à 07:42, Scott Gray a écrit :If there's an ongoing discussion on the dev list then I don't thinkit'sagood idea to try to move it to jira until there's some consensus on the path forward. Regards Scott On 4 April 2018 at 10:14, Taher Alkhateeb <slidingfilame...@gmail.com> wrote:I am a little lost in this JIRA and cannot follow the discussion. Can you please point to what you want to review with others exactly? On Wed, Apr 4, 2018 at 9:46 AM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:Le 03/04/2018 à 09:16, Jacques Le Roux a écrit :I suggest to continue the discussion at https://issues.apache.org/jira/browse/OFBIZ-7112 where I havecompleted mypropositionSince there were some more comments after is al link to my commentwithmycompleted my proposition https://s.apache.org/7uwl Jacques
smime.p7s
Description: S/MIME Cryptographic Signature
