Le 16/02/2018 à 18:18, Taher Alkhateeb a écrit :
That could be probably an incredibly dangerous and complexity-inudcing
idea. Imagine what you are suggesting, a massive state machine, implied and
not explicit (a massive global collection of variables).
Are you thinking about the properties files in 
/framework/start/src/main/java/org/apache/ofbiz/base/start ?

If so then I should have say that those are not concerned by my proposition, 
they are needed at start and can't stay in the DB.

If you are thinking about the properties as a whole, then I'm not sure to 
understand you. And I'd need more details.

We have already some SystemProperties. They have been introduced because of 
multi-tenant, are you against of them? Why? Do you think at a better solution?

BTW, SystemProperty is IMO a wrong name for them. EntityProperty or even simply Property would have been better and less confusing, because they are business and not system properties.


In my opinion explicit is always better than implicit and we should strive
to actually reduce all properties and things to hold in memory, because
that is exactly the source of confusion and spaghetti code that we suffer
from today.
Do you mean that you would want the properties not being cached?

Jacques


-1 from my side.

On Feb 16, 2018 6:12 PM, "Jacques Le Roux" <jacques.le.r...@les7arts.com>
wrote:

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.br...@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.r...@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="
ofbizt...@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.r...@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, Дмитрий Цыганок <d...@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=dmtsyga...@gmail.com
mail.notifications.enabled=Y
mail.notifications.redirectTo=d...@kapitanweb.ru
mail.smtp.relay.host=smtp.gmail.com
mail.smtp.auth.user=dmtsyga...@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 [ d...@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








Reply via email to