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? 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.
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