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