Hi Brian,
Thanks for the response. Comments inline ....
On 6/12/06, Brian McCallister <[EMAIL PROTECTED]> 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
