activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: Pluggable Stomp/AMQ translation
Date Fri, 06 Oct 2006 14:56:08 GMT
D'oh, I did miss it, and it is a better solution :-)

I'll roll back my change later this morning and apply yours.  
Apparently, we think alike, we have the exact same interfaces, you  
have a much better way of selecting mappings though!


On Oct 6, 2006, at 12:22 AM, Dejan Bosanac wrote:

> 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.
> Regards,
> Dejan
> 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?

View raw message