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? Also I did not quite understand how a JMS MapMessage resembles a HTTP GET request. [1] http://svn.apache.org/repos/asf/webservices/commons/trunk/scratch/senaka/sci-flex/transport [2] http://people.apache.org/~senaka/sciflex-axiom-patch/ 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 >> > >
