As a proof of my srtatement yesterday I have now put the 'evil' line back into
ContextFilter that overwrites ServletContext with the delegator AND IT WORKS.
In order to cope with this on Logout, I have changed the
LoginWorker.doBasicLogout to re-initialize a Delegator object using the
Servlet's initParameter delegatorName.
This cannot be called better than a workarounbd for the fact that the
backoffice apps are not ready for Multitenant use, at least not for robust,
concurrent access to these apps by several tenants.
Also, I did a search for 'getAttribute("delegator")' in java files, but all I
can see are accesses to the HttpRequest.
So my call for help remains: can anyone point me to the basic delegator
retrieval mechanism that backoffice apps use? They seem to be reading
servletcontext regardless
Thanks + regatds
Carsten
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-----Original Message-----
From: Carsten Schinzer <[email protected]>
Date: Thu, 17 Jan 2013 08:23:46
To: <[email protected]>
Subject: Re: [jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment
not working correctly
All,
I really need help on this -- I know multitenant is not very popular in
use. Yet, if someone could find time to look at this, would be a great help!
I have modified ContextFilter and LoginWorker now as follows in my local
environment:
LoginWorker:
- identifies the correct tenant delegator and places it in Session Context
ContextFilter:
- assure the tenant delegator is in SessionContext and places it in the
HttpRequest
- does no longer overwrite the ServletContext delegator with the
tenantDelegator (this is bad practice IMHO)
Since this change the logins work perfectly fine however the data I am
seeing in backoffice applications are not the tenant data but the data on
the main ofbiz instance.
So the backoffice application pages seem to be always using the delegator
in the ServletContext and not the Visit's or the HttpRequest's or the
SessionContext's.
Can someone confirm this statement and please point me where in the
framework I would change that behaviour?
IMHO the current, official implementation on the trunk which overwrites the
ServletContext parameter is bad practice and moreover is not robust enough
to support concurrent use of apps by different tenants.
Thanks for your support!
Regards
Carsten
