Hi Nandika, yes .we choose Axiom has default soap processing library because it supports differed building and uses StAx API for processing XML events and XPath support . Seems it is matured library for handling SOAP .
On Fri, Jun 17, 2016 at 9:59 AM, Nandika Jayawardana <[email protected]> wrote: > Hi Isuru, > > So the XML processing library will be Axiom right. +1 for axiom since its > very comprehensive when it comes to soap processing. > > Regards > NAndika > > On Fri, Jun 17, 2016 at 9:55 AM, Isuru Ranawaka <[email protected]> wrote: > >> Hi Jochen, >> >> Your suggestion is very interesting and thanks for providing a valuable >> idea. Actually we are in the process of designing error handling in CGW >> and need to think about error handling strategies like, Per exception >> based error handling, Mediation level error handling , Pipeline level error >> handling , Global level error handling etc .. and how to fit them with >> Next GEN ESB Language and runtime. >> >> Thanks >> Isuru >> >> On Thu, Jun 16, 2016 at 1:18 AM, Jochen Traunecker < >> [email protected]> wrote: >> >>> Hi Isuru, >>> >>> have you considered some kind of robust "Fallback-Reader" capable of >>> reading whatever comes in as binary raw data? It might be very handy in >>> error handling like illegal characters in XML payloads, wrong encoding of >>> payloads, malformed payloads and so on. >>> >>> A typical scenario is like this: a illegal payload ends up in some >>> fault-handler ( e.g. XML parser throws an exception). Fault-Handling should >>> be able to process the illegal payload like encoding it as Base64 compliant >>> text and write it to the log-file and so on. By that Fault-Handling should >>> be able to access the payload as binary data stream through >>> "Fallback-Reader". Ideally "Fallback-Reader" provides convenience >>> functionality like base64 encoding, compressing, ... >>> >>> Regards, >>> Jochen >>> -- >>> Jochen Traunecker >>> https://www.linkedin.com/in/jochen-traunecker >>> >>> >>> >>> >>> Isuru Ranawaka <[email protected]> schrieb am Di., 14. Juni 2016 um >>> 19:27 Uhr: >>> >>>> Hi all, >>>> >>>> >>>> We have identified three scenarios when considering content aware >>>> support in Next Gen ESB . These can be categorized as a pure pass thru >>>> scenario where payload is not touched , reading the content without >>>> modifying scenario and reading and modifying the content. So we came up of >>>> initial design and implementation of the content reading part. We have >>>> come up with different message readers for different content types . For >>>> example, for the XML message XMLReader is used and for the JSON Messages >>>> JSONReader is used. Message readers are pluggable via OSGI service. >>>> >>>> [image: reader_implementation.png] >>>> >>>> >>>> Reader Registration >>>> >>>> - >>>> >>>> Gateway core consists of in memory registry which keeps registered >>>> MessageReaders according to content type. >>>> - >>>> >>>> Message readers are registered via OSGI services. >>>> - >>>> >>>> JSON message reader and XML message reader are implemented as two >>>> different OSGI bundles. >>>> - >>>> >>>> CarbonMessage is supported with reading content as InputStream and >>>> write content via OutputStream. >>>> >>>> >>>> Message Flow >>>> >>>> - >>>> >>>> Need to specify the portion of the message that needs to be read >>>> via XPath or JSONPath according to the content type. >>>> - >>>> >>>> When message hits the content aware mediator it checks weather >>>> message is already read if so then it takes MessageDataSource which is >>>> data >>>> holder for already read message inputstream according contentType.Else >>>> it >>>> gets the matching reader from reader registry and read the input stream >>>> and >>>> load the inputstream into MessageDataSource. >>>> - >>>> >>>> XPath and JSONPath are evaluated using MessageDataSource >>>> - >>>> >>>> Serialize data from MessageDataSource to CarbonMessage before >>>> sending to the transport level after mediation. >>>> >>>> >>>> >>>> XML Reading >>>> >>>> - >>>> >>>> Axiom is used for represent XML messages as OMElements >>>> - >>>> >>>> Axiom uses StAX API for read and write XML messages which is >>>> inherently supports deferred building concept. >>>> - >>>> >>>> AxiomXpath is used for evaluate XPath and it used Jaxen as >>>> underlying XPath library. >>>> - >>>> >>>> XPath libraries are pluggable. >>>> >>>> >>>> >>>> JSON Reading >>>> >>>> - >>>> >>>> Jayway library is used for represent JSONPath. >>>> - >>>> >>>> Underlying JSON library is Jackson. >>>> - >>>> >>>> Jackson has JSONParser and JSONGenerator which are similar to >>>> StreamingXMLReader and Writer in StAX API and can read, write events in >>>> streaming manner. >>>> - Jackson supports data binding as well. >>>> >>>> >>>> Thanks >>>> -- >>>> Best Regards >>>> Isuru Ranawaka >>>> M: +94714629880 >>>> Blog : http://isurur.blogspot.com/ >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Best Regards >> Isuru Ranawaka >> M: +94714629880 >> Blog : http://isurur.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nandika Jayawardana > WSO2 Inc ; http://wso2.com > lean.enterprise.middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards Isuru Ranawaka M: +94714629880 Blog : http://isurur.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
