On 9/18/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
(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.
When you want to avoid icky long class names I recommend you use the
Factory pattern we for the transports, discovery agents, wire formats,
and event jdbc adapters. Basically you can use the FactoryFinder to
map a simple string name to your 'converter' factory.
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.
sounds good to me.
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.
I'd keep it simple. Avoid the DataInput stream for now until we prove
it's a performance problem. I would start by just factoring out this
interface out of ProtocolConverter:
interface MappingStrategy {
public StompFrame convertMessage(ActiveMQMessage message) throws
IOException, JMSException;
public ActiveMQMessage convertMessage(StompFrame command) throws
IOException, JMSException;
public ActiveMQDestination convertDestination(String name)
throws ProtocolException;
protected String convertDestination(Destination d);
}
and have a DefaultMappingStrategy that is implemented using the
current methods that are provided. The ProtocolConverter would then
delegate to the MappingStrategy which is defaulted to a
DefaultMappingStrategy implementation. But our Stomp transport would
then have an additional configurable string property
'mappingStrategy'. If it's set, we use that string to look up a
MappingStrategyFactory using the FactoryFinder.
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?
I say keep it simple. the current method signatures of the
convertMessage methods should work.
-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
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
