On Mon, Sep 22, 2008 at 9:00 AM, Sanjiva Weerawarana <[EMAIL PROTECTED]>wrote:
> I think the whole question of "REST" is not the point here. > > Axis2's underlying data model is a SOAP Infoset. As a result, any type of > data that runs thru the system has to be represented as a SOAP Infoset. > That's not a big deal - essentially it means we need to create two extra > Axiom nodes (a s:Envelope node and an s:Body node) and stick a child in > there that contains whatever the real data is. Using our nice MTOM > integration and the deferred pull architecture of Axiom, we can do that > efficiently using OMSourceElement nodes as we've proven multiple times now. > > That's for incoming stuff - we take whatever that comes in and represent it > within a SOAP Infoset. > > When we have an outgoing message, the inverse question is relevant - if the > message is not going out as SOAP, then someone needs to take the real > message payload (which is in the child node of the s:Body node) and only > write the content of that. That's basically what MessageFormatters do. > > [So calling all of that "REST" is totally wrong and an abuse of what "REST" > means. I think we need to refactor that code and get rid of any references > to REST as this has nothing to do with REST. Yes I know the history and how > it got called that but now its time to fix it.] > +1. Better later than never ;). > > > Now to get back to your original point - I think the idea of having message > formatters applied to faults too (which you proposed in a later mail) is the > right answer. Faults are just messages too and its clearly an oversight that > we didn't apply the design orthogonally there too. Time to fix it. > +1. Thanks, Keith. > > > Sanjiva. > > > keith chapman wrote: > > Let me describe the problem in more detail. As of now Axis2 enables you to > plug in various message types by registering them in the axis2.xml. Some of > these message types will be SOAP based (like text/xml and > application/soap+xml) while others are not. And in the latter case when a > exception occurs somewhere in the pipe we do not want to throw the fault as > a SOAP message. What we do in the REST case of of now is that we take the > fault element in the SOAP body (If not found the first child of the SOAP > body) and write that out as the fault. As of now Axis2 treats a few message > Types as REST specifically application/xml, multipart/form-data and > application/x-www-form-urlencoded. But with the pluggable message types in > place this may not work that well. Assume that someone want to to plug in > application/foo and that this message type is REST how are we gonna handle > it? > > Should we consider adding a attribute to the > messageBuilders/messageFormatters section to indicate weather its REST or > not? > > Thanks, > Keith. > > On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana < > [EMAIL PROTECTED]> wrote: > >> +1 .. but I'm a bit confused. I assume by "REST" you meant that the >> response has media type text/xml instead of application/soap+xml, right? >> >> If we think about it that way, can we get rid of the "isDoingREST" flag?? >> >> (I've hated that from day 1 and haven't had a chance to really dig thru it >> and figure out how to get rid of. Maybe this is an opportunity to get it >> right ..) >> >> Sanjiva. >> >> keith chapman wrote: >> >> Any input on this would be appreciated. >> >> Thanks, >> Keith. >> >> On Thu, Sep 4, 2008 at 8:40 AM, keith chapman <[EMAIL PROTECTED]>wrote: >> >>> Hi devs, >>> >>> This idea came up because of the following scenario. >>> >>> Currently the logic for creating a AxisFault for a fault received lies >>> in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly >>> when the received fault is SOAP or REST. But it does not work as expected >>> when the response is JSON ( rather a exception is thrown saying "The >>> MessageContext does not have an associated SOAPFault."). The reason is the >>> logic we use to build the AxisFault. If the fault message is not a SOAP >>> message we check for the flag messageContext.isDoingREST() and get the first >>> element of the SOAPBody as the fault message. >>> >>> When the fault message is JSON its neither SOAP and the >>> messageContext.isDoingREST() returns false. Should we consider JSON >>> messages as REST messages? I believe so. >>> >>> WDYT? >>> >>> Thanks, >>> Keith. >>> >>> -- >>> Keith Chapman >>> Senior Software Engineer >>> WSO2 Inc. >>> Oxygenating the Web Service Platform. >>> http://wso2.org/ >>> >>> blog: http://www.keith-chapman.org >>> >> >> >> >> -- >> Keith Chapman >> Senior Software Engineer >> WSO2 Inc. >> Oxygenating the Web Service Platform. >> http://wso2.org/ >> >> blog: http://www.keith-chapman.org >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >> Member; Apache Software Foundation; http://www.apache.org/ >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >> >> Blog: http://sanjiva.weerawarana.org/ >> >> --------------------------------------------------------------------- To >> unsubscribe, e-mail: [EMAIL PROTECTED] For additional >> commands, e-mail: [EMAIL PROTECTED] > > > > > -- > Keith Chapman > Senior Software Engineer > WSO2 Inc. > Oxygenating the Web Service Platform. > http://wso2.org/ > > blog: http://www.keith-chapman.org > > > -- > Sanjiva Weerawarana, Ph.D. > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
