You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2018/04/03 07:16:24 UTC
Re: Deprecate properties in favour of SystemProperties
I suggest to continue the discussion at https://issues.apache.org/jira/browse/OFBIZ-7112 where I have completed my proposition
Jacques
Le 18/02/2018 à 13:37, Jacques Le Roux a écrit :
> Michael,
>
> Actually this idea of multitenant and multitenant-initial readers came to me after your proposition of commenting out the load of
> CommonSystemPropertyData.xml. This idea is easy and safe to implement. It's only a matter of changing the data and no code change is needed (I
> consider entityengine.xml to be data).
>
> Also it's not all or nothing. We could separate the data which are only for multitenant. If a data is used in both contexts (multitenant and single
> DB) then no worries: it should only be loaded as a seed or seed-initial data, no need to duplicate.
>
> Since we don't demonstrate multi-tenancy in our official demo, no need to include multitenant and multitenant-initial in loadAdd. But of course all
> this needs to be clearly documented for people interested in the feature.
>
> Note that this does not mean that multi-tenancy should not be improved. But here I try to minimise the changes while answering the initial issue in
> this thread which is actually a duplicate of OFBIZ-7754. With this solution we could also close OFBIZ-7112 and hopefully more easily answer to
> OFBIZ-6164.
>
> And to agree with you Taher, we know OFBiz multi-tenancy is limited and can't or hardly scale (I was confronted with that). But that's another
> problem and at least OOTB OFBiz offers a mean for small not scaling multi-tenancy deployments.
>
> Jacques
>
>
> Le 18/02/2018 à 11:27, Taher Alkhateeb a écrit :
>> I agree, the two serve entirely different purposes. Multi tenancy
>> simply means different databases sharing the same code base.
>>
>> If any differences in configuration are substantial enough, then this
>> is when you consider two or more instances instead of multi-tenancy. I
>> don't favor multi-tenancy generally myself simply because the hardware
>> / software infrastructure has evolved a lot, and with plenty of ram
>> and disk space available nowadays and using something like containers
>> (docker) you can achieve the same desired results using even the same
>> code base.
>>
>> On Sun, Feb 18, 2018 at 12:51 PM, Michael Brohl
>> <mi...@ecomify.de> wrote:
>>> Hi Jacques,
>>>
>>> I think the SystemProperty feature should not be tight together with the
>>> multi tenant terminology. It is usable without it and therefore should have
>>> it's own configuration. It would just add more confusion to users.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 18.02.18 um 08:08 schrieb Jacques Le Roux:
>>>
>>>> Thanks Michael,
>>>>
>>>> Taher's reluctance pushed me to think about another solution. I add the
>>>> same thought than you but with a different solution.
>>>>
>>>> We could have a multitenant and multitenant-initial readers, like we have
>>>> seed and seed-initial
>>>>
>>>> Like ext readers , it would not be included in loadAll. So only
>>>> multitenant deployments would use them.
>>>>
>>>> Then all files loading SystemProperties would declare using the
>>>> multitenant or the multitenant-initial reader, eg
>>>>
>>>> <entity-resource type="data" reader-name="multitenant" loader="main"
>>>> location="data/CommonSystemPropertyData.xml"/>
>>>>
>>>> A simple documentation should suffice.
>>>>
>>>> About
>>>>> So I propose to introduce a file property which can switch the
>>>>> SystemProperty reading on and off.
>>>> We already have it, it's the multitenant general property. But anyway with
>>>> the multitenant reader modifying the code would not be needed. The data
>>>> would not be loaded in a no multitenant deployment.
>>>>
>>>> With this solution all the problems related to SystemProperties would
>>>> vanish and most of the related Jira issues could be closed, maybe with some
>>>> changes like for OFBIZ-7112, anyway the list is below
>>>>
>>>> If nobody disagree I'll look at it soon...
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 17/02/2018 à 12:01, Michael Brohl a écrit :
>>>>> I don't think that this is the right way to go.
>>>>>
>>>>> The original problem is that we have some example SystemProperty data
>>>>> which is loaded automatically when you setup OFBiz in the documented way.
>>>>> This leads to confusion when someone changes the file properties for e.g.
>>>>> the mail transport configuration without success because the example data
>>>>> overrides it.
>>>>>
>>>>> The immediate solution for this problem is simple: just don't
>>>>> load/override file properties with example SystemProperty data by default.
>>>>>
>>>>>
>>>>> Although I do not agree with the deprecation of file properties in favor
>>>>> of SystemProperty, there are some aspects we should consider/do.
>>>>>
>>>>> OFBiz should consistently provide the possibility to overload file
>>>>> properties with SystemProperty data, not just in a few places.
>>>>>
>>>>> So +1 to implement this in all areas where it is reasonable for either
>>>>> multi tenant environments or configuration you might want to change at
>>>>> runtime. Of course, this is not something we should do in a simple search &
>>>>> replace session. It needs careful consideration.
>>>>>
>>>>> A good central documentation of all properties and if they can be changed
>>>>> at file or SystemProperty level would leave no questions open. A good task
>>>>> for contributors to the new documentation framework ;-)
>>>>>
>>>>> Additionally, I think we should make the SystemProperty loading
>>>>> configurable also, disabled by default. This would be the setting where only
>>>>> file properties would be used. For single tenant environments, it can avoid
>>>>> permanent entity checks/reading attempts where it is not necessary because
>>>>> SystemProperty is not used. So I propose to introduce a file property which
>>>>> can switch the SystemProperty reading on and off.
>>>>>
>>>>> This way, the default loading of the example SystemProperty data would do
>>>>> no harm also.
>>>>>
>>>>> For multi tenant environments or single tenant environments it can be
>>>>> switched on and allows overriding the file properties.
>>>>>
>>>>> This way, we are flexible to a maximum, there are no backward
>>>>> compatibility problems and there are no unneccessary memory usages or
>>>>> performance issues when the user does not want to use SystemProperty
>>>>> configurations.
>>>>>
>>>>> So in short:
>>>>>
>>>>> * -1 for file properties deprecation
>>>>>
>>>>> * +1 for consistently implementing SystemProperty reads where
>>>>> applicable/reasonable
>>>>>
>>>>> * additionally make SystemProperty reads configurable, off by default.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 16.02.18 um 16:12 schrieb Jacques Le Roux:
>>>>>> The more I think about it, the more I believe the ultimate solution is
>>>>>> to remove all properties in favour of SystemProperties. And to no longer use
>>>>>> properties but only SystemProperties.
>>>>>>
>>>>>> This entails to
>>>>>>
>>>>>> 1. completely implements EntityUtilProperties
>>>>>> 2. deprecate UtilProperties
>>>>>> 3. replace all properties by SystemProperties
>>>>>>
>>>>>> One could argue that not all properties need to be SystemProperties
>>>>>> because they are not useful for multi-tenants.
>>>>>> But I believe that for consistency reasons it's easier to have all or
>>>>>> nothing. Once well documented, this would avoid confusion and prevent
>>>>>> creation of new erratic properties.
>>>>>>
>>>>>> Even the general-multitenant properties could be a SystemProperty, I see
>>>>>> no reasons why not.
>>>>>>
>>>>>> Opinions, ideas?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 16/02/2018 à 08:49, Jacques Le Roux a écrit :
>>>>>>> This could be a solution for this specific problem if we get a
>>>>>>> consensus. OFBIZ-7754 is related
>>>>>>>
>>>>>>> To summarize: the problem is, because of OFBIZ-7112, if you use the
>>>>>>> same seeds than in 13.07 you will get nothing which can even be more
>>>>>>> confusing.
>>>>>>> That's why we have values in SystemProperty, this was done with
>>>>>>> r1748560.
>>>>>>>
>>>>>>> While at it, and about OFBIZ-7754 what about the other SystemProperty
>>>>>>> in other seed or seed-initial data files.
>>>>>>> seed-initial: WorkEffortSeedInitialData CatalogSystemPropertyData
>>>>>>> OrderSystemPropertyData BiSystemPropertyData ProjectMgrSystemPropertyData
>>>>>>> seed: CommonSystemPropertyData EcommerceSystemPropertyData
>>>>>>>
>>>>>>> I note that we have no other solutions yet than EntityUtilProperties to
>>>>>>> handle properties in multi-tenants.
>>>>>>> There is another related topic: we need to be sure to keep the
>>>>>>> SystemProperty and the properties in file synchronised as shown in
>>>>>>> OFBIZ-9924
>>>>>>> I wonder if a solution could not be to remove any property which has a
>>>>>>> related SystemProperty. What do you think about that?
>>>>>>>
>>>>>>> So we need to get a consensus, or even a vote if necessary, to
>>>>>>> definitely resolve these issues.
>>>>>>>
>>>>>>> For that I exceptionally cross post this discussion in dev ML and it
>>>>>>> should be continued there.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 15/02/2018 à 18:22, Mike a écrit :
>>>>>>>>> but to comment them out of the ofbiz-component.xml.
>>>>>>>> +1
>>>>>>>>
>>>>>>>> On Thu, Feb 15, 2018 at 8:42 AM, Michael Brohl
>>>>>>>> <mi...@ecomify.de>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I agree that the default population of SystemProperty with
>>>>>>>>> configuration
>>>>>>>>> values is confusing, especially for the mail configuration
>>>>>>>>>
>>>>>>>>> I'd suggest to not remove the load data but to comment them out of
>>>>>>>>> the
>>>>>>>>> ofbiz-component.xml. They can stay there as an example but would not
>>>>>>>>> be
>>>>>>>>> loaded by default.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 15.02.18 um 17:07 schrieb Mike:
>>>>>>>>>
>>>>>>>>> Jacques: I understand the value of the feature. What I'm
>>>>>>>>> referring to is
>>>>>>>>>> somebody, in 16.x, hard-coded the above values in "seed", which
>>>>>>>>>> caused the
>>>>>>>>>> problem for this user.
>>>>>>>>>>
>>>>>>>>>> This is an advanced feature, and caused a lot of confusion. I'd
>>>>>>>>>> recommend
>>>>>>>>>> that the 16.x CommonSystemPropertyData.xml be edited to remove all
>>>>>>>>>> "systemPropertyValue="
>>>>>>>>>> entries.
>>>>>>>>>>
>>>>>>>>>> 13.07: ./framework/common/data/CommonSystemPropertyData.xml
>>>>>>>>>>
>>>>>>>>>> Here is the latest version of 13.07, which does not hard-code these
>>>>>>>>>> values.
>>>>>>>>>> None of the 13.07 seed data have "systemPropertyValue=" set.
>>>>>>>>>>
>>>>>>>>>> systemPropertyId="ORGANIZATION_PARTY
>>>>>>>>>> systemPropertyId="VISUAL_THEME"
>>>>>>>>>> systemPropertyId="currency.uom.id.default"
>>>>>>>>>> systemPropertyId="country.geo.id.default"
>>>>>>>>>> systemPropertyId="partner.trackingCodeId.default"
>>>>>>>>>> systemPropertyId="defaultFromEmailAddress"
>>>>>>>>>> systemPropertyId="mail.notifications.enabled"
>>>>>>>>>> systemPropertyId="mail.smtp.relay.host"
>>>>>>>>>> systemPropertyId="mail.smtp.auth.user"
>>>>>>>>>> systemPropertyId="mail.smtp.auth.password"
>>>>>>>>>> systemPropertyId="mail.smtp.port"
>>>>>>>>>> systemPropertyId="mail.smtp.starttls.enable"
>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.port"
>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.class"
>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.fallback"
>>>>>>>>>> systemPropertyId="mail.smtp.sendpartial"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 15, 2018 at 1:15 AM, Jacques Le Roux <
>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Mike, thanks for asking
>>>>>>>>>>> This controversial feature has been initially discussed with
>>>>>>>>>>> http://markmail.org/message/be3ts56b5w22k6pz
>>>>>>>>>>>
>>>>>>>>>>> We currently have some related pending Jira about that (sorry maybe
>>>>>>>>>>> a bit
>>>>>>>>>>> too much, also a way to remind/check myself before discussing again
>>>>>>>>>>> in
>>>>>>>>>>> dev
>>>>>>>>>>> ML)
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7112
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7754
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6166
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6164
>>>>>>>>>>>
>>>>>>>>>>> http://markmail.org/message/i4rubhbo7wlm4wts
>>>>>>>>>>>
>>>>>>>>>>> https://s.apache.org/oTA6
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6712
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6205
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6210
>>>>>>>>>>>
>>>>>>>>>>> Because this is now entrenched in OFBiz for many years, and I guess
>>>>>>>>>>> used
>>>>>>>>>>> by many customs projects, it will maybe hard to get back.
>>>>>>>>>>> But then we need a better documentation. Beginning as simply as I
>>>>>>>>>>> proposed
>>>>>>>>>>> below. And we need to agree and fix the pending issues.
>>>>>>>>>>>
>>>>>>>>>>> HTH
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 14/02/2018 à 16:49, Mike a écrit :
>>>>>>>>>>>
>>>>>>>>>>> Jacques: Why does ofbiz 16.x set real properties
>>>>>>>>>>>> in: ./framework/common/data/CommonSystemPropertyData.xml? This is
>>>>>>>>>>>> part
>>>>>>>>>>>> of
>>>>>>>>>>>> "seed"... It hard-codes:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> systemPropertyId="ORGANIZATION_PARTY"
>>>>>>>>>>>> systemPropertyValue="Company"
>>>>>>>>>>>> systemPropertyId="VISUAL_THEME" systemPropertyValue="FLAT_GREY"
>>>>>>>>>>>> systemPropertyId="currency.uom.id.default"
>>>>>>>>>>>> systemPropertyValue="USD"
>>>>>>>>>>>> systemPropertyId="country.geo.id.default"
>>>>>>>>>>>> systemPropertyValue="USA"
>>>>>>>>>>>> systemPropertyId="defaultFromEmailAddress" systemPropertyValue="
>>>>>>>>>>>> ofbiztest@example.com"
>>>>>>>>>>>> systemPropertyId="mail.notifications.enabled"
>>>>>>>>>>>> systemPropertyValue="N"
>>>>>>>>>>>> systemPropertyId="mail.smtp.port" systemPropertyValue="465"
>>>>>>>>>>>> systemPropertyId="mail.smtp.starttls.enable"
>>>>>>>>>>>> systemPropertyValue="true"
>>>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.port"
>>>>>>>>>>>> systemPropertyValue="465"
>>>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.class"
>>>>>>>>>>>> systemPropertyValue="javax.net.ssl.SSLSocketFactory"
>>>>>>>>>>>> systemPropertyId="mail.smtp.socketFactory.fallback"
>>>>>>>>>>>> systemPropertyValue="false"
>>>>>>>>>>>> systemPropertyId="mail.smtp.sendpartial"
>>>>>>>>>>>> systemPropertyValue="true"
>>>>>>>>>>>>
>>>>>>>>>>>> Which seems to override general.properties.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Feb 13, 2018 at 6:55 AM, Jacques Le Roux <
>>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks Pierre!
>>>>>>>>>>>>
>>>>>>>>>>>>> This is indeed something which is tricky for new users and even
>>>>>>>>>>>>> easily
>>>>>>>>>>>>> forgettable in general.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Before I post about SystemProperty and EntityUtilProperties on
>>>>>>>>>>>>> dev ML,
>>>>>>>>>>>>> I
>>>>>>>>>>>>> want to suggest here that we put a comment at the top of each
>>>>>>>>>>>>> properties
>>>>>>>>>>>>> file as a reminder that the properties there could be overridden
>>>>>>>>>>>>> in a
>>>>>>>>>>>>> SystemProperty
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 12/02/2018 à 21:32, pierre.gaudin a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, have a look at SystemProperty entity for key
>>>>>>>>>>>>>
>>>>>>>>>>>>>> mail.notifications.enabled
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pierre
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12/02/2018 19:53, Mike wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For TLS (mail.smtp.starttls.enable=true ), use port 587
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Feb 12, 2018 at 4:37 AM, Дмитрий Цыганок
>>>>>>>>>>>>>>> <dt...@kapitanweb.ru>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've deployed Ofbiz several times, but each time with the right
>>>>>>>>>>>>>>>> settings,
>>>>>>>>>>>>>>>> email notifications are not sent.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here are my settings from /var/www/ofbiz/framework/commo
>>>>>>>>>>>>>>>> n/config/general.
>>>>>>>>>>>>>>>> properties:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> unique.instanceId=ofbiz1
>>>>>>>>>>>>>>>> currency.uom.id.default=USD
>>>>>>>>>>>>>>>> ORGANIZATION_PARTY=Company
>>>>>>>>>>>>>>>> VISUAL_THEME=RAINBOWSTONE_SAPHIR
>>>>>>>>>>>>>>>> currency.decimal.format=#,##0.00
>>>>>>>>>>>>>>>> currency.rounding.default=10
>>>>>>>>>>>>>>>> currency.scale.enabled=N
>>>>>>>>>>>>>>>> locale.properties.fallback=en
>>>>>>>>>>>>>>>> #locales.available=ar,de,en,es,fr,hi,it,nl,pt,ro,ru,th,zh
>>>>>>>>>>>>>>>> #timeZones.available=US/Eastern,US/Central,US/
>>>>>>>>>>>>>>>> Mountain,US/Pacific,US/Alaska,US/Hawaii
>>>>>>>>>>>>>>>> country.geo.id.default=USA
>>>>>>>>>>>>>>>> partner.trackingCodeId.default=
>>>>>>>>>>>>>>>> usps.address.match=(^.*?p[\\. ]*o[\\.
>>>>>>>>>>>>>>>> ]*box.*$)|(^.*?post.*?office.*
>>>>>>>>>>>>>>>> ?box.*$)|((^|(^.*?
>>>>>>>>>>>>>>>> ))r[\\. ]*r[\\. ]*(( +)|([0-9#]+)).*$)|(^.*?rural.*?route.*$)
>>>>>>>>>>>>>>>> defaultFromEmailAddress=dmtsyganok@gmail.com
>>>>>>>>>>>>>>>> mail.notifications.enabled=Y
>>>>>>>>>>>>>>>> mail.notifications.redirectTo=dt@kapitanweb.ru
>>>>>>>>>>>>>>>> mail.smtp.relay.host=smtp.gmail.com
>>>>>>>>>>>>>>>> mail.smtp.auth.user=dmtsyganok@gmail.com
>>>>>>>>>>>>>>>> mail.smtp.auth.password=*******
>>>>>>>>>>>>>>>> mail.smtp.port=465
>>>>>>>>>>>>>>>> mail.smtp.starttls.enable=true
>>>>>>>>>>>>>>>> mail.smtp.socketFactory.port=465
>>>>>>>>>>>>>>>> mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
>>>>>>>>>>>>>>>> mail.smtp.socketFactory.fallback=false
>>>>>>>>>>>>>>>> mail.address.caseInsensitive=N
>>>>>>>>>>>>>>>> mail.debug.on=N
>>>>>>>>>>>>>>>> mail.smtp.sendpartial=true
>>>>>>>>>>>>>>>> http.upload.max.sizethreshold=10240
>>>>>>>>>>>>>>>> http.upload.tmprepository=runtime/tmp
>>>>>>>>>>>>>>>> http.upload.max.size=-1
>>>>>>>>>>>>>>>> mail.spam.name=X-Spam-Flag
>>>>>>>>>>>>>>>> mail.spam.value=YES
>>>>>>>>>>>>>>>> Ofbiz always issues this error in the logs and the mail is not
>>>>>>>>>>>>>>>> sent:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> " 2018-01-17 22:21:19,562 |OFBiz-JobQueue-1 |EmailServices
>>>>>>>>>>>>>>>> |I| Mail notifications disabled in
>>>>>>>>>>>>>>>> general.properties; mail
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> subject [test] not sent to addressee [ dt@kapitanweb.ru "
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I also tried different mail accounts, but the result is always
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What could be the reason? Please help me to solve this
>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>> Thank you very much in advance!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Dmitriy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
>
Re: Deprecate properties in favour of SystemProperties
Posted by Jacques Le Roux <ja...@les7arts.com>.
To clarify, I'll do a recollection of all in a new Thread where I'll summarize. There are indeed several aspects.
Jacques
Le 05/04/2018 à 09:26, Taher Alkhateeb a écrit :
> 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 <ja...@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 should have
>> been named BusinessProperty. We could consider rename it, but that's minor
>> in 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 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 <
>> https://markmail.org/message/opldepaevls3y3ob> 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.
>>
>> 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 think it's
>> a
>>> good 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 <sl...@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
>>>> <ja...@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 have
>>>> completed my
>>>>>> proposition
>>>>> Since there were some more comments after is al link to my comment with
>>>> my
>>>>> completed my proposition https://s.apache.org/7uwl
>>>>>
>>>>> Jacques
>>>>>
>>
Re: Deprecate properties in favour of SystemProperties
Posted by Michael Brohl <mi...@ecomify.de>.
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
> <ja...@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 <sl...@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.roux@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 should
>>>> have
>>>>> been named BusinessProperty. We could consider rename it, but that's
>>>> minor
>>>>> in 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 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 <
>>>>> https://markmail.org/message/opldepaevls3y3ob> 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.
>>>>> 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 think
>>>> it's
>>>>> a
>>>>>> good 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 <sl...@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
>>>>>>> <ja...@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 have
>>>>>>> completed my
>>>>>>>>> proposition
>>>>>>>> Since there were some more comments after is al link to my comment
>>>> with
>>>>>>> my
>>>>>>>> completed my proposition https://s.apache.org/7uwl
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
Re: Deprecate properties in favour of SystemProperties
Posted by Taher Alkhateeb <sl...@gmail.com>.
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
<ja...@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 <sl...@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.roux@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 should
>>>
>>> have
>>>>
>>>> been named BusinessProperty. We could consider rename it, but that's
>>>
>>> minor
>>>>
>>>> in 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 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 <
>>>> https://markmail.org/message/opldepaevls3y3ob> 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.
>>>>
>>>> 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 think
>>>
>>> it's
>>>>
>>>> a
>>>>>
>>>>> good 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 <sl...@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
>>>>>> <ja...@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 have
>>>>>>
>>>>>> completed my
>>>>>>>>
>>>>>>>> proposition
>>>>>>>
>>>>>>> Since there were some more comments after is al link to my comment
>>>
>>> with
>>>>>>
>>>>>> my
>>>>>>>
>>>>>>> completed my proposition https://s.apache.org/7uwl
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>
>
Re: Deprecate properties in favour of SystemProperties
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <sl...@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.roux@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 should
>> have
>>> been named BusinessProperty. We could consider rename it, but that's
>> minor
>>> in 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 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 <
>>> https://markmail.org/message/opldepaevls3y3ob> 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.
>>> 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 think
>> it's
>>> a
>>>> good 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 <sl...@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
>>>>> <ja...@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 have
>>>>> completed my
>>>>>>> proposition
>>>>>> Since there were some more comments after is al link to my comment
>> with
>>>>> my
>>>>>> completed my proposition https://s.apache.org/7uwl
>>>>>>
>>>>>> Jacques
>>>>>>
>>>
Re: Deprecate properties in favour of SystemProperties
Posted by Scott Gray <sc...@hotwaxsystems.com>.
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 <sl...@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.roux@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 should
> have
> > been named BusinessProperty. We could consider rename it, but that's
> minor
> > in 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 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 <
> > https://markmail.org/message/opldepaevls3y3ob> 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.
> >
> > 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 think
> it's
> > a
> > > good 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 <sl...@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
> > >> <ja...@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 have
> > >> completed my
> > >>>> proposition
> > >>> Since there were some more comments after is al link to my comment
> with
> > >> my
> > >>> completed my proposition https://s.apache.org/7uwl
> > >>>
> > >>> Jacques
> > >>>
> >
> >
>
Re: Deprecate properties in favour of SystemProperties
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <ja...@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 should have
> been named BusinessProperty. We could consider rename it, but that's minor
> in 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 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 <
> https://markmail.org/message/opldepaevls3y3ob> 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.
>
> 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 think it's
> a
> > good 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 <sl...@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
> >> <ja...@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 have
> >> completed my
> >>>> proposition
> >>> Since there were some more comments after is al link to my comment with
> >> my
> >>> completed my proposition https://s.apache.org/7uwl
> >>>
> >>> Jacques
> >>>
>
>
Re: Deprecate properties in favour of SystemProperties
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 should have been named BusinessProperty. We could consider rename it, but that's minor
in 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 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 <https://markmail.org/message/opldepaevls3y3ob> 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.
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 think it's a
> good 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 <sl...@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
>> <ja...@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 have
>> completed my
>>>> proposition
>>> Since there were some more comments after is al link to my comment with
>> my
>>> completed my proposition https://s.apache.org/7uwl
>>>
>>> Jacques
>>>
Re: Deprecate properties in favour of SystemProperties
Posted by Scott Gray <sc...@hotwaxsystems.com>.
If there's an ongoing discussion on the dev list then I don't think it's a
good 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 <sl...@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
> <ja...@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 have
> completed my
> >> proposition
> >
> > Since there were some more comments after is al link to my comment with
> my
> > completed my proposition https://s.apache.org/7uwl
> >
> > Jacques
> >
>
Re: Deprecate properties in favour of SystemProperties
Posted by Taher Alkhateeb <sl...@gmail.com>.
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
<ja...@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 have completed my
>> proposition
>
> Since there were some more comments after is al link to my comment with my
> completed my proposition https://s.apache.org/7uwl
>
> Jacques
>
Re: Deprecate properties in favour of SystemProperties
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 have completed my proposition
Since there were some more comments after is al link to my comment with my completed my proposition https://s.apache.org/7uwl
Jacques