[cdi-dev] [JBoss JIRA] (CDI-317) review PassivationCapable interface
Mark Struberg (JIRA)
jira-events at lists.jboss.org
Mon Jan 14 04:15:22 EST 2013
[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745556#comment-12745556 ]
Mark Struberg commented on CDI-317:
A producer method is passivation capable if and only if it never returns a value which is not passivation capable at runtime.
A custom implementation of Bean is passivation capable if it implements the interface PassivationCapable.
So, how does a Bean tells the container: "most of my implementations are passivation capable, but sadly some are not? There is no such thing like dynamically adding an interface. At least not with compiled classes.
You would need to add 2 Bean classes for the same logic. In OWB we allow getId() to return null which indicates that this very bean is not passivation capable.
> review PassivationCapable interface
> Key: CDI-317
> URL: https://issues.jboss.org/browse/CDI-317
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
> Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface.
> But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not.
> Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation.
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
More information about the cdi-dev