[
https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-317:
-----------------------------------
Read 6.6.1
{quote}
A producer method is passivation capable if and only if it never returns a value which is
not passivation capable at runtime.
{quote}
plus
{quote}
A custom implementation of Bean is passivation capable if it implements the interface
PassivationCapable.
{quote}
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