Hi, But what if we have an option to turn the xml decl off if we don't need it... Therefore we can turn it off in the case of tcp.
IMHO we can have the default behaviour of OMDocument serialization to : - Set the xml decl - set Char encoding as utf-8 which will be inherited by the proposed SOAPMessage, and values set in the MC can be used to override these as required. On 8/3/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > ARGH I hate it :( .. would we not be creating a parallel structure to > MessageContext? I suggest (1) and pass the MC into the serialization > stuff? I any case, whether to gen the xml decl could depend on the > transport (think http vs tcp) and then you need the MC to know the > transport. > > Sanjiva. > > On Wed, 2005-08-03 at 12:18 +0530, Shahi, Ashutosh wrote: > > +1 to the main idea. This is how even SAAJ manages XML declaration and > > character encoding. > > > > > > > > Ashutosh > > > > > > ______________________________________________________________________ > > From: Eran Chinthaka [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 03, 2005 6:50 AM > > To: [email protected] > > Subject: [Axis2] SOAPMessage > > > > > > > > > > Hi all, > > > > > > > > Current source, we have only the SOAPEnvelope that contains the soap > > message. But IMO, I think its better to have SOAPMessage as well to > > contain XML Declaration, Encoding, etc., > > > > So that when sending a message transport will get the output from > > SOAPMessage.serialize, not SOAPEnvelope.serialize. > > > > > > > > Here are the evaluations of other alternations to solve the above > > problem. > > > > > > > > 1. put those stuff in message context. > > > > Serializing code is in the envelope and it doesn't have access to the > > message context. If someone needs to serialize he must be able to do > > it without having a message context. > > > > 2. Put this information in OMOutputImpl. This is not practical as we > > create a new OMOutputImpl whenever we want to serialize. So I don't > > think it's a good idea to have state within the OMOutputImpl. > > > > > > > > So what do you all think about this suggestion. This may involve some > > changes to the code. > > > > > > > > Regards, > > > > Chinthaka > > > > > > > > > > > -- Ruchith
