(Replying at top as it is a long message :-)
The mapping be configured by naming a "converter" of some kind in the
activemq.xml
This is a bit tricksier than it might be because the activemq.xml is
just a specialized spring config which reads a lot of stuff from a
URL syntax, and adding Java classnames in a URL is the ick.
I've started poking around and my current plan is to pull the AMQ
message creating and Stomp message creation bits out of the protocol
converter and use an implementation of some mapping interface to do
the conversion.
Exactly what the interface needs to look like I am not sure yet. In
order to handle largish messages, it should probably deal with
DataInput (AMQ's stream/buffer+channel hiding thing) instances, but
we'll have had to already parse the type to get this far, so it may
be a case of doing some parsing of the headers, and passing the data
input in to be munged, or it may fall out that something else is more
useful.
For encoding AMQ to stomp, we are faced with something similar -- we
pass in the JMS message, which might be a stream message with a large
body, we probably want to be able to "chunk" it out, that means
either making a stomp frame abstraction which can read from a stream
and is returned by the converter, or having the converter actually
"send" the message on the wire. Not sure which I like more.
Thoughts?
-Brian
On Sep 18, 2006, at 7:45 AM, Dejan Bosanac wrote:
Thanks James.
We've a Stomp transport for ActiveMQ which is here...
http://incubator.apache.org/activemq/maven/activemq-core/xref/org/
apache/activemq/transport/stomp/package-summary.html
which can currently deal with all the stomp messages nicely. Maybe
you
mean to extend that? Or did you have something else in mind?
In one of his comments Brian said that he plans to create pluggable
handling framework for stomp messages for ActiveMQ 4.1.
Following that idea, I have even found a discussion on this topic
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/
200606.mbox/%
[EMAIL PROTECTED]
which is related to handling of ByteMessages.
I thought that this is exactly what I would like to have for handling
of this kind of "map" messages. As I see it, it would be the best to
extend functionality of the
public ActiveMQMessage convertMessage(StompFrame command)
method in the
org.apache.activemq.transport.stomp.ProtocolConverter
class
I can add hard-coded mapping for this special case, or as Brian said,
introduce some additional flexibility by allowing developers to submit
their own converter classes at this point. Who knows what other
"protocol" on top of Stomp someone would be interesting to create in
the future (or what kind of object serialization/deserialization to
perform).
The only thing that I'm not sure of is how these plugins would be
configured.
In any case, I won't start doing any work on this before we agree on
how this functionality should look like, or whether it is necessary to
make any changes at all.
Dejan
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email