Sounds great, go for it Dejan! On 9/20/06, Dejan Bosanac <[EMAIL PROTECTED]> wrote:
This sounds to me like the best approach to this problem. It simplifies implementation of the configuration mechanism and at the same time gives just enough flexibility. I don't think that there will be many (if any) clients that will want to change mapping for connections that are already established.If others agree with this approach, I can try to find some time these days to do some work in this direction. Thanks, Dejan On 9/19/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > I think that the client should only be allowed to change the default > mapping if he optionally specifies a 'protocol-mapping' header when he > connects. Something like > > CONNECT > login:<username> > passcode:<passcode> > protocol-mapping: foo > > Where foo is mapped to a implementation of ProtocolMapper/Converter. > Then the client will be expected to send messages in that mapping > format and all messages sent to it will also conform to that format. > > On 9/19/06, Dejan Bosanac <[EMAIL PROTECTED]> wrote: > > And one copy for this list as I assume that we will continue discussion here :) > > > > On 9/19/06, Dejan Bosanac <[EMAIL PROTECTED]> wrote: > > > I think that in order to make this framework usable, it has to be > > > simple. It could be a simple interface such as > > > > > > public interface ProtocolTransformer { > > > public StompFrame convertMessage(ActiveMQMessage message) > > > throws IOException, JMSException; > > > > > > public ActiveMQMessage convertMessage(StompFrame command) > > > throws IOException, JMSException; > > > } > > > > > > this two methods would be called at appropriate places (probably at > > > the begging) of the methods in the ProtocolConverter class. In this > > > way we would allow developers to change message type and/or set > > > appropriate headers, which seems to me would be more than enough. > > > > > > The one thing that I'm not sure of is how the ProtocolConverter will > > > decide which transformers it should call. For incoming Stomp messages > > > someone mentioned a solution which seems fine: to put an extra header > > > in the stomp message (such as amq-msg-type or activemq-transformation > > > or whatever) which would have a full class name of the transformer to > > > be applied. Then the ProtocolConverter would try to load this > > > transformer and if it succeed it would apply the transformation. > > > > > > But this solution is not working for messages that are sent from the > > > broker to the stomp clients. We need some mechanism which will say, > > > apply this transformation to the ByteMessages so we need a mechanism > > > that will be able to register all transformers to the > > > ProtocolConverter and then every transformer would be responsible to > > > detect whether it should or not change the message. > > > > > > For configuring purposes we could use Service Provider JAR > > > functionality (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider) > > > since it is the only way I can think of that not requires external > > > configuration. > > > > > > Two questions that we need to address: > > > > > > 1. do we want to enable more than one transformation to be applied? > > > 2. how this framework will affect overall performances? > > > > > > What do you think? > > > > > > Regards, > > > Dejan > > > > > > On 9/19/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > > > > (Replying at top as it is a long message :-) > > > > > > > > The mapping be configured by naming a "converter" of some kind in the > > > > activemq.xml > > > > > > > > This is a bit tricksier than it might be because the activemq.xml is > > > > just a specialized spring config which reads a lot of stuff from a > > > > URL syntax, and adding Java classnames in a URL is the ick. > > > > > > > > I've started poking around and my current plan is to pull the AMQ > > > > message creating and Stomp message creation bits out of the protocol > > > > converter and use an implementation of some mapping interface to do > > > > the conversion. > > > > > > > > Exactly what the interface needs to look like I am not sure yet. In > > > > order to handle largish messages, it should probably deal with > > > > DataInput (AMQ's stream/buffer+channel hiding thing) instances, but > > > > we'll have had to already parse the type to get this far, so it may > > > > be a case of doing some parsing of the headers, and passing the data > > > > input in to be munged, or it may fall out that something else is more > > > > useful. > > > > > > > > For encoding AMQ to stomp, we are faced with something similar -- we > > > > pass in the JMS message, which might be a stream message with a large > > > > body, we probably want to be able to "chunk" it out, that means > > > > either making a stomp frame abstraction which can read from a stream > > > > and is returned by the converter, or having the converter actually > > > > "send" the message on the wire. Not sure which I like more. > > > > > > > > Thoughts? > > > > > > > > -Brian > > > > > > > > On Sep 18, 2006, at 7:45 AM, Dejan Bosanac wrote: > > > > > > > > > Thanks James. > > > > > > > > > > > > > > >> > > > > >> We've a Stomp transport for ActiveMQ which is here... > > > > >> http://incubator.apache.org/activemq/maven/activemq-core/xref/org/ > > > > >> apache/activemq/transport/stomp/package-summary.html > > > > >> > > > > >> which can currently deal with all the stomp messages nicely. Maybe > > > > >> you > > > > >> mean to extend that? Or did you have something else in mind? > > > > >> > > > > > > > > > > > > > > > In one of his comments Brian said that he plans to create pluggable > > > > > handling framework for stomp messages for ActiveMQ 4.1. > > > > > > > > > > Following that idea, I have even found a discussion on this topic > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ > > > > > 200606.mbox/% > > > > > [EMAIL PROTECTED] > > > > > > > > > > which is related to handling of ByteMessages. > > > > > > > > > > > > > > > I thought that this is exactly what I would like to have for handling > > > > > of this kind of "map" messages. As I see it, it would be the best to > > > > > extend functionality of the > > > > > > > > > > public ActiveMQMessage convertMessage(StompFrame command) > > > > > > > > > > method in the > > > > > > > > > > org.apache.activemq.transport.stomp.ProtocolConverter > > > > > > > > > > class > > > > > > > > > > I can add hard-coded mapping for this special case, or as Brian said, > > > > > introduce some additional flexibility by allowing developers to submit > > > > > their own converter classes at this point. Who knows what other > > > > > "protocol" on top of Stomp someone would be interesting to create in > > > > > the future (or what kind of object serialization/deserialization to > > > > > perform). > > > > > > > > > > The only thing that I'm not sure of is how these plugins would be > > > > > configured. > > > > > > > > > > In any case, I won't start doing any work on this before we agree on > > > > > how this functionality should look like, or whether it is necessary to > > > > > make any changes at all. > > > > > > > > > > Dejan > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe from this list please visit: > > > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe from this list please visit: > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com >
-- James ------- http://radio.weblogs.com/0112098/
