Hi Keith, This solution will solve the JSON problem (if we consider JSON messages as REST, which I'll comment in a different email), but will not solve the more general question IMO.
We have enabled to plug custom content types, and do we wanna restrict these custom types to always be either REST or SOAP compatible? If yes, then we can live with it. But if not, then we need more flexibility to handle it. For example, as Keith pointed, when we get a SOAP fault, what should be do with it? Then the question comes as to what really Axis2 is. If we enable plugging custom types, which are not compatible with SOAP or REST, then aren't we redefining what Axis2 is? Do we wanna make it something which can handle more than Web services (I consider "REST within Axis2" also as Web services, as our REST implementation is based on WSDL 2.0 HTTP binding) Just thinking loud. Thanks, Chinthaka On Fri, Sep 19, 2008 at 10:04 PM, keith chapman <[EMAIL PROTECTED]>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 > -- With Mettha, Eran Chinthaka -------------------------------------------------------------------- Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada
