Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=fBqid+oEcc7kUEZ9hmrhdEZfys08IAMPIkd79B/pcI1VYzeloLgLT+tBwxjUMBAog1f7LzRnYOmgntXyCCFNnmTbo9Uobm3AgjNREsMdWHSDGTyVh+mi7EUORFOA7df62L1lIVm2BQoUVUFBgf1L9iBcLClW1WgEAEHofxk0I08=
Message-ID: <ec6e67fd0606130907k22b09a32ge5e15a7683297a07@mail.gmail.com>
Date: Tue, 13 Jun 2006 17:07:11 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType
In-Reply-To: 
 <7743F17344E95A4CA78A3E53A7AF496B5C2EEB@corpatsmail1.corp.sensis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <7743F17344E95A4CA78A3E53A7AF496B5C2EEB@corpatsmail1.corp.sensis.com>

BTW I confess to skim reading this thread a little so appologies if I
missed some subtleties along the way :)

So I guess there's 2 things.

(i) Whats the default mapping of stomp content-type <-> JMS Message
that most stomp-jms providers should support by default.

(ii) Allowing folks to customize the mapping of Stomp headers -> JMS Messages.

I'm all for both; I wanna nail down (i) and implement it ASAP. Option
(ii) we can tinker with over time as its probably gonna be a pluggable
strategy we can tweak over time.

e.g. I can imagine use cases where when we see "application/xml" or
"text/xml" or "application/soap" or whatnot to using something like
JAXB/SDO to make an ObjectMessage containing the marshalled body.


On 6/13/06, Mittler, Nathan <nathan.mittler@sensis.com> 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.
> 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/