activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
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!

-Brian

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

> Hi Brian,
>
> did you check my patch with similar functionality (
> https://issues.apache.org/activemq/browse/AMQ-943).
>
> 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 <brianm@apache.org> 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?
>>


Mime
View raw message