I prefer to start the discussion in this list and consider to move to Jira only in a second phase if a more structured coordination of tasks will be useful.
Jacopo On Fri, Sep 9, 2016 at 10:25 AM, Pierre Smits <[email protected]> wrote: > I hope the proposal for actionable items will materialise rather sooner > than later in our JIRA. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Fri, Sep 9, 2016 at 10:23 AM, Jacopo Cappellato < > [email protected]> wrote: > > > And here is a proposal for some actionable items to contribute to this > > effort: > > > > 1) review and document the current usage (by application) of filters > > (classes and their order) > > 2) review the logic in the filters and compare it to the one of > > ContextFilter (what is different, what is added, what is duplicated > etc...) > > 3) identify the filters that "extends" the ContextFilter class and figure > > out how to refactor their code to work in a filter chain where the first > > filter is ContextFilter > > > > Jacopo > > > > On Fri, Sep 9, 2016 at 10:07 AM, Jacopo Cappellato < > > [email protected]> wrote: > > > > > 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 > > > > > >
