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?
