ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacopo Cappellato <jacopo.cappell...@hotwaxsystems.com>
Subject Re: Ideas about OFBiz servlet filters
Date Fri, 09 Sep 2016 09:21:10 GMT
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 <pierre.smits@gmail.com>
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 <
> jacopo.cappellato@hotwaxsystems.com> 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 <
> > jacopo.cappellato@hotwaxsystems.com> 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message