activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac" <>
Subject Re: Pluggable Stomp/AMQ translation
Date Fri, 06 Oct 2006 07:22:49 GMT
Hi Brian,

did you check my patch with similar functionality (

I've implemented Hiram's idea:
Translator (Mapper in that patch's terminology) is selected when the client
sends a CONNECT message, according to the value of the protocol-mapping
header. For example,

protocol-mapping: byte

will mark that client expects byte messages.

In that moment it uses a FactoryFinder to look up for the appropriate
transalator. FactoryFinder searches through all
"META-INF/services/org/apache/activemq/transport/mapping/" folders (we can
change this name if necessary) in all classpath JARs. If it finds a "byte"
file (for example) it will read a class name that implements the byte
messages translation (
org.apache.activemq.transport.stomp.ByteProtocolMapping in this case) and
use it to translate messages. If desired mapper is not found (or not
specified in the first place) the default mapper (translator) will be used.

In this way there is no need for any external configuration for the
framework. You simply provide the JAR with the appropriate META-INF content
and the translator is automatically registered.

Maybe you can use some of these ideas for your solution or we can merge them
in one.


On 10/6/06, Brian McCallister <> wrote:
> Just checked in a first take on pluggable stomp to amq translation.
> Right now there is one interface defined for doing both message
> conversions and destination name conversions.
> The behavior for the legacy conversion scheme is identical, I just
> moved the code around so that those four functions could be varied.
> Right now it takes the FrameTranslator instance off the transport
> factory. This probably isn't ideal, but I wanted to talk about the
> best way to do it here before trying to muck around with xbean.
> -Brian
> ps: Speaking of xbean, has anyone considered making a less sysadmin-
> hostile configuration scheme than java class names mapped not-quite-
> obviously into XML?

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