activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 00:06:23 GMT
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  

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.


View raw message