activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Mittler" <nathan.mitt...@gmail.com>
Subject Re: STOMP and JMSType
Date Mon, 12 Jun 2006 23:14:31 GMT
Hi Brian,
Thanks for the response.  Comments inline ....

On 6/12/06, Brian McCallister <brianm@apache.org> wrote:
>
> JMSType is a reserved header in JMS, for use at the application
> level. I think what you are proposing is more accurately an ActiveMQ
> specific transform header. I think this type of transform should
> either be a real, arbitrary, pluggable, transform mechanism, or
> should not be done.


Agreed ... using the "type" header is not an option.

I would much prefer to *always* use a bytes message, but this is
> backwards incompatible so cannot be done in 4.X.
>
> I would propose that instead of overloading JMSType, if we think we
> need to have a transform/mapping mechanism we base it on an active-mq
> specific header, and make it something like:
>
> STOMPMessageTransformer {
>    public ActiveMQMessage transform
> (SomeRepresentationOfTheSendFrameIncludingHeaders frame) {
>      ...
>    }
> }
>
> 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.  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.

I think that, properly, this should be done by a service on the
> messaging bus though, NOT in a protocol handler.


The  logic to choose which message to create already lies in the transport,
I'm just changing the logic.  If we want to refactor this, then I think that
is another JIRA issue for another day (and discussion :) ).

-Brian
>

Thanks,
Nate

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message