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: [email protected]
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/
