Rüdiger,
On 10/04/2012 08:21, Rüdiger zu Dohna wrote:
> Nigel,
>
> On 2012-04-05, at 17:40, Nigel Deakin wrote:
>> /Question 1: should the injection of JMSContext be tied to CDI or should we simply define the injection behaviour we
>> require? A=Yes, B=No/
>
> A - I don't have a very strong opinion here, but I'd prefer to limit the number of scope rules and concepts a
> developer would have to learn.
>>
>> /Question 2: should there be (A) a separate instance for each injection point , or (B) normal CDI sharing (according
>> to scope) used?/
>>
> A - I strongly think it would be extremely confusing to developers to have different beans change the behavior of each
> other.
I don't see why. This is exactly what happens now if you inject an object which has a normal scope such as "request" or
"application".
> An alternative may be to keep the 1.1 producer objects to have a container for those properties. But a client that
> only sends messages would then want to have only those injected, so an analogous question would still remain: Are they
> dependent scope and still share the same connection/session? I think so, and this would additionally provide us with a
> nice place to add annotations for the producer properties!
>
>> /Question 3: even if the session and connection are shared, should the producer properties listed above still have
>> dependent scope? (A=yes, B=no)/
>
> A - I think this is actually just a question of implementation, but "dependent scope with a request scoped
> session/connection" is easier to explain than "request scope but some properties are not shared".
To give a concrete example of the issues here: if we have two beans, one which calls the other (so they're in the same
request), and each of which uses the following code to send a message. if
*Bean 1*:
@Inject
@JMSConnectionFactory(lookup="jms/connectionFactory")
JMSContext context;
@Resource(lookup="jms/inboundQueue") Queue inboundQueue;
public void foo(){
context.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
context.send(inboundQueue,"Message 1");
bean2.bar();
}
*Bean 2:*
@Inject
@JMSConnectionFactory(lookup="jms/connectionFactory")
JMSContext context;
@Resource(lookup="jms/inboundQueue") Queue inboundQueue;
public void bar(){
context.send(inboundQueue,"Message 2");
}
As I see it, both JMSContext objects are in the same scope so the underlying JMSContext is shared. This means that
setting deliveryMode in one bean affects the deliveryMode of the other. So in bean 2, message 2 is non-persistent (and
is guaranteed to be delivered after message 1)
I agree that for those who haven't encountered dependency injection before this might seem odd, but isn't this just what
scoping is all about?
I checked what happens in JPA (by asking Linda, the spec lead). If you have two beans, used within the same JTA
transaction, each of which injects an EntityManager using
@PersistenceContext
EntityManager em;
Then if you call em.setProperty(name,value) on one injected EntityManager, it affects all injected EntityManager objects
within the same transaction.
>
>> /Question 4: Should the scope of the injected JMSContext be (A) request or (B) extended to cover any transaction as
>> well?/
>
> B - would be something a user might expect, but we have an in-house policy not to depend on message ordering but to do
> a full request-reply before the next message is sent. This is mainly because of the poison message handling in place.
> So I don't have a very strong opinion here.
>
> Maybe we should leave this extended scope message ordering optional for 2.0, so the user can't rely on it to be
> portable. If CDI defines transaction scope, we could standardize on this in 2.1 (if this comes too late for 2.0).
So we would mandate request scope, and leave any other scope for 2.1?
>
>> /Question 5: Do you prefer (A) multiple small annotations, similar to qualifiers (@JMSConnectionFactory,
>> @JMSPasswordCredential, @JMSSessionMode and @SessionMode) or (B) a single annotation with many attributes
>> (@JMSContextConfiguration)/
>
> A - looks nicer to me, but I again don't have a strong opinion about this.
Thanks,
Nigel
>
> I assume that you say that these are just *similar* to qualifiers because CDI might not be required, and talking about
> qualifiers outside of CDI isn't defined exactly.
>
>
> Rüdiger
>