activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 17:45:12 GMT
On 6/13/06, Mittler, Nathan <> wrote:
> 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
> before)
> 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
> default).
> 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
> it.
> 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
> issue).

I agree.  But instead calling the header 'amq-msg-type' (which does
not explicitly convey that a transformation is being used), I'd like
it to be called 'activemq-transformation' set to a class name of the
transformation (or something that maps to a classname, like we do for
our service discovery).

and this would be header that is not carried with the message, it's a
header that controls the send and subscribe operations.

> Regards,
> Nate
> -----Original Message-----
> From: Brian McCallister []
> Sent: Tuesday, June 13, 2006 12:20 PM
> To:
> 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.
> -Brian


View raw message