Hi Brian, that's great. After seeing your patch I realized that we definitely should support the current way of dealing with byte messages. I've planed to do it next week, so it's great to see it done.
What do you (and others) think about providing a mapper implementation for map messages using JSON for formatting. I can provide a patch in a day or two. We can also make a mapper that will use some kind of XML format (maybe something like XML-RPC struct type), for people that prefer XML over JSON. I need this kind of map messages mapper (I'll use JSON in my project), so I will definitely implement it. The question is, whether we want to have it integrated in the ActiveMQ distribution or distribute it in a separate JAR. Regards, Dejan On 10/7/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
I've applied Dejan's patch locally, but it needs some changes to preserve the current behavior. I'll make them and check it in within a couple days. -Brian On Oct 6, 2006, at 7:56 AM, Brian McCallister wrote: > 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 <[EMAIL PROTECTED]> 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? >>> >
