[
https://issues.apache.org/jira/browse/AXIS2-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232565#comment-13232565
]
Sagara Gunathunga commented on AXIS2-5270:
-------------------------------------------
These are some comments according to my last post.
1.) It would be great if you can use a dedicated Boolean flag to decide the
particular message will process by JosnRPCMessageReceiver or fullback to use
RPCMessageReceiver instead of INPUT_STREAM property because this make your
design clean and well defined. I would like to see following flow.
In JosnRPCMessageReceiver check above flag and decide further processing.
In RPCMessageReceiver add the same check and if it's true return a fault
instead of further processing. This case can occur when user enable
JSONBuilder/JSONFormatter in axis2.xml but haven't define
JosnRPCMessageReceiver MRs in services.xml file. With this improvement your MR
modification become consistent.
2.) I don't think we can drop the support for other transports hence IMO we
need to create first element of SOAP envelope in order to employ SOAP Body
based dispatching, I think you can create JsonStreamParser [1] and read first
element to facilitate to above then you can use same JsonStreamParser instance
to further unmarshaling.
[1] -
http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/JsonStreamParser.html
3.) Look likes you have some good numbers with performance but IMO you have to
test your new JSON implementation with existing JSON implementation for a
better comparison also use around 50 000 message for testing .
> [GSOC 2012] Improve Json support in Axis2 with google-gson
> ----------------------------------------------------------
>
> Key: AXIS2-5270
> URL: https://issues.apache.org/jira/browse/AXIS2-5270
> Project: Axis2
> Issue Type: Improvement
> Components: json
> Affects Versions: 1.7.0
> Reporter: Shameera Rathnayaka
> Assignee: Shameera Rathnayaka
> Labels: gsoc2012, gson, json
> Fix For: 1.7.0
>
> Attachments: JsonTestService.aar, attachments.zip,
> performance_test.txt
>
>
> There are two ways that xml string can be converted into JSON string,
> Badgerfish and Mapped . Current Axis2 with JSON module completely supports
> Badgerfish convention[1] while partialy supports Mapped convention[1] as
> Mapped formatted JSON with namespaces are not supported in Axis2. Therefore
> if the client side java-script code needs to talk with java service which is
> deployed in Axis2, it should be sent as Badgerfish convention. It is
> cumbersome to generate Badgerfish convention of JSON string again and again
> to call services if there is no xml representation string in client side.
> If java script client can send JSON object to relevant java service in Axis2,
> defining service and operation in request url, without doing any
> modifications to JSON objects, then it would be very helpful for Java-Script
> users at client side.
> According to the thread in the mailing list, which discussed $subject we have
> two approaches. i have summarized those two approaches as below.
> 1. Store json inputstream in message context at the message builder while
> putting dummy SOAPEnvelop to the message context, and using google-gson
> process it inside the message receiver
> 2. Preserve the requirement that a message must have a well defined SOAP
> infoset and use a trivial representation similar (or identical) to what we
> use for plain text. This has the advantage that it is more in line with the
> rest of the Axis2 architecture,
> or
> another option is to write an xmlstream reader/writer implementation to
> parse the json stream. And provide that xml stream implementation to Axiom.
> [1]http://wso2.org/library/768
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
