Hi Robert, > > Not only when consuming messages, but also when creating them. Yes, > it > > appears the message factory mechanism was intented to do this to a > point > > (though it seems the upper level public APIs didn't quite keep this > in > > mind). > > Yes, perhaps this is a good opportunity to address that.
I'll propose a few changes to the API in a separate email to allow for this. > Ah yes, looking at the current text message it doesn't really provide > a reasonable way to extract the underlying bytes. > > You should perhaps override the mapping for the text/plain MIME type > to be just a bytes message. Of course if you are just going to as a > first step turn the message into a String then there isn't any > advantage. There are still some advantages, I think (and it *is* more flexible), but I could certainly live with this. Mostly, I'm not so concerned about my own connector, as given the added flexibility in the API for the first point (i.e. handling MIME types better) I can get around most of the issues. However, doing something as simple as sending a text message with a new mime type shouldn't really require the consumer to jump through the hoops of registering new mime types and all, that's all I meant. But again, that's something I could live with. Tomas Restrepo http://www.winterdom.com/weblog/
