Nigel,
My preference would be to delegate the ideas of how many and scoping to
simply refer to the CDI specifications, noting that the injected messaging
context is @Dependent or @RequestScoped (not sure which was agreed to, if
any?)
John
On Tue, Feb 28, 2012 at 1:47 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> Returning to this thread...
>
>
> On 20/02/2012 18:15, Rüdiger zu Dohna wrote:
>
>> On 2012-02-20, at 14:45, Nigel Deakin wrote:
>>
>>> * Injecting a MessagingContext ------------------------------
>>>>>>
>>>>> But we don't have to specify that there has to be some underlying
>>>> MessagingContext, do we?
>>>>
>>>
>>> We have to say *something* because we don't want the application to
>>> think that the instance variable holding the
>>> MessagingContext will correspond to the same session for the entire life
>>> of the owning bean (because that would
>>> have implications for message ordering). I'm still looking for the right
>>> form of words here and am open to
>>> suggestions.
>>>
>>
>> IMHO, if message ordering was only defined within one transaction, that
>> would be good enough. This is the 99,99% use
>> case in EE and a useful simplification in SE, isn't it?
>>
>
> Just to step back a little, I'm still trying to think of what the spec
> needs to say about how injected MessagingContext objects are managed.
>
> I think there are two separate but related concepts:
>
> 1. The lifetime of the MessagingContext that is injected at a given
> injection point.
>
> 2. Whether multiple injection points will get the same or different
> MessagingContext objects.
>
> I'll explore these in turn:
>
> 1. The lifetime of the MessagingContext that is injected at a given
> injection point.
> ------------------------------**------------------------------**
> ------------------------
>
> If I have, say, a stateful session bean with an injected MessagingContext:
>
>
> @Inject MessagingContext context;
>
> public void doSomething(payload){
> context.send(payload);
> }
>
> When an application makes two calls to doSomething(), the application
> needs to know whether the two calls are guaranteed to use the same
> MessagingContext or whether they might use different MessagingContexts.
> Only when they use the same MessagingContext does JMS guarantee that the
> messages will be delivered in order.
>
> I don't think it is reasonable to require the container to provide the
> same MessagingContext every time for the whole lifetime of the application.
> However I do think it would be reasonable for the container to provide the
> same MessagingContext for the duration of the request, or the duration of
> the transaction, whichever of the two is longer.
>
> We could leave it up to the container to decide whether it wants to keep
> the same MessagingContext for longer than that, though a well-designed
> container would silently close the MessagingContext when it was not being
> used and create a new MessagingContext when needed.
>
> 2. Whether multiple injection points will get the same or different
> MessagingContext objects.
> ------------------------------**------------------------------**
> ------------------------------**---
>
> This is about whether two different @Inject statements, perhaps in
> different beans, should return the same MessagingContext object.
>
> Consider one bean that calls another:
>
> @Stateless
> public class Bean1{
>
> @Resource(lookup="jms/**inboundQueue") Queue inboundQueue;
> @Inject MessagingContext context;
> @EJB Bean1 bean2;
>
> public void doSomething(String payload){
> context.send(inboundQueue,**payload);
> bean2.doSomethingElse("**Finished");
> }
> }
>
> @Stateless
> public class Bean2{
>
> @Resource(lookup="jms/**inboundQueue") Queue inboundQueue;
> @Inject MessagingContext context;
>
> public void doSomethingElse(String payload){
> context.send(inboundQueue,**payload);
> }
> }
>
> The question is: are the injected MessagingContext objects actually the
> same?
>
> My proposal in the draft specification stated that they would not be the
> same.
>
> However I have had second thoughts, and I think it would be valuable if
> the spec specified that if the two objects were being used in the same
> request, or the same transaction, whichever is longer, and the @Inject
> statements specified the same connection factory and other annotations,
> then the two objects would be the same.
>
> 3. What the spec could say
> --------------------------
>
> In the JMS 2.0 Early Draft I proposed (section 11.3 "Injection of
> MessagingContext objects") that:
>
> -----
> "Applications may declare a field of type javax.jms.MessagingContext and
> annotate it with the javax.inject.Inject annotation:
>
> "@Inject private MessagingContext context;
>
> "The container will inject a MessagingContext. It will have request scope
> and will be automatically closed when the request ends. However, unlike a
> normal CDI request-scoped object, a separate MessagingContext instance will
> be injected for every injection point."
> -----
>
> I'd like to propose an alternative wording as follows:
>
> -----
> "Applications may declare a field of type javax.jms.MessagingContext and
> annotate it with the javax.inject.Inject annotation:
>
> "@Inject private MessagingContext context;
>
> "The container will inject a container-managed MessagingContext whose
> lifetime will be managed by the container and which is scoped to a single
> transaction or a request, whichever is longer. An injected MessagingContext
> with a given set of annotations will be propagated by the container to
> other injection points with the same annotations in the same transaction or
> request, whichever is longer.
> -----
>
> (I've stolen some of this terminology from the JPA spec)
>
> This implies a scope which is "transaction or request, whichever is
> longer". I'm unsure of whether this is quite right (and I don't know how to
> implement it yet): I would have simply mentioned a scope of just
> "transaction", except that this needs to work when there is no transaction
> as well.
>
> Nigel
>
>