ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Deprecate properties in favour of SystemProperties
Date Sun, 18 Feb 2018 12:37:43 GMT
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
> <michael.brohl@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
>>>>>>> <michael.brohl@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>


Mime
View raw message