Hi, In an offline chat with Sameera, Shameera and Sagara, we decided we will put it in the kernel's axis2.xml, since many products can benefit from the new message builder/receiver, and for ESB, for the moment, they will retain the older settings with their own axis2.xml and later possibly come with a solution for both scenarios to work.
Cheers, Anjana. On Tue, Mar 18, 2014 at 6:07 PM, Anjana Fernando <[email protected]> wrote: > Hi, > > OK, so for now, I will put the changes for DSS product, Sagara, shall we > put the same changes for AS as well, I guess AS functionality will not be > affected by the new builder/formatter. As for ESB having data services > features, there is no straightforward way to make it work now, so we can > say, if proper JSON mapping is needed for data services, either DSS or AS > have to be used and it wont be possible to embed this in the ESB. > > Cheers, > Anjana. > > > On Tue, Mar 18, 2014 at 5:06 PM, Ishan Jayawardena <[email protected]> wrote: > >> Several basic ESB mediators depend on the message built by ESB's existing >> JSON message builder (implemented in Synapse), so switching to this new >> message builder will break them. >> If we need to make DSS features work in ESB, we have to rebuild the >> message for DSS after it has been first built by ESB's builder. Similarly, >> we have to handle the formatter flow. >> >> Thanks, >> Ishan. >> >> >> >> On Tue, Mar 18, 2014 at 3:58 PM, Anjana Fernando <[email protected]> wrote: >> >>> Hi, >>> >>> Yeah, but in the ESB case, it will be a bit tricky, where the WSDL they >>> create by default for proxy services actually create a "mediate" operation >>> and all, so unless the incoming message actually have a "mediate" wrapper >>> in the message, the message builder will fail. So maybe we should have like >>> a axis2.xml parameter to say, for these type of axis2 services, ignore the >>> schema definition, but then again, the streaming message builder actually >>> fully depends on the schema to actually do the streaming and to build the >>> message, so not sure how feasible this would be. Maybe, in the new message >>> builder, it can revert back to the older message builder's implementation, >>> if he can see that the service dispatching has already happened earlier, >>> probably through the URL based dispatcher, and if it can find out that, for >>> this service/service-type, it is not suppose to use the schema based >>> parsing of the message. >>> >>> Cheers, >>> Anjana. >>> >>> >>> On Tue, Mar 18, 2014 at 3:46 PM, Sameera Jayasoma <[email protected]>wrote: >>> >>>> Hi Anjana/Shameera, >>>> >>>> Great stuff. Now we have a proper JSON support in Axis2. >>>> >>>> But we need to think carefully before adding this formatter and the >>>> builder as the default builder/formatter for the application/json content >>>> type. I think we need to fix this JSON support to work in ESB as well. >>>> Otherwise users will not be able to deploy data services features ESB. >>>> >>>> If we improve this JSON support to handle xsd:any type then we should >>>> be able to support proxy services case. >>>> >>>> Lets fix this to work in ESB as well and then we can commit it to the >>>> Kernel. >>>> >>>> Thanks, >>>> Sameera. >>>> >>>> >>>> >>>> >>>> On Tue, Mar 18, 2014 at 2:28 PM, Shameera Rathnayaka <[email protected] >>>> > wrote: >>>> >>>>> Hi Anjana et al, >>>>> >>>>> Above new JSON implementation has been introduced to handle XML <--> >>>>> JSON lossless transformation. and this implementation highly depend on the >>>>> schema definitions, where it generate the message structure by reading >>>>> this >>>>> schemas. In short, to work XML stream base JSON implementation we need to >>>>> have proper schema definition for in and out messages otherwise it won't >>>>> work. >>>>> >>>>> Addition to the above entries we need to do following changes to >>>>> axis2.xml file in order to integrate above implementation. >>>>> >>>>> Remove RequestURIOperationDispatcher handler from dispatch phase and >>>>> place it as the last handler in transport phase. IMO it is ok to move >>>>> RequestURIOperationDispatcher to transport phase as we are dealing with >>>>> URI. >>>>> >>>>> Now add new JSONMessageHandler after the >>>>> RequestURIOperationDispatcher. Finally transport phase would be like >>>>> following >>>>> >>>>> <phaseOrder type="InFlow"> >>>>> <!-- System predefined phases --> >>>>> <phase name="Transport"> >>>>> ------------- >>>>> <handler name="RequestURIOperationDispatcher" >>>>> >>>>> class="org.apache.axis2.dispatchers.RequestURIOperationDispatcher"/> >>>>> <handler name="JSONMessageHandler" >>>>> >>>>> class="org.apache.axis2.json.gson.JSONMessageHandler" /> >>>>> </phase> >>>>> ------------ >>>>> </phaseOrder> >>>>> >>>>> Thanks, >>>>> Shameera. >>>>> >>>>> >>>>> >>>>> On Tue, Mar 18, 2014 at 1:40 PM, Anjana Fernando <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We've added JSON mapping support for DSS, which is mentioned in the >>>>>> mail with subject "JSON Mapping Support for Data Services". For this, >>>>>> I've >>>>>> used the GSON based streaming JSON message builder/formatter, where this >>>>>> was needed for a correct JSON message generation by looking at the >>>>>> service >>>>>> schema. There were some fixes done by Shameera lately, and this is >>>>>> working >>>>>> properly now for all of the scenarios I've tested. So shall we ship this >>>>>> message builder/formatter by default from the axis2.xml in the kernel, so >>>>>> all the products, including AS and DSS will get this feature. It will be >>>>>> specifically required by AS, as it still contains the data services >>>>>> features. >>>>>> >>>>>> And for ESB, I'm not sure how the new message builder/formatter would >>>>>> work, since they will not always have correct service schemas in proxy >>>>>> services etc.. so I guess those scenarios may fail, maybe Shameera can >>>>>> give >>>>>> some insight on this more. Anyways, the ESB has their own axis2.xml, so >>>>>> they will not be affected. >>>>>> >>>>>> So shall we go ahead in updating the kernel's axis2.xml to contain >>>>>> the following sections? .. >>>>>> >>>>>> <messageFormatter contentType="application/json" >>>>>> class="org.apache.axis2.json.gson.JsonFormatter" /> >>>>>> >>>>>> <messageBuilder contentType="application/json" >>>>>> class="org.apache.axis2.json.gson.JsonBuilder" /> >>>>>> >>>>>> Cheers, >>>>>> Anjana >>>>>> -- >>>>>> *Anjana Fernando* >>>>>> Technical Lead >>>>>> WSO2 Inc. | http://wso2.com >>>>>> lean . enterprise . middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Software Engineer - WSO2 Inc.* >>>>> *email: shameera AT wso2.com <[email protected]> , shameera AT >>>>> apache.org <[email protected]>* >>>>> *phone: +9471 922 1454 <%2B9471%20922%201454>* >>>>> >>>>> *Linked in : * >>>>> http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561 >>>>> *Twitter : *https://twitter.com/Shameera_R >>>>> >>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> blog: http://sameera.adahas.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> *Anjana Fernando* >>> Technical Lead >>> WSO2 Inc. | http://wso2.com >>> lean . enterprise . middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Ishan Jayawardena >> Senior Software Engineer >> Mobile: +94 (77) 408 2330 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
