On Sun, Sep 21, 2008 at 12:21 AM, Eran Chinthaka <[EMAIL PROTECTED]>wrote:
> 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. > Agreed. It would be nice if we could solve the more general question too. > > > 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? > With current MessageBuilders/MessageFormatters they build/format requests based on content-type. I'm not too familiar with the fault message flow in Axis2 (Will have a look on that and get back) But why arn't we allowing the corresponding builder/formatter to format faults too? If that was the case I think this problem would not occur. Looks like the fundemental problem lies in there. > > > 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 > It will definitely come in handy for projects such as Synapse who use Axis2. Thanks, Keith. > (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 > -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
