From activemq-dev-return-3253-apmail-geronimo-activemq-dev-archive=geronimo.apache.org@geronimo.apache.org Sat Oct 07 19:02:20 2006 Return-Path: Delivered-To: apmail-geronimo-activemq-dev-archive@www.apache.org Received: (qmail 34010 invoked from network); 7 Oct 2006 19:02:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Oct 2006 19:02:19 -0000 Received: (qmail 92999 invoked by uid 500); 7 Oct 2006 19:02:19 -0000 Delivered-To: apmail-geronimo-activemq-dev-archive@geronimo.apache.org Received: (qmail 92977 invoked by uid 500); 7 Oct 2006 19:02:19 -0000 Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-dev@geronimo.apache.org Delivered-To: mailing list activemq-dev@geronimo.apache.org Received: (qmail 92964 invoked by uid 99); 7 Oct 2006 19:02:19 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Oct 2006 12:02:19 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [208.210.124.79] ([208.210.124.79:56892] helo=rune.pobox.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 2F/B7-09076-9B9F7254 for ; Sat, 07 Oct 2006 12:02:18 -0700 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 752958719E for ; Sat, 7 Oct 2006 15:02:36 -0400 (EDT) Received: from [10.0.1.2] (c-67-188-124-104.hsd1.ca.comcast.net [67.188.124.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 3FE0D8653E for ; Sat, 7 Oct 2006 15:02:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <45B0A9AF-0A61-4604-BADE-1FA2CE37496E@apache.org> <36e91d9d0610060022k5c71be77vac10d0b02dfe8e4a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CCAE55C-EFB0-4B9B-A129-0C67E12ECC89@apache.org> Content-Transfer-Encoding: 7bit From: Brian McCallister Subject: Re: Pluggable Stomp/AMQ translation Date: Sat, 7 Oct 2006 12:02:07 -0700 To: activemq-dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 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? >>> >