[ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin... ] Peter Royle updated SEAMCRON-6: ------------------------------- Summary: Can we use @RequestScoped for @Scheduled and @Asynchronous methods? How? (was: Can we use @RequestScoped for @Asynchronous methods? How?) Description: This is one for investigation some time. It came up in this IRC chat: The weld reference document (page 34) states: The request and application scopes are also active: • during invocations of EJB remote methods, • during invocations of EJB asynchronous methods, • during EJB timeouts, • during message delivery to a message-driven bean, • during message delivery to a MessageListener, and • during web service invocations. So we should be able to support this, even if only for certain providers (ie: EJB) IRC Transcript: [11:10am] johnament: request scoped won't be active in a background thread. [11:10am] PeteRoyle: ah true cos it's threadlocal? [11:10am] johnament: which? [11:11am] PeteRoyle: request scoped implementation [11:11am] PeteRoyle: won't work in a background thread because the implementation of request scope uses threadlocal, is that right? [11:11am] johnament: its essentially an HTTP request [11:12am] PeteRoyle: right [11:12am] PeteRoyle: I think the use case is valid though, do you agree? [11:13am] johnament: its valid, but it breaks the CDI model, so to say [11:13am] johnament: because you want to make your contextual objects available outside of your context [11:14am] PeteRoyle: right yeah that makes sense [11:14am] PeteRoyle: the request might be over [11:14am] johnament: the only thing really available is going to be dependent or application scoped [11:15am] johnament: the bigger question - which request? [11:15am] PeteRoyle: well the one from which the @Asynch method was called - assuming we could hang onto it [11:15am] PeteRoyle: hang onto the request that is [11:16am] PeteRoyle: eg: a controller which @Injects a @RequestScoped Thing, then calls an @Asynchronous method [11:17am] johnament: the only way it would work is to make request scope extend through your @asynch process is over. [11:18am] PeteRoyle: The interceptor would have access to the correct @RequestScope. It would need to replicate it into the new thread. Would that be possible do you think? [11:18am] johnament: i don't know how plausible/possible that even is. [11:18am] PeteRoyle: yeah. I might leave that as something for investigation later. I'll JIRA it [11:18am] johnament: jms does this by transporting the event over JMS, but loses the context. was: This is one for investigation some time. It came up in this IRC chat: IRC Transcript: [11:10am] johnament: request scoped won't be active in a background thread. [11:10am] PeteRoyle: ah true cos it's threadlocal? [11:10am] johnament: which? [11:11am] PeteRoyle: request scoped implementation [11:11am] PeteRoyle: won't work in a background thread because the implementation of request scope uses threadlocal, is that right? [11:11am] johnament: its essentially an HTTP request [11:12am] PeteRoyle: right [11:12am] PeteRoyle: I think the use case is valid though, do you agree? [11:13am] johnament: its valid, but it breaks the CDI model, so to say [11:13am] johnament: because you want to make your contextual objects available outside of your context [11:14am] PeteRoyle: right yeah that makes sense [11:14am] PeteRoyle: the request might be over [11:14am] johnament: the only thing really available is going to be dependent or application scoped [11:15am] johnament: the bigger question - which request? [11:15am] PeteRoyle: well the one from which the @Asynch method was called - assuming we could hang onto it [11:15am] PeteRoyle: hang onto the request that is [11:16am] PeteRoyle: eg: a controller which @Injects a @RequestScoped Thing, then calls an @Asynchronous method [11:17am] johnament: the only way it would work is to make request scope extend through your @asynch process is over. [11:18am] PeteRoyle: The interceptor would have access to the correct @RequestScope. It would need to replicate it into the new thread. Would that be possible do you think? [11:18am] johnament: i don't know how plausible/possible that even is. [11:18am] PeteRoyle: yeah. I might leave that as something for investigation later. I'll JIRA it [11:18am] johnament: jms does this by transporting the event over JMS, but loses the context. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin... ] Stefano Travelli commented on SEAMCRON-6: ----------------------------------------- We was discussing something similar about seam-servlet at http://seamframework.org/Community/WebApplicationStartupEventAndRequestCo... "no session, no conversation" makes perfectly sense for long running conversation, but in some common use cases a temporary conversation could be enough. With the current behaviour we build all our business components (DAO, etc) with the beloved seam managed persistence context only to discover that we cannot reuse them in @Scheduled, @Asynchronous, in Message Driven Bean and at application startup because the entityManager is conversation scoped. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin... ] Martin Kouba commented on SEAMCRON-6: ------------------------------------- I'm not sure about conversation scope, but request scope seems to me legal and pretty useful (in terms of reusing request scoped components) for both @Scheduled and @Asynchronous methods. In Seam Cron quartz impl or custom quartz integration this could be accomplished e.g. with org.quartz.JobListener and org.jboss.weld.context.bound.BoundRequestContext (http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/contexts.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin... ] Heiko Tappe commented on SEAMCRON-6: ------------------------------------ Is there any progress concerning this issue? Or any workaround? All my business logic is based on using session and conversation scoped beans. So I really need some way to make these contexts available in cron jobs. -- 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