[seam-issues] [JBoss JIRA] Updated: (SEAMCRON-6) Can we use @RequestScoped for @Scheduled and @Asynchronous methods? How?

[Peter Royle (JIRA)]

     [ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.



> Can we use @RequestScoped for @Scheduled and @Asynchronous methods? How?
> ------------------------------------------------------------------------
>
>                 Key: SEAMCRON-6
>                 URL: https://issues.jboss.org/browse/SEAMCRON-6
>             Project: Seam Cron
>          Issue Type: Task
>            Reporter: Peter Royle
>            Assignee: Peter Royle
>             Fix For: 3.0.0.Alpha2
>
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira