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 16:19:58 GMT

On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote:

> 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.

Actually, my first choice would be hard coded to bytes message,  
period, finished =)

We cannot do this without breaking backwards compatibility, which I  
have been presuming we don't want to do.

The most important thing, to me, when mapping from Stomp to JMS is to  
have it be very predictable. I don't want to ever have someone have a  
JMS client listening for stuff from Stomp and having to guess at the  
message type. As such, the default should be "it is X." If they need  
some other mapping, I would suggest that they look at some kind of  
transformer service which republishes messages.

If we are going to have more complicated mapping, I want to either  
make it super crippled: a default "compatibility mode" and a strong  
recommended "5.0 mode." The next step is to make mapping pluggable,  
but don't make a big deal out of it. As ben Laurie would say, a  
European style API.

That is the external point of view. For the internal point of view,  
the cleanest implementation I can think of is to have an interface  
which takes a Send (or something like) and returns an ActiveMQMessage.

I am quite strongly against using using application level metadata  
(which content-type is in Stomp and JMSType is in JMS) for mapping  
information. I am also quite against every client having to specify  
what to map the message to as the client should be able to be  
independent of the particular implementation. I think it is a very  
bad idea to require the client to add the mapping to every message.


> 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 []
> Sent: Tuesday, June 13, 2006 10:57 AM
> To:
> 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 <> 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 <> 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
> -------

View raw message