[jira] [Updated] (SLING-2774) Bad initialisation of a cache in SlingPostServlet

["Lukas Eder (JIRA)" <ji...@apache.org>]

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

Lukas Eder updated SLING-2774:
------------------------------

    Attachment: SlingPostServlet.java.patch
    
> 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/dev@sling.apache.org/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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira