Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-107575

Misbehavior when ServletFilters with duplicated names are deployed



      ServletFilters have a name that's not namespaced by module. Thus, any name that duplicates one that's already deployed, will clash with the other filter.

      Steps to reproduce:

      Create 2 module projects with a simple OSGi servlet filter with the same servlet-filter-name property (different classnames should be chosen for the two, to separate the log output. Also change the implementation, e.g. the header name), e.g.

         immediate = true,
         property = {
          "before-filter=Auto Login Filter",
          "servlet-filter-name=Sample Servlet Filter",
      public class SampleServletFilter1 extends BaseFilter {
       protected void processFilter(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse,
       FilterChain filterChain) throws Exception {
          _log.error("Sample Filter FILTERING"); // change msg in second filter
          String requestURI = httpServletRequest.getRequestURI();
          httpServletResponse.addHeader("X-Sample-Filter-1", requestURI);
                httpServletRequest, httpServletResponse, filterChain);
        protected Log getLog() {
          return _log;
        private static final Log _log = LogFactoryUtil.getLog(SampleServletFilter1.class);


      Note: change log message and header to indicate the source of the message/header in both deployed servlet filters, but keep them with the same servlet-filter-name.

      Deploy first filter, evaluate that it's message is shown / header applied.

      Deploy second filter, evaluate that only one filter's message/header is applied twice.

      Undeploy one of the filters. Evaluate that neither of the filters will now be applied despite one still being deployed.


      If you add different log outputs during init and destroy for these filters, you'll see that only one filter is ever destroyed, while the other is still dangling, no matter if you undeploy one or both plugins.

       public void init(FilterConfig filterConfig) {
         _log.error("init 1");
       public void destroy() {
         _log.error("destroy 1");

       There's also no warning about deployment of duplicate servlet filter names - the procedure fails silently.

      With the possibility of copying samples with nondescript names, there's a real chance for accidentally deactivating one - on top: The order of deactivation might be random, as it depends on deployment order.

      Hint: InvokerFilterHelper.unregisterFilterMapping() might be part here - first identifying the filter only by name (line 201), then ignoring potential multiple filters (line 207).

      If the current behavior is kept (allow only one filter with a given name), deployment of the second filter with the same name should fail explicitly and with log output, to limit the possible damage and debugging time.




            support-lep@liferay.com SE Support
            olaf.kock Olaf Kock
            Participants of an Issue:
            Recent user:
            Olaf Kock
            0 Vote for this issue
            1 Start watching this issue


              Days since last comment:
              1 year, 45 weeks, 5 days ago


                Version Package