On 22/10/2012 17:26, Chris Barrow wrote:
> Hi Nigel and Pete,
>
> Just want to say I really like the Message.getPayload idea. For MapMessage and StreamMessage, presumably it would just
> throw ClassCastException, since there is no valid class the user could pass in for those message types?
I agree it wouldn't really work for StreamMessage. But MapMessage would be OK: it could just return a Map
I see this method as analogous to the receivePayload methods on JMSConsumer:
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSConsumer.html#receivePayload%28java.lang.Class%29
> Also, perhaps it might be clearer to throw MessageFormatException instead of ClassCastException when the content can't
> be converted to the specified class. That would be consistent with all of typed content accessor methods like
> StreamMessage.readBoolean, MapMessage.getDouble, etc.
I quite like that. If we did this we would want to make the same change to receivePayload on JMSConsumer. Any other views?
Nigel
>
> Chris
> --
> *Chris Barrow
> **Kaazing Corporation*
>
> On 10/22/2012 8:42 AM, Nigel Deakin wrote:
>> 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
>