Deprecate properties in favour of SystemProperties [ was Re: Sending mail from Ofbiz does not work]
Locked
Deprecate properties in favour of SystemProperties [ was Re: Sending mail from Ofbiz does not work]
 
Administrator
|
Re: Deprecate properties in favour of SystemProperties [ was Re: Sending mail from Ofbiz does not work]
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties [ was Re: Sending mail from Ofbiz does not work]
|
In reply to this post by Jacques Le Roux
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 >>> <[hidden email]> >>> 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 < >>>>> [hidden email]> 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=" >>>>>>> [hidden email]" >>>>>>> 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 < >>>>>>> [hidden email]> 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, Дмитрий Цыганок >>>>>>>>>> <[hidden email]> >>>>>>>>>> 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=[hidden email] >>>>>>>>>>> mail.notifications.enabled=Y >>>>>>>>>>> mail.notifications.redirectTo=[hidden email] >>>>>>>>>>> mail.smtp.relay.host=smtp.gmail.com >>>>>>>>>>> mail.smtp.auth.user=[hidden email] >>>>>>>>>>> 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 [ [hidden email] " >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> >> >> > > |
smime.p7s (5K)
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
|
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 >>>>> <[hidden email]> >>>>> 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 < >>>>>>> [hidden email]> 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=" >>>>>>>>> [hidden email]" >>>>>>>>> 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 < >>>>>>>>> [hidden email]> 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, Дмитрий Цыганок >>>>>>>>>>>> <[hidden email]> >>>>>>>>>>>> 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=[hidden email] >>>>>>>>>>>>> mail.notifications.enabled=Y >>>>>>>>>>>>> mail.notifications.redirectTo=[hidden email] >>>>>>>>>>>>> mail.smtp.relay.host=smtp.gmail.com >>>>>>>>>>>>> mail.smtp.auth.user=[hidden email] >>>>>>>>>>>>> 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 [ [hidden email] " >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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
|
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
|
Re: Deprecate properties in favour of SystemProperties
|
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
|
Re: Deprecate properties in favour of SystemProperties
|
Administrator
|
Re: Deprecate properties in favour of SystemProperties
|
|
Re: Deprecate properties in favour of SystemProperties
|
|
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 > <[hidden email]> 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 <[hidden email]> >>> 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 >>>> <[hidden email] >>>> 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 <[hidden email]> >>>>>> 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 >>>>>>> <[hidden email]> 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 >>>>>>>> |
| Free forum by Nabble | Edit this page |