Re: [DOC] Re-starting our OFBiz Documentation Effort

[Swapnil Mane]

Thanks, Sharan for bringing this thread back to life :-)
After a long break in this, I am also now available for this effort.


- Best Regards,
Swapnil M Mane


On Thu, Aug 9, 2018 at 3:55 PM Taher Alkhateeb 
wrote:

> If there are any volunteers that need mentoring at this moment I might
> be able to assist. And it's great to re-energize this critical project
> that seems to be more necessary than ever.
>
> On Mon, Aug 6, 2018 at 2:06 PM, Sharan Foga  wrote:
> > Hi All
> >
> > Our documentation effort has stalled a little.  Partly due to me being
> involved in other Apache activities related to the EU Roadshow. Anyway that
> event is now completed so I’d like to look at getting people started
> working on our documentation again.
> >
> > So first let’s see where we are. This was our team list of people
> wanting to help out.
> >
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Documentation+Team
> >
> > Mentors
> > Please can you contact the people you are mentoring to see if they are
> still interested in helping out and if they need your support
> >
> > Volunteers
> > If you don’t have a mentor but still want to help out then please
> respond to this thread.
> >
> > JIRA Status
> > We are tracking work related to the Human Resources manual under the
> following JIRA
> >
> > https://issues.apache.org/jira/browse/OFBIZ-10251
> >
> > I think we need to focus on getting as much content as possible. Once we
> have the content then we can re-arrange it or format it as necessary.
> >
> > Our aim is to provide enough information for someone who has not seen
> the OFBIz Human Resources application before, to have enough information
> about each of the areas to be able to know how to use them.
> >
> > Next Step
> > Review the patches that have been submitted and commit them or provide
> feedback
> > Continue to migrate, update and complete the content for the Human
> Resources manual
> >
> > So let’s see if we can get things moving again :-) and as always all
> ideas, comments and feedback welcome.
> >
> > Thanks
> > Sharan
> >
>

Re: Should we keep the multi-tenants feature in OFBiz?

[Rajesh Mallah]

Hi  ,

I strongly feel we should.

For me, multi-tenency is the key feature in supporting more number of
organisations
with a single instance of Java/tomcat. Think of running 20  under-utilized
OFBiz instances
each *locking* up say 1GB ram versus 1 multi-tenant OFBiz instance
allocated with a
copious amount of RAM say 4-8GB ram.

a dozens or maybe even few hundreds tenants, after it begin to be a lot of
> DBs!
>

I would want to understand for whom does it becomes a *lot* of DB ?
In case it is about persistent connections to 100s' of distinct uris (ie.
host+user+db combination)
from the JDBC pool, we can offload the connection pooling feature to an
external
pooler , (eg: pgpool or pgbouncer , in case of postgreSQL) , and convert
the connection
mode from persistent to non-persistent at the tomcat level . So a *new*
connection is made
on a HTTP request and disconnected as soon as the request is served.
in oracle we have:
https://docs.oracle.com/cd/B28359_01/appdev.111/b28395/oci09adv.htm#LNOCI87721
in postgreSQL:
https://dba.stackexchange.com/questions/56559/postgresql-high-availability-scalability-using-haproxy-and-pgbouncer
In case it is the sheer number of db connections i feel users can come up
with their own
architectures suiting their environment.

(disclaimer: I am not expert in tomcat but i am trying to draw parallels
with other application servers)

And its not only a matter of resource sharing only, deploying  a new client
on a multi tenant OFBiz
instance is 10 times simpler than creating a new instance and configuring a
new OFBiz instance
itself ( discounting the factor or chef/puppet /salt/ansible/your favorite
automation tool) .

I feel It will be a big loss unless an equivalent feature is found out ,
the equivalent  IMHO is multi-tenant feature itself without the warts :-).

@Jacques Le Roux   there is also:
https://issues.apache.org/jira/browse/OFBIZ-10284 for which i had worked on
a patch.

my 2 cents

regds
mallah.


On Wed, Aug 29, 2018 at 6:19 PM Shi Jinghai  wrote:

> Hi Jacques,
>
> Honestly I was shocked by this email, I'm working on deploying OFBiz in
> Kubernetes, are you monitoring me?
>
> In 2010, Kubernetes was quite new and not good enough, now it's the
> standard on cloud deploy management, and we can support it.
>
> Before doing that, we have to answer some common questions in cloud
> running lifecycle, such as how may instances/requests can share one CPU,
> how to deliver(create) an instance, how to isolate an instance, how to
> offline, how to remove, how to online again and etc.
>
> Personally I don't think we have to remove current multi-tenants
> implements, add a SAAS implement would be OK.
>
> Kind Regards,
>
> Shi Jinghai
>
>
> -邮件原件-
> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
> 发送时间: 2018年8月29日 17:46
> 收件人: dev@ofbiz.apache.org
> 主题: Should we keep the multi-tenants feature in OFBiz?
>
> Hi,
>
> The multi-tenants feature in OFBiz only allows a dozens or maybe even few
> hundreds tenants, after it begin to be a lot of DBs!
> I faced that with a startup which wanted to handle thousands, if not
> millions (actually they failed), of tenants, obviously OFBiz can't do that.
>
> I don't break any secret to say that I was working with David (and Andrew)
> on a project in 2010 when David had to quickly answer to the client's
> demand who wanted to have tenants. David brilliantly and quickly
> delivered, but it was only a start.
>
> After many improvements, this feature still have some issues
>  https://issues.apache.org/jira/browse/OFBIZ-6066
>  https://issues.apache.org/jira/browse/OFBIZ-7900
>  https://issues.apache.org/jira/browse/OFBIZ-6164
>  https://issues.apache.org/jira/browse/OFBIZ-6065
>
> Also this is somehow related
>  https://issues.apache.org/jira/browse/OFBIZ-6712
>
> And most importantly
>  https://issues.apache.org/jira/browse/OFBIZ-7112
>  https://issues.apache.org/jira/browse/OFBIZ-7754
>
> I recently read this article
>
>
> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
>
> and, after my experiences with multi-tenant as is in OFBiz, it made me
> wonder if we should not think about how it's done now in OFBiz in 2018 with
> the
> clouds being everywhere!
>
> Before sending this email, I quickly exchanged with David about how Moqui
> handles that now. And we are on the same page, see
>
> https://www.linkedin.com/groups/4640689/4640689-6180851287941201924
>
>
> https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
> [1]
>
> [1] Initially David gave me this link
>
> https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/
>
> but it seems LinkedIn has lost it, as said in the stackoverflow comment.
>
> So IMO why not deprecating the multi-tenants as is now and rather push a
> multi-instances way?
>
> Opinions?
>
> Jacques
>
>

Re: Should we keep the multi-tenants feature in OFBiz?

[Shi Jinghai]

Hi Jacques,

Honestly I was shocked by this email, I'm working on deploying OFBiz in 
Kubernetes, are you monitoring me?

In 2010, Kubernetes was quite new and not good enough, now it's the standard on 
cloud deploy management, and we can support it.

Before doing that, we have to answer some common questions in cloud running 
lifecycle, such as how may instances/requests can share one CPU, how to 
deliver(create) an instance, how to isolate an instance, how to offline, how to 
remove, how to online again and etc.

Personally I don't think we have to remove current multi-tenants implements, 
add a SAAS implement would be OK.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 
发送时间: 2018年8月29日 17:46
收件人: dev@ofbiz.apache.org
主题: Should we keep the multi-tenants feature in OFBiz?

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not millions 
(actually they failed), of tenants, obviously OFBiz can't do that.

I don't break any secret to say that I was working with David (and Andrew) on a 
project in 2010 when David had to quickly answer to the client's 
demand who wanted to have tenants. David brilliantly and quickly delivered, but 
it was only a start.

After many improvements, this feature still have some issues
     https://issues.apache.org/jira/browse/OFBIZ-6066
     https://issues.apache.org/jira/browse/OFBIZ-7900
     https://issues.apache.org/jira/browse/OFBIZ-6164
     https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
     https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
     https://issues.apache.org/jira/browse/OFBIZ-7112
     https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article

https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/

and, after my experiences with multi-tenant as is in OFBiz, it made me wonder 
if we should not think about how it's done now in OFBiz in 2018 with the 
clouds being everywhere!

Before sending this email, I quickly exchanged with David about how Moqui 
handles that now. And we are on the same page, see

https://www.linkedin.com/groups/4640689/4640689-6180851287941201924

https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
 [1]

[1] Initially David gave me this link

https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/

but it seems LinkedIn has lost it, as said in the stackoverflow comment.

So IMO why not deprecating the multi-tenants as is now and rather push a 
multi-instances way?

Opinions?

Jacques

Re: Should we keep the multi-tenants feature in OFBiz?

[Arun Patidar]

+1 Taher for checking the dependencies of OFBiz users on tenant feature.

As both the options create multiple numbers of databases. Before
deprecating/removing multi-tenancy, we should check all the pros and cons
of the Multi-instance option as an alternate in OFBiz.
We will not want to add another feature with similar or other limitations.
At a time any one of the features should exist in OFBiz instead of adding
backward compatibility. This may make the code more complex.

IMO, existing tenant issues are not critical or blocker.



Kind Regards,

Arun Patidar
Director of Information Systems

*HotWax CommerceReal OmniChannel. Real Results.*
m: +91 9827353082
w: www.hotwax.c o 
 





On Wed, Aug 29, 2018 at 4:06 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Yes you are right, I'll start a discussion on user ML.
>
> I already know that Pierre Smits uses it for his own projects, and indeed
> we know there are more people using it.
>
> This said it should not prevent us to deprecate it and users to continue
> to use it based on R17 branch.
>
> They could then switch later to the replacing feature. If we do so, we
> should try to deliver a migration tool, maybe with their interested help...
>
> At the end it's the dev community to decide, we can get blocked by our
> users, notably because there are issues pending for too long, w/o much
> interest.
>
> Let's see on user ML
>
> Jacques
>
>
> Le 29/08/2018 à 12:05, Taher Alkhateeb a écrit :
> > Multi-tenancy complicates things, and the code could be made simpler
> > by removing it in many areas of the system. So technically, I'm for
> > that.
> >
> > However, the issue here is whether enough people depend on it. I saw
> > multiple questions in the mailing list in the past about multi-tenancy
> > in the past, so I'm just not sure if people depend on it or not. Maybe
> > shooting that question in the user ML would help shed some perspective
> > on it?
> >
> > With our appreciation for all the good work people are doing in their
> > projects, I think we should be focused on OFBiz and what is best for
> > _this_ project. If some project decides to drop multi-tenancy I don't
> > think we should be influenced or automatically follow suit. So naming
> > who-did-what might not important for this discussion and we need to
> > bake our own bread.
> > On Wed, Aug 29, 2018 at 12:45 PM Jacques Le Roux
> >  wrote:
> >> Hi,
> >>
> >> The multi-tenants feature in OFBiz only allows a dozens or maybe even
> few hundreds tenants, after it begin to be a lot of DBs!
> >> I faced that with a startup which wanted to handle thousands, if not
> millions (actually they failed), of tenants, obviously OFBiz can't do that.
> >>
> >> I don't break any secret to say that I was working with David (and
> Andrew) on a project in 2010 when David had to quickly answer to the
> client's
> >> demand who wanted to have tenants. David brilliantly and quickly
> delivered, but it was only a start.
> >>
> >> After many improvements, this feature still have some issues
> >>   https://issues.apache.org/jira/browse/OFBIZ-6066
> >>   https://issues.apache.org/jira/browse/OFBIZ-7900
> >>   https://issues.apache.org/jira/browse/OFBIZ-6164
> >>   https://issues.apache.org/jira/browse/OFBIZ-6065
> >>
> >> Also this is somehow related
> >>   https://issues.apache.org/jira/browse/OFBIZ-6712
> >>
> >> And most importantly
> >>   https://issues.apache.org/jira/browse/OFBIZ-7112
> >>   https://issues.apache.org/jira/browse/OFBIZ-7754
> >>
> >> I recently read this article
> >>
> >>
> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
> >>
> >> and, after my experiences with multi-tenant as is in OFBiz, it made me
> wonder if we should not think about how it's done now in OFBiz in 2018 with
> the
> >> clouds being everywhere!
> >>
> >> Before sending this email, I quickly exchanged with David about how
> Moqui handles that now. And we are on the same page, see
> >>
> >> https://www.linkedin.com/groups/4640689/4640689-6180851287941201924
> >>
> >>
> https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
> [1]
> >>
> >> [1] Initially David gave me this link
> >>
> >>
> https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/
> >>
> >> but it seems LinkedIn has lost it, as said in the stackoverflow comment.
> >>
> >> So IMO why not deprecating the multi-tenants as is now and rather push
> a multi-instances way?
> >>
> >> Opinions?
> >>
> >> Jacques
> >>
>
>

Re: Should we keep the multi-tenants feature in OFBiz?

[Jacques Le Roux]

Le 29/08/2018 à 12:05, Taher Alkhateeb a écrit :

If some project decides to drop multi-tenancy I don't
think we should be influenced or automatically follow suit. So naming
who-did-what might not important for this discussion and we need to
bake our own bread.

I was not influenced by David's decision on multi-tenants for Moqui. It only 
confirms what I was wondering about.
Actually it was only after asking David for his permission to talk about the work we did together in 2010 that it occurred to me that Moqui is now 
using the multi-instances way. I did not know.
It was after reading the LinkedIn article I re-tweeted few weeks ago [1], that I began to think about the situation, though it's a long time I'm 
worried about it, as the Jira references I used show.

[1]  https://twitter.com/ghohpe/status/1026179522562011137

And to complete my previous answer, we indeed need to care, because it's an 
important (architectural) decision.

Jacques

Re: Should we keep the multi-tenants feature in OFBiz?

[Michael Brohl]

Before we deprecate this feature (if ever) we should provide a well 
designed, fully tested and established alternative as well as a 
migration path and good documentation.


I propose to do any work on this in another branch to prevent any 
distraction in trunk until this change is fully established. I assume 
that this is going to be a longer task...


Regards,

Michael


Am 29.08.18 um 12:36 schrieb Jacques Le Roux:

Yes you are right, I'll start a discussion on user ML.

I already know that Pierre Smits uses it for his own projects, and 
indeed we know there are more people using it.


This said it should not prevent us to deprecate it and users to 
continue to use it based on R17 branch.


They could then switch later to the replacing feature. If we do so, we 
should try to deliver a migration tool, maybe with their interested 
help...


At the end it's the dev community to decide, we can get blocked by our 
users, notably because there are issues pending for too long, w/o much 
interest.


Let's see on user ML

Jacques


Le 29/08/2018 à 12:05, Taher Alkhateeb a écrit :

Multi-tenancy complicates things, and the code could be made simpler
by removing it in many areas of the system. So technically, I'm for
that.

However, the issue here is whether enough people depend on it. I saw
multiple questions in the mailing list in the past about multi-tenancy
in the past, so I'm just not sure if people depend on it or not. Maybe
shooting that question in the user ML would help shed some perspective
on it?

With our appreciation for all the good work people are doing in their
projects, I think we should be focused on OFBiz and what is best for
_this_ project. If some project decides to drop multi-tenancy I don't
think we should be influenced or automatically follow suit. So naming
who-did-what might not important for this discussion and we need to
bake our own bread.
On Wed, Aug 29, 2018 at 12:45 PM Jacques Le Roux
 wrote:

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe 
even few hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not 
millions (actually they failed), of tenants, obviously OFBiz can't 
do that.


I don't break any secret to say that I was working with David (and 
Andrew) on a project in 2010 when David had to quickly answer to the 
client's
demand who wanted to have tenants. David brilliantly and quickly 
delivered, but it was only a start.


After many improvements, this feature still have some issues
  https://issues.apache.org/jira/browse/OFBIZ-6066
  https://issues.apache.org/jira/browse/OFBIZ-7900
  https://issues.apache.org/jira/browse/OFBIZ-6164
  https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
  https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
  https://issues.apache.org/jira/browse/OFBIZ-7112
  https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article

https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ 



and, after my experiences with multi-tenant as is in OFBiz, it made 
me wonder if we should not think about how it's done now in OFBiz in 
2018 with the

clouds being everywhere!

Before sending this email, I quickly exchanged with David about how 
Moqui handles that now. And we are on the same page, see


https://www.linkedin.com/groups/4640689/4640689-6180851287941201924

https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 
[1]


[1] Initially David gave me this link

https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ 



but it seems LinkedIn has lost it, as said in the stackoverflow 
comment.


So IMO why not deprecating the multi-tenants as is now and rather 
push a multi-instances way?


Opinions?

Jacques








smime.p7s
Description: S/MIME Cryptographic Signature

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Jacques Le Roux]

I'll soon provide an AsciiDoc for that. I have to think about its location, any 
ideas?

Jacques


Le 29/08/2018 à 12:06, Taher Alkhateeb a écrit :

I couldn't find the testing mechanism and the JIRA is filled with too
much information. Sharing a simple testing mechanism would help
On Wed, Aug 29, 2018 at 12:33 PM Jacques Le Roux
 wrote:

Hi Taher,

Before creating the last patch, I have reviewed the code a last time again,  
it's totally OK now. Did you test from
https://localhost:8443/catalog/control/FindCatalog with the provided test patch?

I'll now provide a simple and concise AsciiDoc documentation. Maybe with a 
graph, but that's not sure, I have to try...

For the test part I'll wait for the user ML "OFBiz Sanity Test Automation" 
thread https://markmail.org/message/nxoyqxn7lqfupf55 to conclude before
endeavouring in web tests

I don't think it should stop to commit this work, which can be tested manually 
using the provided patches (though the one from example needs the
commit to be done)

Anyway I'll wait more feedbacks before committing, I'm not in a hurry and I 
know it's a sensitive feature.

Jacques


Le 27/08/2018 à 14:55, Taher Alkhateeb a écrit :

I already found problems in this code to give me pause and to show
that it is not properly studied and designed. If you want to continue
the effort, then I recommend reviewing your code thoroughly, providing
a clear testing mechanism (especially the web scripts), and ask for
reviews and tests.
On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
 wrote:

Hi Taher,

Thanks for your review, much appreciated.


Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :

I reviewed the code and explanation in the beginning of this thread
and I have the following comments:

- First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
you are still returning "success". Does not make sense at all.

You are right I should have used "error".
I did not notice (actually forgot a last own review after much variations in 
code) because it's an event preprocessor and no response is
expected/handled.
Not to bad, in case of error just an EventHandlerException was not thrown.


- Also the comments are unnecessary and do not make sense in the same code block

You mean "// Something unexpected happened here", or ?


- The comment you wrote: "Check it's the right tenant in case username
and password are the same in different tenants. Not sure this is
really useful in the case of external server, does not hurt anyway" is
self-defeating. Never put in code you won't use. We have enough mess
in the code base.

I must say I initially copied that from 
ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the context. 
It's roughly the same code.
I let it there because I was then unsure. But when you think about it, there is 
no reason to not make this check. So I'll simply remove the comment. I
should have put a TODO.

BTW this is out of subject and I'll start a new thread about it after reading
https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
The subject will be: "Should we keep the multi-tenants feature in OFBiz."
I though think the tenants in OFBiz are still useful when you only needs dozens 
or maybe even few hundreds tenants (begin to be a lot of DBs!).
But I faced that with a startup which wanted to handle thousands, if not 
millions (actually they failed), of tenants, obviously OFBiz can't do that.


- Calling LoginWorker.doBasicLogin(userLogin, request) after the
if/else block does not make sense. The else block guarantees falling
into the exception. This whole code block needs refactoring

You are totally right, I have uploaded a new patch where I put the call of
   LoginWorker.doBasicLogin(userLogin, request);
in the positive part of the if and used the same block pattern than above where 
there is a warning log then returning an error.
I was so focused on the other parts of the mechanism, especially to secure it, 
than I forgot to review the Java part.
My bad, thank you again for your review.


- A testing method needs to be provided in detail. For example I'm not
sure how the Javascript portions will execute and when. So some
provision of a clear testing mechanism is necessary.

Yep, right, I'll document all the mechanism and how to use it. Pierre even 
proposed to make a graph in AsciiDoc, not sure I'll be able to, by I'll try.
Actually it's only a matter of following what should be in the example 
component, see last OFBIZ-10307-test from example.patch.
I thought it would be enough for devs. I understand it's not, a bit of clear 
documentation is always welcomed, and I often advocate for it.


- Finally, I'm not sure this feature is needed at all. Why not just
assign an LDAP server to take care of OFBiz and non-OFBiz in a single
sign-on environment.

Because you don't need to have (install, maintain, etc.) a LDAP server, or 
whatnot (CAS, Oauth2, SAML, you name it) if you use this code, it's ready OOTB.


  

Re: Should we keep the multi-tenants feature in OFBiz?

[Jacques Le Roux]

Yes you are right, I'll start a discussion on user ML.

I already know that Pierre Smits uses it for his own projects, and indeed we 
know there are more people using it.

This said it should not prevent us to deprecate it and users to continue to use 
it based on R17 branch.

They could then switch later to the replacing feature. If we do so, we should 
try to deliver a migration tool, maybe with their interested help...

At the end it's the dev community to decide, we can get blocked by our users, 
notably because there are issues pending for too long, w/o much interest.

Let's see on user ML

Jacques


Le 29/08/2018 à 12:05, Taher Alkhateeb a écrit :

Multi-tenancy complicates things, and the code could be made simpler
by removing it in many areas of the system. So technically, I'm for
that.

However, the issue here is whether enough people depend on it. I saw
multiple questions in the mailing list in the past about multi-tenancy
in the past, so I'm just not sure if people depend on it or not. Maybe
shooting that question in the user ML would help shed some perspective
on it?

With our appreciation for all the good work people are doing in their
projects, I think we should be focused on OFBiz and what is best for
_this_ project. If some project decides to drop multi-tenancy I don't
think we should be influenced or automatically follow suit. So naming
who-did-what might not important for this discussion and we need to
bake our own bread.
On Wed, Aug 29, 2018 at 12:45 PM Jacques Le Roux
 wrote:

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not millions 
(actually they failed), of tenants, obviously OFBiz can't do that.

I don't break any secret to say that I was working with David (and Andrew) on a 
project in 2010 when David had to quickly answer to the client's
demand who wanted to have tenants. David brilliantly and quickly delivered, but 
it was only a start.

After many improvements, this feature still have some issues
  https://issues.apache.org/jira/browse/OFBIZ-6066
  https://issues.apache.org/jira/browse/OFBIZ-7900
  https://issues.apache.org/jira/browse/OFBIZ-6164
  https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
  https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
  https://issues.apache.org/jira/browse/OFBIZ-7112
  https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article

https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/

and, after my experiences with multi-tenant as is in OFBiz, it made me wonder 
if we should not think about how it's done now in OFBiz in 2018 with the
clouds being everywhere!

Before sending this email, I quickly exchanged with David about how Moqui 
handles that now. And we are on the same page, see

https://www.linkedin.com/groups/4640689/4640689-6180851287941201924

https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
 [1]

[1] Initially David gave me this link

https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/

but it seems LinkedIn has lost it, as said in the stackoverflow comment.

So IMO why not deprecating the multi-tenants as is now and rather push a 
multi-instances way?

Opinions?

Jacques

Re: [Proposal] Enhance the controller logic to accommodate HTTP methods and prepare for REST

[Julien NICOLAS]

+1 to move forward.

Julien.


Le 09/08/2018 à 17:31, Taher Alkhateeb a écrit :

Hello Everyone,

We want to make this formal with proper community consensus and I will
try to keep this short.

In [1] Mathieu Lirzin is providing some (in my opinion) good work on
converting the Control Servlet logic to be able to handle the
different HTTP methods (GET, POST, etc ...) The purpose of the work in
this JIRA is simple. You should be able to call a request with a
different HTTP methods by using a format like . You can find a more detailed discussion in [2]. This
is the first step of a multi-step process to be able to integrate REST
API with OFBiz.

So, this is a proposal to apply the following:
1- Enhance the controller to be able to accommodate one-or-more HTTP
methods (method="GET,POST")
2- Enhance the controller to further be able to get "patterns" that
can be mapped to REST APIs. So a request like
https://host/control/request/customer/orders/1/orderName can be
processed as a resource

Please correct me if I was wrong on anything written here Mathieu, and
please everyone provide your feedback if you approve of moving forward
with this initiative.

[1] https://issues.apache.org/jira/browse/OFBIZ-10438
[2] https://s.apache.org/ec2r

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Taher Alkhateeb]

I couldn't find the testing mechanism and the JIRA is filled with too
much information. Sharing a simple testing mechanism would help
On Wed, Aug 29, 2018 at 12:33 PM Jacques Le Roux
 wrote:
>
> Hi Taher,
>
> Before creating the last patch, I have reviewed the code a last time again,  
> it's totally OK now. Did you test from
> https://localhost:8443/catalog/control/FindCatalog with the provided test 
> patch?
>
> I'll now provide a simple and concise AsciiDoc documentation. Maybe with a 
> graph, but that's not sure, I have to try...
>
> For the test part I'll wait for the user ML "OFBiz Sanity Test Automation" 
> thread https://markmail.org/message/nxoyqxn7lqfupf55 to conclude before
> endeavouring in web tests
>
> I don't think it should stop to commit this work, which can be tested 
> manually using the provided patches (though the one from example needs the
> commit to be done)
>
> Anyway I'll wait more feedbacks before committing, I'm not in a hurry and I 
> know it's a sensitive feature.
>
> Jacques
>
>
> Le 27/08/2018 à 14:55, Taher Alkhateeb a écrit :
> > I already found problems in this code to give me pause and to show
> > that it is not properly studied and designed. If you want to continue
> > the effort, then I recommend reviewing your code thoroughly, providing
> > a clear testing mechanism (especially the web scripts), and ask for
> > reviews and tests.
> > On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
> >  wrote:
> >> Hi Taher,
> >>
> >> Thanks for your review, much appreciated.
> >>
> >>
> >> Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :
> >>> I reviewed the code and explanation in the beginning of this thread
> >>> and I have the following comments:
> >>>
> >>> - First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
> >>> you are still returning "success". Does not make sense at all.
> >> You are right I should have used "error".
> >> I did not notice (actually forgot a last own review after much variations 
> >> in code) because it's an event preprocessor and no response is
> >> expected/handled.
> >> Not to bad, in case of error just an EventHandlerException was not thrown.
> >>
> >>> - Also the comments are unnecessary and do not make sense in the same 
> >>> code block
> >> You mean "// Something unexpected happened here", or ?
> >>
> >>> - The comment you wrote: "Check it's the right tenant in case username
> >>> and password are the same in different tenants. Not sure this is
> >>> really useful in the case of external server, does not hurt anyway" is
> >>> self-defeating. Never put in code you won't use. We have enough mess
> >>> in the code base.
> >> I must say I initially copied that from 
> >> ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the 
> >> context. It's roughly the same code.
> >> I let it there because I was then unsure. But when you think about it, 
> >> there is no reason to not make this check. So I'll simply remove the 
> >> comment. I
> >> should have put a TODO.
> >>
> >> BTW this is out of subject and I'll start a new thread about it after 
> >> reading
> >> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
> >> The subject will be: "Should we keep the multi-tenants feature in OFBiz."
> >> I though think the tenants in OFBiz are still useful when you only needs 
> >> dozens or maybe even few hundreds tenants (begin to be a lot of DBs!).
> >> But I faced that with a startup which wanted to handle thousands, if not 
> >> millions (actually they failed), of tenants, obviously OFBiz can't do that.
> >>
> >>> - Calling LoginWorker.doBasicLogin(userLogin, request) after the
> >>> if/else block does not make sense. The else block guarantees falling
> >>> into the exception. This whole code block needs refactoring
> >> You are totally right, I have uploaded a new patch where I put the call of
> >>   LoginWorker.doBasicLogin(userLogin, request);
> >> in the positive part of the if and used the same block pattern than above 
> >> where there is a warning log then returning an error.
> >> I was so focused on the other parts of the mechanism, especially to secure 
> >> it, than I forgot to review the Java part.
> >> My bad, thank you again for your review.
> >>
> >>> - A testing method needs to be provided in detail. For example I'm not
> >>> sure how the Javascript portions will execute and when. So some
> >>> provision of a clear testing mechanism is necessary.
> >> Yep, right, I'll document all the mechanism and how to use it. Pierre even 
> >> proposed to make a graph in AsciiDoc, not sure I'll be able to, by I'll 
> >> try.
> >> Actually it's only a matter of following what should be in the example 
> >> component, see last OFBIZ-10307-test from example.patch.
> >> I thought it would be enough for devs. I understand it's not, a bit of 
> >> clear documentation is always welcomed, and I often advocate for it.
> >>
> >>> - Finally, I'm not sure this feature is needed at all. Why not just

Re: Should we keep the multi-tenants feature in OFBiz?

[Taher Alkhateeb]

Multi-tenancy complicates things, and the code could be made simpler
by removing it in many areas of the system. So technically, I'm for
that.

However, the issue here is whether enough people depend on it. I saw
multiple questions in the mailing list in the past about multi-tenancy
in the past, so I'm just not sure if people depend on it or not. Maybe
shooting that question in the user ML would help shed some perspective
on it?

With our appreciation for all the good work people are doing in their
projects, I think we should be focused on OFBiz and what is best for
_this_ project. If some project decides to drop multi-tenancy I don't
think we should be influenced or automatically follow suit. So naming
who-did-what might not important for this discussion and we need to
bake our own bread.
On Wed, Aug 29, 2018 at 12:45 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
> hundreds tenants, after it begin to be a lot of DBs!
> I faced that with a startup which wanted to handle thousands, if not millions 
> (actually they failed), of tenants, obviously OFBiz can't do that.
>
> I don't break any secret to say that I was working with David (and Andrew) on 
> a project in 2010 when David had to quickly answer to the client's
> demand who wanted to have tenants. David brilliantly and quickly delivered, 
> but it was only a start.
>
> After many improvements, this feature still have some issues
>  https://issues.apache.org/jira/browse/OFBIZ-6066
>  https://issues.apache.org/jira/browse/OFBIZ-7900
>  https://issues.apache.org/jira/browse/OFBIZ-6164
>  https://issues.apache.org/jira/browse/OFBIZ-6065
>
> Also this is somehow related
>  https://issues.apache.org/jira/browse/OFBIZ-6712
>
> And most importantly
>  https://issues.apache.org/jira/browse/OFBIZ-7112
>  https://issues.apache.org/jira/browse/OFBIZ-7754
>
> I recently read this article
>
> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
>
> and, after my experiences with multi-tenant as is in OFBiz, it made me wonder 
> if we should not think about how it's done now in OFBiz in 2018 with the
> clouds being everywhere!
>
> Before sending this email, I quickly exchanged with David about how Moqui 
> handles that now. And we are on the same page, see
>
> https://www.linkedin.com/groups/4640689/4640689-6180851287941201924
>
> https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
>  [1]
>
> [1] Initially David gave me this link
>
> https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/
>
> but it seems LinkedIn has lost it, as said in the stackoverflow comment.
>
> So IMO why not deprecating the multi-tenants as is now and rather push a 
> multi-instances way?
>
> Opinions?
>
> Jacques
>

Re: Policy on commit

[Jacques Le Roux]

oOps, I missed to finish a sentence... amended inline...


Le 27/08/2018 à 10:15, Jacques Le Roux a écrit :

Hi Michael, All,

First, thank you Michael for your effort in trying to clarify what to discuss in dev ML (this has already been , when to revert a commit, and I'll 
add relations with Jiras status.

(this has already been discussed and agreed in the past)


I know it's important for you to correctly deliver the information about OFBiz 
activity in the monthly blog post

My goal here is to decide if we should write best practices for that in 
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices



And if yes, to clearly write them. This to avoid future confusion and conflicts 
in the community about these subjects.

Before beginning on that, I have already collected some information, I'd like to be sure we all agree about doing so. Then, if we agree we can begin 
to discuss what to write...


Thanks for your attention

Jacques


Le 19/08/2018 à 11:28, Michael Brohl a écrit :

I have not the time to dig into the specific details right now so will just 
give my thoughts on the process in general because of the citations:

1. we have to distinguish between (a) completely new functionality or major refactorings and (b) the enhancement of functionality which is already 
in the code base


2. for (a), we should first have consenus that we want the proposed solution and we should look for a complete, well designed and carefully tested 
solution before the first commit will be done. This is to prevent the introduction of new problematic code.


3. for (b), I think every improvement of existing code/functionality helps and should be committed if there are no flaws in the design or technical 
solution and it does not break existing funtionality. of course, it should be complete within the *scope* of the improvement.


4. if the solution for (b) does not cover other wishes or things which could be enhanced also, this would be no reason to not commit the 
improvement. If people have further requirements, they can provide concepts and solutions/patches anytime to make things better.


In this case, for me it is important if Suraj's commit

a. breaks anything?

b. is vetoed by other committers in view of code quality or design flaws?

If none of these questions get a "yes", then I see no reason to revert.

If you have additional requirements, you are encouraged to provide solutions or 
concepts for them.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Should we keep the multi-tenants feature in OFBiz?

[Jacques Le Roux]

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not millions 
(actually they failed), of tenants, obviously OFBiz can't do that.

I don't break any secret to say that I was working with David (and Andrew) on a project in 2010 when David had to quickly answer to the client's 
demand who wanted to have tenants. David brilliantly and quickly delivered, but it was only a start.


After many improvements, this feature still have some issues
    https://issues.apache.org/jira/browse/OFBIZ-6066
    https://issues.apache.org/jira/browse/OFBIZ-7900
    https://issues.apache.org/jira/browse/OFBIZ-6164
    https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
    https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
    https://issues.apache.org/jira/browse/OFBIZ-7112
    https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article

https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/

and, after my experiences with multi-tenant as is in OFBiz, it made me wonder if we should not think about how it's done now in OFBiz in 2018 with the 
clouds being everywhere!


Before sending this email, I quickly exchanged with David about how Moqui 
handles that now. And we are on the same page, see

https://www.linkedin.com/groups/4640689/4640689-6180851287941201924

https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
 [1]

[1] Initially David gave me this link

https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/

but it seems LinkedIn has lost it, as said in the stackoverflow comment.

So IMO why not deprecating the multi-tenants as is now and rather push a 
multi-instances way?

Opinions?

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Jacques Le Roux]

Hi Taher,

Before creating the last patch, I have reviewed the code a last time again,  it's totally OK now. Did you test from 
https://localhost:8443/catalog/control/FindCatalog with the provided test patch?


I'll now provide a simple and concise AsciiDoc documentation. Maybe with a 
graph, but that's not sure, I have to try...

For the test part I'll wait for the user ML "OFBiz Sanity Test Automation" thread https://markmail.org/message/nxoyqxn7lqfupf55 to conclude before 
endeavouring in web tests


I don't think it should stop to commit this work, which can be tested manually using the provided patches (though the one from example needs the 
commit to be done)


Anyway I'll wait more feedbacks before committing, I'm not in a hurry and I 
know it's a sensitive feature.

Jacques


Le 27/08/2018 à 14:55, Taher Alkhateeb a écrit :

I already found problems in this code to give me pause and to show
that it is not properly studied and designed. If you want to continue
the effort, then I recommend reviewing your code thoroughly, providing
a clear testing mechanism (especially the web scripts), and ask for
reviews and tests.
On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
 wrote:

Hi Taher,

Thanks for your review, much appreciated.


Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :

I reviewed the code and explanation in the beginning of this thread
and I have the following comments:

- First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
you are still returning "success". Does not make sense at all.

You are right I should have used "error".
I did not notice (actually forgot a last own review after much variations in 
code) because it's an event preprocessor and no response is
expected/handled.
Not to bad, in case of error just an EventHandlerException was not thrown.


- Also the comments are unnecessary and do not make sense in the same code block

You mean "// Something unexpected happened here", or ?


- The comment you wrote: "Check it's the right tenant in case username
and password are the same in different tenants. Not sure this is
really useful in the case of external server, does not hurt anyway" is
self-defeating. Never put in code you won't use. We have enough mess
in the code base.

I must say I initially copied that from 
ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the context. 
It's roughly the same code.
I let it there because I was then unsure. But when you think about it, there is 
no reason to not make this check. So I'll simply remove the comment. I
should have put a TODO.

BTW this is out of subject and I'll start a new thread about it after reading
https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
The subject will be: "Should we keep the multi-tenants feature in OFBiz."
I though think the tenants in OFBiz are still useful when you only needs dozens 
or maybe even few hundreds tenants (begin to be a lot of DBs!).
But I faced that with a startup which wanted to handle thousands, if not 
millions (actually they failed), of tenants, obviously OFBiz can't do that.


- Calling LoginWorker.doBasicLogin(userLogin, request) after the
if/else block does not make sense. The else block guarantees falling
into the exception. This whole code block needs refactoring

You are totally right, I have uploaded a new patch where I put the call of
  LoginWorker.doBasicLogin(userLogin, request);
in the positive part of the if and used the same block pattern than above where 
there is a warning log then returning an error.
I was so focused on the other parts of the mechanism, especially to secure it, 
than I forgot to review the Java part.
My bad, thank you again for your review.


- A testing method needs to be provided in detail. For example I'm not
sure how the Javascript portions will execute and when. So some
provision of a clear testing mechanism is necessary.

Yep, right, I'll document all the mechanism and how to use it. Pierre even 
proposed to make a graph in AsciiDoc, not sure I'll be able to, by I'll try.
Actually it's only a matter of following what should be in the example 
component, see last OFBIZ-10307-test from example.patch.
I thought it would be enough for devs. I understand it's not, a bit of clear 
documentation is always welcomed, and I often advocate for it.


- Finally, I'm not sure this feature is needed at all. Why not just
assign an LDAP server to take care of OFBiz and non-OFBiz in a single
sign-on environment.

Because you don't need to have (install, maintain, etc.) a LDAP server, or 
whatnot (CAS, Oauth2, SAML, you name it) if you use this code, it's ready OOTB.


   I see too much code being written for something
that might not be of great value and there are other better solutions
out there.

Which ones do you think about? And why they are better at doing this specific 
feature?


Using JWT tokens might come with problems [1] that need to
be justified before we adopt it.

That's very interesting, 

Re: [Proposal] Enhance the controller logic to accommodate HTTP methods and prepare for REST

[deepak nigam]

Hi Shi,

Verified the fix by Mathieu on the local machine, the system is working
fine now.

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

On Wed, Aug 29, 2018 at 11:01 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Taher,
>
> Thank you for summarizing. I agree with this proposal
>
> After I have applied Mathieu's last OFBIZ-10438 at r1839451, I think we
> are ready to continue this work
>
> Jacques
>
> Le 09/08/2018 à 17:31, Taher Alkhateeb a écrit :
> > Hello Everyone,
> >
> > We want to make this formal with proper community consensus and I will
> > try to keep this short.
> >
> > In [1] Mathieu Lirzin is providing some (in my opinion) good work on
> > converting the Control Servlet logic to be able to handle the
> > different HTTP methods (GET, POST, etc ...) The purpose of the work in
> > this JIRA is simple. You should be able to call a request with a
> > different HTTP methods by using a format like  > method="post">. You can find a more detailed discussion in [2]. This
> > is the first step of a multi-step process to be able to integrate REST
> > API with OFBiz.
> >
> > So, this is a proposal to apply the following:
> > 1- Enhance the controller to be able to accommodate one-or-more HTTP
> > methods (method="GET,POST")
> > 2- Enhance the controller to further be able to get "patterns" that
> > can be mapped to REST APIs. So a request like
> > https://host/control/request/customer/orders/1/orderName can be
> > processed as a resource
> >
> > Please correct me if I was wrong on anything written here Mathieu, and
> > please everyone provide your feedback if you approve of moving forward
> > with this initiative.
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-10438
> > [2] https://s.apache.org/ec2r
> >
>
>