[
https://issues.jboss.org/browse/CDI-219?page=com.atlassian.jira.plugin.sy...
]
Guido Bonazza commented on CDI-219:
-----------------------------------
I actually don't have strong arguments for @PreDestroy, the main one is symmetry,
which is not completely fool since it's common to use the same resources in
@PreDestroy as in @PostConstruct.
Joe, I'm afraid I don't understand 2), (and I coudn't find Martin's
comment): my suggestion is that in @Singleton @PostConstruct (and eventually @PreDestroy)
the current RequestContext, if any, is "suspended" and "resumed" upon
exit of the callback. Does this contradict 6.3? This would be coherent with transactional
behaviour; otherwise we end up with a new transaction opened on the @Singleton
@PostConstruct invocation, suspending the current one, all within the same RequestContext
which could lead to weird side effects I think.
Support Request Scope for EJB @Singleton @PostConstruct methods
---------------------------------------------------------------
Key: CDI-219
URL:
https://issues.jboss.org/browse/CDI-219
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts, Java EE integration
Affects Versions: 1.0
Reporter: Guido Bonazza
Assignee: Joe Bergmark
Fix For: 1.1.PRD
A Request context should be available in @PostConstruct methods of EJB Singletons.
This is a completion of section 6.7.1 of the CDI 1.0 spec, which covers @Asynchronous and
@Timeout EJB methods.
Probably the container should ensure that a new context is always created for the
@PostConstruct invocation, to be coherent with section 4.8.3 of the EJB 3.1 spec, which
specifies the transactional behavior of @Singleton @PostConstruct.
--
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