[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages

[John D. Ament]

On Wed, Aug 26, 2015 at 7:33 AM arjan tijms <arjan.tijms at gmail.com> wrote:

> On Wed, Aug 26, 2015 at 1:10 PM, John D. Ament <john.d.ament at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/b7700702/attachment.html