The idea is to expose our service both as a SOAP service as well as a REST service, which I believe is what Axis2 is built to do.
However, one of our clients has a hard requirement of the response having a processing instruction in the XML document when exposed as a REST service. Something like: <?xml version="1.0"?> <?my-pi allow="abc"?> <responseBody> .. </responseBody> We were intending to do this by manipulating the envelope object available through the MessageContext in either a module handler or a message formatter. But looks like that is not possible. So should we just write a custom formatter which would write whatever message we need directly to the available OutputStream? Is this the best approach or is there something that can be done via configurations (best would be services.xml) Thanks for your responses. Sowmi -----Original Message----- From: Jorge Medina [mailto:[email protected]] Sent: Saturday, September 25, 2010 4:39 PM To: [email protected] Subject: Re: Processing Instruction If you are using Axis2, then I assume that you cannot choose the web services implementation, you ARE using SOAP not REST. REST does not ignore the SOAP header or Envelope; there is no such thing when you are using REST services. You may return plain text, or some custom XML or some JSON structure, or some 'standard' XML like Atom. What is the processing instruction for? Where in the message is your server expecting it to be? On Fri, Sep 24, 2010 at 5:10 PM, Thallapragada, Sowmi <[email protected]> wrote: > Thanks Jorge. > > So if we have access to an "Envelope" (via a custom Message Formatter or a > Module Handler), would it suffice to add the PI to the SOAP Body since > Envelope & SOAP Header are ignored in REST? Or would it have to be added to > the parent of the "Envelope" (which I am not sure how to access as it is NULL > in whatever tests I am performing)? > > > -----Original Message----- > From: Jorge Medina [mailto:[email protected]] > Sent: Friday, September 24, 2010 1:01 PM > To: [email protected] > Subject: Re: Processing Instruction > > In REST you are free to return whatever you want...there is no > limitation, REST is not a standard it is just a "style"...some people > calls it an "architectural approach". > > REST services do not need to return XML. But you may. > You may include processing instructions if you use XML. > > On Thu, Sep 23, 2010 at 2:33 PM, Thallapragada, Sowmi > <[email protected]> wrote: >> Thanks Andreas. >> >> Does this hold true for REST style services as well? >> >> -----Original Message----- >> From: Andreas Veithen [mailto:[email protected]] >> Sent: Thursday, September 23, 2010 11:32 AM >> To: [email protected] >> Subject: Re: Processing Instruction >> >> According to the SOAP specs, processing instructions are forbidden in >> SOAP messages. Here is the relevant quote from the specs: >> >> "A SOAP message MUST NOT contain a Document Type Declaration. A SOAP >> message MUST NOT contain Processing Instructions." >> >> Andreas >> >> On Thu, Sep 23, 2010 at 00:16, Thallapragada, Sowmi <[email protected]> >> wrote: >>> How can I add a processing instruction in my response XML? We would like to >>> add something like: >>> >>> >>> >>> <?access-control allow="*myvalue"?> >>> >>> >>> >>> before the SOAP envelope. Any help is appreciated. >>> >>> >>> >>> Sowmi >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
