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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
