Hi Andreas, I have added a working implementation that adds MapMessage support to the JMS Transport at [1] (rev. 708016). Also, the source of the AXIOM patch is available at [2]. There is also a mail that I sent to the list, to discuss an efficient serialization scheme that one could use when retrieving the XML payload from the OMSourcedElement which is backed by a java.util.Map, at [3]. The current implementations ([1] and [2]) use a Java serialization scheme which as of now seems to be better than the rest. Also, some portions of code in [2] are hacks and need to be finalized.
[1] http://svn.apache.org/repos/asf/webservices/commons/trunk/scratch/senaka/sci-flex/transport [2] http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom [3] http://markmail.org/message/gfa6qrgwuuldse5e Thanks, Senaka On Sun, Oct 26, 2008 at 11:51 PM, Andreas Veithen <[EMAIL PROTECTED] > wrote: > On Mon, Oct 20, 2008 at 22:49, Senaka Fernando <[EMAIL PROTECTED]> > wrote: > > Hi Andreas, > > > > Thanks for the clarifications. If the builders/formatters for JMS is not > > mandatory. I believe that I have done most of the coding required for the > > addition of MapMessage support. I'm looking forward to extend the present > > tests to include testing for MapMessages as well, and be certain that my > > implementation works. You can find the implementation at [1], and you > will > > need to provide a patch to Axiom available at [2] which adds MapBackedOM > > support to represent MapMessages as a java.util.Map attached to the OM > Tree. > > > > By the way, do you have any documents, discussions, wikis etc, on how the > > test-kit for the JMS Transport is organized? > > There is no documentation yet and it is still work in progress. > > > Also I did not quite understand > > how a JMS MapMessage resembles a HTTP GET request. > > Both represent a set of key-value pairs. The difference is that for a > JMS MapMessage, the values are typed, while in HTTP GET, the values > are simple strings. > > > > > [1] > > > http://svn.apache.org/repos/asf/webservices/commons/trunk/scratch/senaka/sci-flex/transport > > [2] > > http://people.apache.org/~senaka/sciflex-axiom-patch/<http://people.apache.org/%7Esenaka/sciflex-axiom-patch/> > > Is the source code of the AXIOM patch (in particular MapDataSource) > available somewhere? > > > Thanks, > > Senaka > > > > On Tue, Oct 21, 2008 at 2:47 AM, Andreas Veithen <[EMAIL PROTECTED]> > wrote: > > > >> > >> On 20 oct. 08, at 23:00, Senaka Fernando wrote: > >> > >> Hi Asankha, > >>> > >>> Thanks for the reply. I would also like to know, > >>> > >>> 1. > >>> > >>> To count the number of bytes sent over JMS and report the value via > JMX > >>>> > >>>> The current calculation only counts the number of bytes in the JMS > >>> payload. > >>> However, the actual Message might be much larger (or am I mistaken > here?); > >>> also, why can't we use a scheme like, > >>> java.lang.instrument.Instrumentation. > >>> getObjectSize() in here? > >>> > >>> > >> That is a common problem in all the transports: it is generally not > >> possible to determine the number of bytes that are effectively sent on > the > >> wire. Therefore the bytes count has no precisely defined meaning and is > only > >> an indication. > >> > >> 2. What's the typical purpose of a Message Formatter? JMS MapMessages > >>> wouldn't require a separate message formatter isn't it? or am I > mistaken > >>> here? > >>> > >>> > >> To transform a SOAP infoset into data conforming to some content type. > >> Message builders and formatters assume that the message payload is a > stream. > >> Since this is not the case for MapMessages, no message builder/formatter > >> should be used. This makes sense because MapMessages are a concept > specific > >> to JMS, while message builders/formatters are meant to be useable with > any > >> kind of transport. > >> > >> Note however that MapMessages are somewhat similar to HTTP GET requests. > >> Maybe they should be represented in the same way as a SOAP infoset?? > >> > >> Thanks, > >>> Senaka > >>> > >> > >> > > >
