Hi Manoj, Not the axis2_client.xml, since ESB is using it, and other servers like DSS and AS will not be using it, which is what this is mainly aimed for, so lets not change that now. As for tenant-axis2.xml, what does that do? .. is it the same as standard axis2.xml for tenants or something.
Cheers, Anjana. On Wed, Mar 19, 2014 at 10:50 AM, Manoj Kumara <[email protected]> wrote: > Hi Anjana, > > I committed the fix relevant to axis2.xml to patch0006 with r198653. > > Should we need to apply this change to *axis2_client.xml, > tenant-axis2.xml *configuration files also ? > > Thanks, > Manoj > > > *Manoj Kumara* > Software Engineer > WSO2 Inc. http://wso2.com/ > *lean.enterprise.middleware* > Mobile: +94713448188 > > > On Tue, Mar 18, 2014 at 7:46 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Sameera / Carbon Team, >> >> Can you please apply the patch at [1], to patch0006 in Turing branch, >> Carbon 4.3.0 and the trunk. >> >> [1] https://wso2.org/jira/browse/CARBON-14738 >> >> Cheers, >> Anjana. >> >> >> On Tue, Mar 18, 2014 at 7:15 PM, Sagara Gunathunga <[email protected]>wrote: >> >>> >>> >>> >>> On Tue, Mar 18, 2014 at 7:06 PM, Anjana Fernando <[email protected]>wrote: >>> >>>> 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. >>>> >>> >>> Proposed new JSON Builder/Formatter are much effective if the underline >>> server is the final destination but for ESB this is not the case hence we >>> don't need to apply this change to ESB. >>> >>> Thanks ! >>> >>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
