On 01/29/2013 06:32 PM, Fraser Adams wrote:
from a perspective of decoding it's not too hard to write defensive code to be able to handle a reasonable set of variations, that's what I did at in my code where I checked the Content-Type so was able to figure out that the MapMessage that I was getting was really a list.
I feel the library can also help here, that's the idea behind allowing the message to be treated as a variety of different types. Arguably another way you should be able to treat the message is as a BytesMessage in which case you would get the raw encoded bytes and had that been supported your application would have continued to work as before.
On the encoding side that's where it'd be good for the runtime to be able to be tolerant so if I send a BytesMessage with amqp/list it behaves as it did
I agree, that should be the case.
, or a MapMessage with amqp/list it behaves as 0.20 and (hopefully) in the future if I send and ObjectMessage containing a List with a Content-Type of amqp/list then that would work too.
I agree.
I think that exposing the AMQP Content-Type more satisfactorily is very much our friend from the perspective of interoperability.
I agree.
I still assert that ObjectMessage is the only way to expose amqp/map and amqp/list and properly conform to the spec.
I don't think it is or should be the _only_ way. I accept it could be one useful way of doing so. If I send a simple map, receiving it from JMS as a MapMessage seems reasonable. Being able to treat it as some other message type may also be reasonable.
Just because we might want to introduce a constraint that only Maps and Lists (and other types with an AMQP serialisation) are supported here and not arbitrary Java objects isn't a huge constraint (especially if it's documented).
I think such constraints are perfectly acceptable in conjunction with some other way (e.g. content-type property) for indicating the desired encoding. That way, if you want it encoded in AMQP's type system there may be some restrictions on the object in question, otherwise serialization is used as expected.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
