Hi Nigel,
Was reviewing javadocs for JMS2.0 specification.
Have several questions/proposals:
*JMSConsumer:*
> A JMSConsumer object is created by passing a Destination object to one of
> the createConsumer or createDurableConsumer methods on a JMSContext.
This is not precise enough I think, cause JMSConsumer could be created by
createSharedConsumer() methods also
and createDurableConsumer/createDurableConsumer methods are required
passing exactly Topic, but not any Destination...
*JMSConsumer#get/setMessageListener():*
> This method must not be used in a Java EE web or EJB application. Doing so
> may cause a JMSRuntimeException to be thrown though this is not guaranteed
I suspect it is because preferred way to use asynchronous delivery in Java
EE container is to use MDBs. Might be worth saying it in javadocs. What do
you think?
*JMSProducer#get/setPriority():*
What's the implications of using getPriority()/setPriority() methods?
Does it mean that messages will be placed in priority order on broker's
message queue?
Or no guarantee and it is up to consumer how to use it?
*JMSProducer#send():*
I noticed that there are number of similar send methods differ only by type
of payload to be send.
Not sure it is not planned yet, but why can't we introduce:
*<T> JMSProducer sendPayload(Destination dest, T payload)*
This will be consistent with new methods for receiving payloads.
*JMSProducer#get/setXXXProperty():*
I noticed that there are number of similar methods differ only by type of
property used.
Why can't we introduce:
*<T> T getProperty(String name, Class<T> type)*
*<T> void setProperty(String name, T value)*
This will be also consistent with new methods for receiving payloads.
*JMSProducer#setAsync():*
> Restrictions on usage in Java EE An asynchronous send is not permitted in
> a Java EE EJB or web container. If the application component violates this
> restriction this method may throw a JMSRuntimeException.
Again might be worth to explain why. What do you think?
*JMSProducer#get/setJMSCorrelationIDAsBytes():*
What is the reason to support byte[] IDs?
Thank you,
Oleg