Hi,
sorry for taking so long to reply... I was on vacation with the family, i.e. offline for two weeks.
Nigels comments on the AtInject proposal seem quite comprehensive and detailled, while the Event Messaging proposal goes quite uncommented, yet, so I'll concentrate on that. CDI event binding is obviously a viable solution and seems to have support in the EG. As I've stated before, I'd prefer to instead bind to a business interface, but I'll leave that discussion to a separate thread. Here are my suggestions to improve the current proposal, in no particular order:
* ObjectMessages seem an obvious choice, but I think that they are not a good default. Asynchronous messages are very different from synchronous calls, also in that there may be intermediate instances that need to read them, namely tools to debug e.g. error queues, or content based routers. With ObjectMessages containing application specific classes, these tools require the proper class files of the message objects being sent. But it's often not feasible to share with them all versions of all message objects; so it seems to me to be a better default to use generic message formats, like xml or mapped messages.
* How are the qualifiers mentioned as Annotation[] in the code examples on page 5 transported from the sender to the receiver?
* I think it's worth to mention that it's a required change to allow MessageListeners in an EE environment.
* Defining all defaults, e.g. the default factory attribute of the JmsConnection annotation, would improve portability, wouldn't it? The spec doesn't have to define the exact value in this case, but the exact semantics should be set, shouldn't it?
* I think that it would be more consistent with the EJB behavior of automatically managing transactions, if the default of the JmsConnection#transacted attribute were true.
* Maybe it would be easier and suffice if "transacted" were not a separate attribute but a fourth acknowledge mode (as I understand it, this is what Nigel suggests in JMS_SPEC-45).
* The JmsCredentials annotation (used literal as well as plain) is not really an improvement over the current security situation of JMS client code. But the only real solution that I can think of may be out of scope, as it's a general EE issue: Every application has some identity and required privileges to e.g. send messages to some queue. The deployer checks this identity and grants it the requested privileges. So the developer only defines what the application needs, while the deployer checks and fulfills these needs.
* Page 4, 2nd client guarantee, 2nd sentence is unclear to me... and what's 3a?
* Page 4 (and later on): The MessageObject type irritates me. Isn't it meant to be the StatusIdMessage used before?
* Page 4, SomeQueueLiteral: If it's a singleton, the constructor should be public... and as it may be serialized it would be better to use a one-value-enum (cf. Effective Java). If it's not a singleton, you'd need equals and hashCode, so it's a proper value object. Don't have to code it but mention it.
* Page 5, 2nd (non-code) sentence (and last code snippet and paragraph on the same page): The property name is not "someProperty" but "eventType", isn't it?
* Page 5, 2nd "contract" bullet point: Do you really suggest that messages that can't be converted for some reason be dropped with only an optional waring in some logs?!?
* Page 5, last paragraph, 2nd to last sentence: I just don't get it. Why is the message selector supposed to be an interceptor? How it it supposed to do the routing, if there are multiple message selectors? How is transactionality related?
* Page 6-8, API Changes: I'd prefer to read (eventually commented) code for all annotations and enumerations.
And I really like the improvement over the 1.1 spec!!!
Rüdiger