Pete,
Thank you very much for these comments (sorry it's taken so long for me to reply).
On 10/10/2012 12:01, Pete Muir wrote:
> Nigel et al.
>
> Here is a writeup of the notes I made during Nigel's JavaOne talk on JMS 2.
>
> 1) The word "Context" in the simplified API JMSContext seems redundant to me, and not very consistent with usage in
> other specs. I just wonder if there is a better name for this class (but I don't have one!).
A "JMSContext" represents a single-threaded handle on the messaging provider. I chose the word "context" to be vaguely
consistent with the JPA concept of PersistenceContext, though it is actually closer to an EntityManager. What specs
were you thinking that have a inconsistent use of "context"?
The fact that "context" is fairly meaningless was considered a benefit!
I did call it MessagingContext initially but changed to JMSContext for reasons of brevity and also to allow a consistent
trio of interfaces JMSContext, JMSProducer, JMSConsumer.
>
> 2) Some feedback for the CDI community comes from the way that JMS wants a "gracefully degrading scope" such that
> @TransactionScoped is used if a transaction is in progress, otherwise a request scoped is used. I would hope to
> specify this idea in CDI 2.0, hopefully in a way that JMS can then use (as opposed to specifying it directly)
Would this expand the definition of @TransactionScoped to state that it degrades to to be the same as @RequestScoped
when there was no transaction?
How would this relate to whatever the JTA spec lead is planning to say about @TransactionScoped? Should that spec
(rather than CDI) define @TransactionScoped as a gracefully degrading scope?
> 3) Nigel introduced the new simplified method of getting hold of the payload via the receivePayload methods which
> return the payload already cast to the correct type, using generic inference, however highlighted that this didn't
> help if you still wanted to look at the message headers, and that here you still need to receive a Message. I
> suggested adding generic inference to ObjectMessage.getObject for this purpose.
I think this is an excellent idea. I think what this means is we would add a new method to javax.jms.Message which
returned the payload directly. This would have a similar API to the new receivePayload methods on JMSConsumer:
<T> T getPayload(Class<T> c)
This means that instead of something like:
public void onMessage(Message message) {
String payload = ((TextMessage) message).getText();
...
we could have
public void onMessage(Message message) {
String payload2 = message.getPayload(String.class);
...
Although this might still throw a ClassCastException, it avoids the need for an explicit class in the code, which is
fiddly to code (all those brackets) and can cause compiler warnings.
What do others think about this?
>
> 4) JMS 2 code, with CDI, has a lot of:
>
> @Inject @JMSConnectionFactory("foo") JMSContext ctx;
>
> which concerns me for two reasons:
>
> a) DRY - we constantly repeat the @JMSConnectionFactory("foo") in a fashion that the compiler can't verify (easy to
> slip in a typo on foo), and that won't be auto-completed in an IDE.
>
> (a) should be addressed by something like a CDI stereotype, however stereotypes are not currently applied to
> injection points. I'll work with the CDI community + Java EE community on this (this is also an open issue for Java
> EE 7 - generalizing the notion of stereotypes).
Do I need to wait for something to be added to CDI 2.0 before we can update JMS 2.0 to state that the injection point
can include stereotypes?
Does CDI need to do anything extra to make it possible to define a stereotype for @JMSConnectionFactory("foo")?
> (b) that JMSConnectionFactory is actually metadata
> that is used to determine how JMSContext is wired up, and not configuration for the JMSContext
>
> (b) is a situation I've seen a few times with CDI integrations, and perhaps something CDI needs to address better
> itself. I'll work with the CDI community on this.
You refer to the distinction between "how JMSContext is wired up" and "configuring the JMSContext". Is either catered
for in standard CDI currently? As far as I can see neither are: all we have in CDI are qualifiers which are used to
select which particular producer method is used, whereas with JMS we're defining annotations which define how the
(single) producer method generates a JMSContext.
In any case it sounds like there's nothing that JMS can do about this currently.
Nigel