[cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation

[Martin Kouba (JIRA)]

    [ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203570#comment-13203570 ] 

Martin Kouba commented on CDI-594:
----------------------------------

I believe we should mark this issue as duplicate. See also CDI-519.

> Instance#destroy should be linked to Instance instance which has been used for the creation
> -------------------------------------------------------------------------------------------
>
>                 Key: CDI-594
>                 URL: https://issues.jboss.org/browse/CDI-594
>             Project: CDI Specification Issues
>          Issue Type: Epic
>    Affects Versions: 1.2.Final
>            Reporter: Romain Manni-Bucau
>
> We suppose we have an injection of type Instance<Greeting>.
> {code}
> // adapted from javaee7-samples repo
> 		Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {});
> 		Greeting anotherBean = select.get();
> 		assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> 		select.destroy(anotherBean);
> {code}
> This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work:
> {code}
> 		Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get();
> 		assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> 		instance.destroy(anotherBean);
> {code}
> The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)