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

ASF subversion and git services commented on ARIES-2207:
--------------------------------------------------------

Commit daa69700a5d832037acf507048eff1ad17b50bcc in aries-rsa's branch 
refs/heads/master from Amichai Rothman
[ https://gitbox.apache.org/repos/asf?p=aries-rsa.git;h=daa69700 ]

ARIES-2207 Re-implement ImportRegistrationImpl more simple, clear and compliant


> Import/ExportRegistrationImpl copies use convoluted shared state and don't 
> fully implement api contracts
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-2207
>                 URL: https://issues.apache.org/jira/browse/ARIES-2207
>             Project: Aries
>          Issue Type: Bug
>          Components: Remote Service Admin
>    Affects Versions: rsa-1.16.1
>            Reporter: Amichai Rothman
>            Assignee: Amichai Rothman
>            Priority: Major
>
> Both ImportRegistrations and  ExportRegistrations, according to the spec, 
> should under some circumstances (re-exporting/importing an already 
> exported/imported endpoint) return a new instance of the registration that is 
> linked to (i.e. shares state) with the previously existing one.
> The current implementation is rather convoluted, making it error-prone and 
> difficult to maintain: the impl has all fields (both shared and 
> per-instance), one of them is designated as the 'parent', then at various 
> places there are checks and conditionals deciding whether to use the 
> instance's own fields (if it is the parent) or delegate to the parent.
> A much more straightforward and intuitive approach would be to just have a 
> shared state object containing the shared data, and have all impls reference 
> it with simple and consistent code.
> In addition, the spec and interface javadocs state the contract for the 
> methods of this class, specifically several of them need to either return 
> data, return null, or throw an IllegalStateException, depending on the 
> dynamic state of the registration (invalid, closed, etc.). The current 
> implementation doesn't implement these contracts properly.



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

Reply via email to