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.br...@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.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
