Great proposal, I had quite some headaches with this 2-3 years ago when I was diving deep into the multitenancy with several (mini) shops and content sites for different tenants.. ContextFilter handles it well, but the others don't for the reasons you mention. I was hesitating to propose anything because I did not feel safe enough with my .. .well ... workarounds. They were likely not generic and robust enough under different circumstances (more traffic, concurrent traffic to different sites).
Good to have a documented guideline now. Thanks & regards Carsten 2016-09-09 10:07 GMT+02:00 Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com>: > A web application, in order to leverage the OFBiz framework, requires that > a series of objects are in its contexts (servlet context, session and > request) such as "delegator", "delegatorName", "dispatcher", "security" > etc. etc... > This setup is performed by the logic contained in the servlet filter > implemented by the following class: > > org.apache.ofbiz.webapp.control.ContextFilter > > The execution of this logic is required for the application to run > properly. > However, this filter is deployed in most but not all the web application in > the OFBiz codebase: there are few exceptions due to the fact that a few web > applications require the execution of other filters (e.g. CatalogUrlFilter, > etc...). > > Unfortunately the way these filters have been implemented have issues > including: > * some of them extend the ContextFilter and override its behavior by > copying some logic and adding new one; in these cases the ContextFilter is > also deployed but after the execution of the extended filter > * some of them have been copied from ContextFilter and then adapted, > introducing a lot of redundant code difficult to maintain; in these cases > the ContextFilter is not deployed > > There is now a chance for the community to help cleaning up these classes > and I am proposing the following guidelines: > > 1) servlet filters should be chained (rather than extended or replaced) > 2) ContextFilter should always be used and should always be the first > (OFBiz) filter in the chain > 3) if some of the behavior/logic of ContextFilter conflicts with the ones > of other filters, then ContextFilter should be enhanced to prevent that > (e.g. we can improve the code, move some of its logic in a separate filter > that can be executed after etc...) > 4) the other filters should work well after the ContextFilter and add > behavior rather than overriding behavior or duplicating behavior > > As a beneficial side effect of this effort, we will get a cleaner picture > (documented by the logic of ContextFilter) of all the context objects > required by OFBiz web applications. > > I hope it helps > > Jacopo >
