activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 17:06:28 GMT
I agree with all that. In a pure Stomp world, content-type is a very
useful header and probably affect how the stomp client processes the
message.

Whatever the default rule is for Stomp <-> JMS I'd have thought most
JMS providers would (through configuration or implementation) probably
use that to make a sensible choice over Text v Bytes - even if it may
break backward compatibility. (It should be trivial to configure
backwards compatibility - everything is BytesMessage if folks really
care)


On 6/13/06, Brian McCallister <brianm@apache.org> wrote:
>
> 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
>
> > 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 [mailto:james.strachan@gmail.com]
> > Sent: Tuesday, June 13, 2006 10:57 AM
> > To: activemq-dev@geronimo.apache.org
> > 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 <nathan.mittler@gmail.com> 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 <brianm@apache.org> 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
> > -------
> > http://radio.weblogs.com/0112098/
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message