activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mittler, Nathan" <>
Subject RE: STOMP and JMSType
Date Tue, 13 Jun 2006 17:19:57 GMT
Just to make clear what the proposed new "hard-coded" logic does:

1) If there is no content-length, it's a text message (same as before)
2) else, if there is no message type, it's a bytes message (same as
3) else use amq-msg-type to determine the message type

So this logic is backward-compatible with the existing logic.  If the
client does not specify "amq-msg-type", the behavior will be the same as
it is now.  

The STOMP protocol doesn't define a mapping to a JMS system, so as far
as predictability goes, the users just need to follow our logic for the
mapping.  They wouldn't be able to change the mapping, like they would
with a pluggable framework, but they shouldn't need to.  They just code
their clients against the mapping that we publish online and they'll be
up and running.  

I'm getting the feeling that the main reason for leaning toward the
pluggable framework is to support a BytesMessage-only paradigm.  In a
STOMP-only world this probably makes sense.  You're just and receiving
"stuff".  But when you're bridging between Stomp and JMS, I'm not sure
why a client would ever want this restriction.  It seems like if you
want BytesMessages to come out the other end, then you just follow our
mapping logic to make that happen, which really is as simple as
including "content-length" (which you would have to include for a true
bytes message anyway) and leave off "amq-msg-type" (which you would by

Even if you were to implement a pluggable framework, you would still
need to have some sort of application metadata like the "amq-msg-type"
header.  Assuming our framework is comprised of a bunch of message
transformers that go between raw bytes and ActiveMQMessages, the default
transformer for the STOMP transport would do this mapping the way I've
proposed above.  So you wouldn't be eliminating the need for the
"amq-msg-type" header, you'd just be pushing around the logic that uses

So I guess I'm still not seeing the bang for the buck ... it seems like
the "hard-coded" solution works for all cases that we've defined so far.
I'd rather just get this functionality in because I think it's useful
and people have been asking for it.  I'm all for continuing to discuss
the pluggable framework, but it seems that that is a separate issue from
what I'm trying to do here (...and probably literally a separate JIRA


-----Original Message-----
From: Brian McCallister [] 
Sent: Tuesday, June 13, 2006 12:20 PM
Subject: Re: STOMP and JMSType

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.


View raw message