activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Mittler" <>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 10:21:04 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message