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/
