All,
Just wondering - can we complement this with a method along the lines of
"isPayloadType(Class<?> clazz)" that returns true if the underlying payload
can be cast to the given class, false if it cannot be (or if it's a stream
message?)
I know in my applications today I have up to three if blocks depending on
the message implementation used, and would need this logic to check before
processing. It may also be cleaner than catching the exception.
John
On Mon, Oct 22, 2012 at 12:44 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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
>
>
>