There's actually a gap in the documentation in this area. CXF also supports "byte" as the message type in the configuration to use a BytesMessage.
Dan On Tue November 3 2009 5:50:20 pm Bryan99 wrote: > The W3C SOAP over JMS spec for the JMS body states the following > (http://www.w3.org/TR/soapjms/#binding-message-body) : > > "The contents of the JMS Message body MUST be the SOAP payload as a JMS > BytesMessage or TextMessage. [Definition: Use fault subcode > unsupportedJMSMessageFormat when the arriving message format is not > BytesMessage or TextMessage. ]." > > The CXF user guide notes on specifying JMS messageType reads as follows: > > "You can specify the message type supported by the consumer endpoint using > a jms:runtimePolicy element that has a single attribute: > messageType - Specifies how the message data will be packaged as a JMS > message. text specifies that the data will be packaged as a TextMessage. > binary specifies that the data will be packaged as an ObjectMessage." > > The fuse documentation goes a little further: > > "JMS consumer endpoints specify the type of messages they use. JMS consumer > endpoint can use either a JMS ObjectMessage or a JMS TextMessage. When > using an ObjectMessage the consumer endpoint uses a byte[] as the method > for storing data into and retrieving data from the JMS message body. When > messages are sent, the message data, including any formating information, > is packaged into a byte[] and placed into the message body before it is > placed on the wire. When messages are received, the consumer endpoint will > attempt to unmarshall the data stored in the message body as if it were > packed in a byte[]." > > It seems to me that using message type binary indicates that ObjectMessage > will be used which seems to be in violation of the SOAP over JMS spec. > However, does the fact that the ObjectMessage wraps a byte array make it > not violate the spec? > > I'm confused, can anyone un-confuse me? Perhaps I shouldn't care. > > Thanks anyway. > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
