[cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance

Martin Kouba (JIRA) issues at jboss.org
Thu Sep 17 04:53:00 EDT 2015


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

Martin Kouba commented on CDI-561:
----------------------------------

bq. Being able to capture an instance state to use its information outside CDI or as an event payload...

I think this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically.

> Add the possibility to unmanage a bean instance
> -----------------------------------------------
>
>                 Key: CDI-561
>                 URL: https://issues.jboss.org/browse/CDI-561
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 (discussion)
>
>
> CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful
> * Accessing the true class of the instance in a clean way
> * Being able to capture an instance state to use its information outside CDI or as an event payload
> The limitation we have  on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance.
> We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean.



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


More information about the cdi-dev mailing list