Hi, > > > What we mean by custom types in the context of MessageBuilders/formatters > is that different serializations of the XML infoset. One example would be > fast infoset. When supporting JSON we are using the existing XML<-->JSON > transformation standards (or rather agreements) and I beleive this can also > be called as a different searialisation of XML infoset.. On the other hand > I personally consider a pure JSON service as a web service too... > > No I think your statement is too strong - yes, we support different XML > Infoset serializations too via the MessageBuilder/Formatter architecture but > its a lot more than that because of how we ended up doing non-SOAP stuff. > Not only can we serialize the SOAP Infoset (as an XML Infoset) into a > different XML serialization, but we can also write message formatters and > builders that use the integrated MTOM stuff and OMSourcedElement stuff > (which you did IIRC!) to keep ANY kind of content. In fact those can even > fail if you ask for the payload as XML (or may not)- so if you take a JSON > message and serialize as XML then Bablefish or whatever will kick in. > However if you ask to serialize as JSON directly then NO transforms will > occur and the JSON characters should go in and out seamlessly. >
I kind of still stand by my statement given the fair usage policy of functionality ;-)... Even though OMSourcedElement can keep any type of element, it should be able to serialize it as XML (or provide StaX events) if somebody requests to do so from it. It's kind of a hidden contract for the people who use it and the OMDataSource interface ( http://ws.apache.org/commons/axiom/apidocs/org/apache/axiom/om/OMDataSource.html) reflects that. Yes, practically a user can implement a his own version of OMDataSource without supporting the getXMLReader() and serialiseAsXML methods, but those will fail as soon as Axis2 tries to expand the XML tree (even a logging handler would do this). I don't consider that as the intended use of OMSourcedElement, but rather as exploitation of the functionality. Ability to directly serialize the stuff to the wire without converting to XML back and forth is just an optimization to avoid the cost of transformations when the content is already in the given format. But even in that case if Axis2 wanted to expand the tree, due to some module, then there is not alternative but rather to transform to XML. > Back to the proposed solutions, > >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. > > > >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. > > > The messagefomatter interface[1] defines how to write the SOAP message it > receives to the wire. It does not differentiate anything about the content > of the message (eg: fault or not).. IMHO it's up to the author of the > message formatter to decide whether he is going to treat it diffrently or > not.. Even in the case of JSON, I do not see anything wrong if our JSON > formatter serialised the whole SOAP message (including SOAP). If it > serializes just the payload then it is just simply a decision by the message > format author. > > Yes - and there's nothing at all wrong if the JSON formatter just printed > the payload out in JSON either! What the formatter decides to serialize is a > decision up to that .. and the real contract is between the formatter and > the builder when they are coupled in a request/response MEP. That is, a > message coming in via JSON should probably go out via JSON, unless some type > of content negotiation has kicked in to ask for a different response format. > > > (BTW did you ever do the content negotiation stuff we discussed? Or was > that with Keith .. gettin' old. Maybe we should get content negotiation > working right too in the context of this cleanup. Its not hard.) > Your memory is still pretty good.. It's with both me and Keith.... Actually it was a small change, but I never found time to test it thoroughly and the changes slipped away from my code base over time :(.. Keith is the one who took the job over from me :).. > On the other hand, I consider it as a huge bug if Axis2 is not applying > the message formatters to the Fault flow at all.. IIRC considered the fault > flow and we did this for the fault flow too, so that it'll use the > corresponding formatter/builder in case of a fault.. > > OK good - we're all in agreement that not doing the faults was a mistake! > yes.. Definitely a mistake if we are not doing it.. Current issue is with respect to the usage of isDoingRest() in the inFaultFlow.. Other than that my guess is that the faults are working with formatters & builders, but cannot confirm till I test it out.. thanks, Thilina > > > Sanjiva. > > -- > 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] > -- Thilina Gunarathne - http://thilinag.blogspot.com
