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. 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".
> 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).
> 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.
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