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
>
>
