JMS 3.0 [proposal] @MessageConverter Annotation and interface

@dblevins I'm not sure if this is the correct place to raise an idea, please let me know. This is related to #243

After reading through the spec, one thing I think is missing is the concept of message body converters. JAX-RS has the ability to allow people to create JSON, XML, FormURLEconding, YAML, etc representations and automatically convert them to Java objects before the developer's code is called.

Why is this important?

Interaction with third party systems! For instance, if you're communicating with a ruby or python program at the other end of your message broker, you're definitely not going to be using Java serialization.

Another very important reason is viewing of messages on the Message Broker itself. Most message broker consoles allow you to peer into the contents of a message. Having first class support for encoding Java objects as JSON, XML, or whatever allows a developer to have them in a human readable format, more aligned with RESTful principles.

I would propose a @MessageConverter annotation that takes a class argument (works well for non-CDI environments). A CDI-ish way to bind a bean as a converter would also be nice so we can support injection on Converters.

@Destination("event.queue")
@DestinationType(Queue.class)
@MessageType(TextMessage.class)
@MessageConverter(type = MessageDirection.Ingress, class=JsonConverter.class)
public void recvEvent(MyEvent myEvent){
}

public interface JmsMessageConverter<T extends Message> {
	<K> K convert(T message, Class<K> targetClass);
}

public class JsonMessageConverter implements JmsMessageConverter<TextMessage> {
	@Override
	public <K> K convert(TextMessage message, Class<K> targetClass) {
		// TODO magic, convert textMessage containing json to Java object
		K myEvent = ....from json
		return  myEvent;
	}
}

Start by reading the JMS 3.0 specification and related issue #243, then review the proposed @MessageConverter annotation and JmsMessageConverter interface in the issue. Identify the API, CDI binding, and message-direction decisions that require agreement. Done means the proposal has an agreed scope and API design before implementation begins.