[ 
https://issues.apache.org/jira/browse/SLING-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-2774.
-------------------------------------
    Resolution: Won't Fix

> Bad initialisation of a cache in SlingPostServlet
> -------------------------------------------------
>
>                 Key: SLING-2774
>                 URL: https://issues.apache.org/jira/browse/SLING-2774
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Servlets Post 2.2.0
>            Reporter: Lukas Eder
>            Priority: Minor
>         Attachments: SlingPostServlet.java.patch
>
>
> This issue is intended to track the problems mentioned in this thread from 
> the developer list:
> http://www.mail-archive.com/[email protected]/msg18940.html
> An extract of the original mail:
> --------------------------------------------------------
> I've been stepping through the SlingPostServlet, having a look at its
> code. I feel that there is a potential "code smell" in some of its
> methods. As I'm unsure how the Sling project deals with such
> situations, I felt that posting a mail here before creating an issue
> might be better.
> The code I'm talking about is contained in
> registerPostResponseCreator(), where the cachedPostResponseCreators
> attribute is initialised. There are two issues here:
> 1. The cachedPostResponseCreators array is re-initialised every time
> this method is invoked. This leads to an unnecessary O(n^2)
> initialisation complexity on componentContext.locateService() method.
> I guess that this cache's whole purpose is to avoid expensive
> locateService() calls, so this should probably be fixed.
> 2. A first loop initialises this cachedPostResponseCreators array. In
> a second step, "null" entries are "removed" by copying the array. This
> behaviour is hard to read from the existing code, which is a bit
> verbose. In order to avoid the potential for bugs, I'd like to suggest
> using the (untested) behaviour from the attached patch. Note that
> other methods, such as registerPostProcessor(),
> registerNodeNameGenerator() suffers from similar "verbosity problems".
> --------------------------------------------------------
> Also, attached the .patch file that was blocked in the mail on the mailing 
> list



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to