[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-223: ----------------------------------- The same should happen for @Asynchronous and @Timer, JMS etc. But there is already a section which states exactly that: 6.7.1 Request Context Lifecycle The request scope is active: ... * during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and ... + The request context is destroyed: ... * after the EJB remote method invocation, asynchronous method invocation, timeout or message delivery completes, or ... This pretty much implies what you wrote. What's imo missing is @Timer. Btw, there is atm a HUGE difference between remote and local EJB invocations! An example: Imagine a @RequestScoped User CDI bean which gets injected into a @Stateless EJB. Your User will _not_ be available for injection on the remote side! But this would perfectly work for a @Stateless bean which is local. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-223: ------------------------------- When you say "Imagine a @RequestScoped User CDI bean which gets injected into a @Stateless EJB. Your User will not be available for injection on the remote side! But this would perfectly work for a @Stateless bean which is local." Yes, you can't inject it using @Inject, but you still can via @EJB, in which case the CDI bean behaves as a "non-contextual instance". I was assuming @EJB injection for this clarification, sorry about that! Re @Timer, isn't that covered by "message-driven bean, >>>timeout<<< or..."? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-223: ------------------------------- Hah, the @ confused me :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-223: ------------------------------- Yes, you would need to make this as a *class* bean, which can be an EJB as well. e.g. {code} @Stateful @RequestScoped public class User { ... private String getId() { ... } } {code} {code} @Stateful public class RemoteBean { @EJB User user; public void doSomething() { String id = user.getId(); } } {code} Is what would work. If you want to make user produced, you'll need some sort delegate or something, which is a really mess. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Fab Mars edited comment on CDI-223 at 4/30/12 9:49 AM: ------------------------------------------------------- @Stateful + @EJB User may turn the use-case into something rigid/theoretical, don't you think? Back to to the example, @Remote can't marry with CDI's jurisdiction boundaries. It's obvious and at the same time I feel there's going to be a lot of questions on user forums. It kind of reminds me of the lazy loading issue on detached JPA entities. Well, so, logically (though it will require careful documenting), the only option is to pass a reference to the content you want to use within your EJB. Either you ask developpers to create an intermediate cdi-free "copy" of User(sounds oldschool to me), or take the road Mark outlined. Unless there are so few Remote-EJB/CDI users that this issue is pointless (for this CDI revision at least), I think we have no choice. was (Author: fabmars): @Stateful + @EJB User may turn the use-case into something rigid/theoretical, don't you think? Back to to the example, @Remote can't marry with CDI's jurisdiction boundaries. It's obvious and at the same time I feel there's going to be a lot of questions on user forums. It kind of reminds me of the lazy loading issue on detached JPA entities. Well, so, logically (though it will require careful documenting), the only option is to pass a reference to the content you want to use within your EJB. Either you ask developpers to create an intermediate cdi-free "copy" of User(sounds oldschool to me), or take the road Mark outlined. Unless there are so few Remote-EJB/CDI users that this issue is pointless, I think we have no choice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-223: ----------------------------------- Maybe we should handle this the same way we need to handle @Asynchronous? To add the explicit boundary saying what parts and mechanisms get their own RequestContext. Or just saying that any CDI Context doesn't get propagated to EJB remote instances. Even if the desired behaviour seems obvious - it is unspecified as long as we don't explicitly define it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-223: -------------------------- Fix Version/s: 1.1 (Proposed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-223: -------------------------- Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-223: -------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PFD) -- 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