[ 
https://issues.apache.org/jira/browse/QPID-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404204#comment-15404204
 ] 

Rob Godfrey commented on QPID-7318:
-----------------------------------

h4. Patch 8
{quote}
 * I think I am missing the point of {{AbstractConfiguredObjectProxy}}. I 
cannot find is being used (extended, implemented, or mocked) anywhere. So how 
would any of the {{if (source instanceof AbstractConfiguredObjectProxy)}} 
checks ever trigger?
{quote}
I started off going this way to cope with some of the unit tests that mock 
configured objects and use them in the hierarchy, then worked out that I could 
avoid having to use this mechanism for the changes I needed.  I decided to 
leave the code in since it does no harm, and there's a significant non-zero 
possibility we will need it later.

{quote}
 * {{FixedKeyMap#get}} and {{#containsKey}} have O(n ) time complexity which 
certainly breaks my expectation of a Map implementation. I see that they are 
only used for very small maps so it probabaly does not matter but still 
surprising.
{quote}
where n <= 3 I think it's actually going to be quicker (or at least no slower) 
to iterate over a list than to calculate the hashcode, find the correct bucket 
then iterate over the list - especially considering the advantages in not 
having to create so many objects when the Map object is created/populated.  
Obviously you wouldn't want to use this for larger maps.
{quote}
 * {{FixedKeyMap$EntrySetIterator#next}} has a bug in the assignment of the 
value.
{quote}
Fixed

> [Java Broker] Refactor existing ACL plugin code
> -----------------------------------------------
>
>                 Key: QPID-7318
>                 URL: https://issues.apache.org/jira/browse/QPID-7318
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Rob Godfrey
>            Assignee: Rob Godfrey
>             Fix For: qpid-java-6.1
>
>
> While the aim is to redesign the ACL implementation in the v6.2 or v7.0 
> timeframe, there is still utility in tidying up the existing ACL 
> implementation a bit.  In particular by separating out functions and 
> providing a better encapsulation, we will make the job of writing automated 
> upgraders to any new ACL implementation substantially easier.
> As a first step we can separate out the parsing of the ACL file, from the 
> "rule based" implementation of ACLs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to