On Wed, Aug 26, 2015 at 1:10 PM, John D. Ament <john.d.ament@gmail.com> wrote:
> The JMS provider would be responsible for retrieving a contextual reference
> to the bean and then invoking the method.
But in that case the contextual reference to the bean would be within
the single request scope that the resource adapter adapter sees.
Likewise, IFF the bridging would be done via an MDB, and the MDB would
retrieve a contextual reference of an @RequestScoped bean, then it
would be the single instance corresponding to the same request the MDB
sees.
What I think is wanted here is that an arbitrary *other* request
that's active, say an HTTP request to a Servlet, has an active
@RequestScoped bean and the resource adapter or MDB invokes a method
on the bean in that other request scope.
Correct me if I'm wrong, but this is not entirely how CDI normally
works, where contextual references always resolve to beans that are in
the scope of the caller.
I think we're saying the same thing. I feel like I had similar discussions with Nigel in JMS 2, and cautioned him to not redefine how CDI works or how request scoped works. By simply saying "this is the active context when you do this" it's covering that request context will continue to be request context. If the CDI E.G. ever redefined how request context works, then those changes should just apply anywhere that request context is used, without requiring the specs to change something.
There is currently no sharing of request contexts. One of the open requests from the servlet spec is to bridge request on async submissions. They should be able to specify that themselves, but meh. LIkewise, there is no guarantee that the MDB that the message gets delivered to shares any topology with the client that produced the message, so attempting to state that the http request is shared makes very little sense. If there are attributes that want to be shared, that's fine, but those can be sent with the message itself.
John