James, I think that's what we're proposing here. I proposed "amq-msg-type", but I suppose "content-type" is just as good. I think Brian's main concern (Brian, correct me if I'm wrong) is that he'd like the mapping of stomp message to AMQ message type to be pluggable, not hard-coded. So if a user wanted to, they could configure the broker to turn all stomp messages into bytes messages, rather than using the default behavior of handling text and bytes messages differently.
I guess I'm just not sure yet what this pluggable infrastructure should look like, as I don't think there is currently a framework in place. I already have a build with the "hard-coded" approach that is backward compatible with clients that don't use the "amq-msg-type" header. I guess I'll leave this as a question of what should be done: 1) submit what I've got (the hard-coded approach), once it's verified to be working. 2) step back and create a pluggable framework. Regards, Nate -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 10:57 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType FWIW I'd like to have content-type header support. Couldn't we then use content-type as the standard header that any Stomp-JMS bridge would use to decide if something is a TextMessage or a BytesMessage? On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > I think that clears things up for me a bit - what you're proposing makes > sense. I'll poke around today and see what I can come up with. > > Thanks, > Nate > > On 6/12/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > > > > On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote: > > > > > Agreed ... using the "type" header is not an option. > > > > --- From the bug report --- > > It isn't possible to reuse the "type" header (JMSType) for the > > purpose of sending through the information as to what type of message > > it is (text or bytes). So this means that we need to add another > > activemq extension header. I propose "amq-msg-type". > > --- / From the bug report -- > > > > I like this a lot better, and think it would be a reasonable default > > rule for mapping in 4.X. > > > > >> I am not convinced we need this, but I much prefer it to a hardcoded > > >> transform, as this would allow for much more useful transforms (ie, > > >> aplication-aware). > > > > > > > > > Although I agree conceptually, I'm thinking this might be a bit of an > > > overkill for the task at hand. > > > > Agreed. I just hate to layer on another backwards compatibility issue > > beyond what we already have. By designing it to be forward compatible > > with an arbitrary mapping we can grow into a future solution more > > easily. Once we add this header we will need to support it ~forever. > > > > > Right now the STOMP transport only works > > > with bytes and text messages, and creating this transform model > > > won't change > > > that. I think if we one day decide to refactor the transport to > > > accept > > > other message types - that would be the time to make this sort of > > > change. > > > > What if I want to switch on "Content-type" to decide between text or > > bytes? It is a common header to use, but is not part of the spec (as > > stomp doesn;t care, but is happy to pass it along). This makes more > > sense to me in terms of mapping between Stomp and JMS, but it is not > > compatible with switching on a specific content header. > > > > The mapping between Stomp and JMS is actually rather important to get > > right as it is the low level interop mapping between various > > platforms and Java. As such, I want to make sure we are building > > towards a correct solution. > > > > Aside from all this, controlling the protocol <--> (semi-)protocol > > mapping should be a configuration thing, not a flag the client must > > put on every message it sends. > > > > The end goal for me is to have all messages coming in from the Stomp > > adaptor be bytes messages, unless someone has an overriding need for > > something else (quote possible). The current behavior is pretty bad > > as a default, but we just released 4.0 with it, so we are stuck until > > we make another backwards incompatible release (5.0). > > > > In 4.1 we can add the amq-msg-type header to allow people to force > > things to bytes (or text) but for the 5.0 end game we will need to > > make the mapping pluggable in order to make the upgrade path as easy > > as possible. if we are going to need pluggable eventually, why not do > > it now in order to allow people to fix the bytes/text mistake (I can > > say it is a mistake, I wrote it =) at the server level instead of > > having to add a header to every message. > > > > We have, then, three configurations which people are likely to want: > > > > 1) Current (3.2 and 4.0 compatible) one which is made more palatable > > by letting the client specify via the amq-msg-type. > > > > 2) Map everything to bytes, which I would like to make the default in > > 5.0. > > > > 3) Map everything to Text (which is what I would actually use if we > > had it as I convert all the bytes ones I send now into strings anyway). > > > > If we are going to have it be sufficiently pluggable to support these > > three, we should consider letting users provide their own. > > > > -Brian > > > > > > > > -- James ------- http://radio.weblogs.com/0112098/
