On Fri, Dec 30, 2011 at 05:55, Amila Suriarachchi <amilasuriarach...@gmail.com> wrote: > > > On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen > <andreas.veit...@gmail.com> wrote: >> >> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi >> <amilasuriarach...@gmail.com> wrote: >> > >> > >> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen >> > <andreas.veit...@gmail.com> >> > wrote: >> >> >> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka >> >> <shameerai...@gmail.com> wrote: >> >> > 2. store json string without doing any process untill it reaches >> >> > JsonMessageReceiver. JsonMessageReceiver is a new Message Receiver >> >> > which >> >> > use >> >> > gson to convert json to java objects, call relevant operation and get >> >> > result. >> >> >> >> What this means in practice is that you will have a message builder, a >> >> message receiver and a message formatter that interact with each >> >> other, but that have no meaningful interaction with any other >> >> component of the Axis2 framework (the fundamental reason being that >> >> google-gson defines a mapping between JSON and Java objects, but >> >> eliminates XML from the picture). The question is then why would a >> >> user go through all the pain of setting up Axis2 for this? >> > >> > >> > if you look into a point where users only need to expose a POJO with >> > json >> > then they don't have to use Axis2. >> > >> > But if the user want to expose the same POJO service both soap and json >> > formats this provides a value in terms of performance for latter case. >> > In >> > this case JSON message receiver can be written extending RPC message >> > receiver and call the normal RPC processing if the received message is >> > not a >> > json one. >> > >> > thanks, >> > Amila. >> >> As you know, Axis2 assumes that every message it processes is >> representable as XML (which is different from CXF where a message can >> have different representations, depending on the phase that is >> executed). Until now this has always been the case, even for plain >> text and unstructured binary data. Are you going to drop that >> requirement from the Axis2 architecture > > > Drop that requirement ( I would say initially Axis2 is designed like that > but latter specially in all contract first approaches it has not followed > this for performance reasons) and make an efficient way to work with JSON. > Then obviously this won't support WS-Security etc .. which are anyway > meaningless for json. > > If you look at how ADB works for non security (or non message building case) > is similar to this. It stores the xml stream in the Axiom object (this > feature has come from axiom differed building) and get that underline stream > at the message receiver and directly build the java objects from that. Then > at the response also it save the response in OMDatasource and directly > serialize to the xml stream at the formatter. > > So idea for this is to provide such a direct stream parsing serializing > technique which performs well for POJO objects to communicate using json. > > thanks, > Amila.
You are mixing two things here: (1) The requirement that a message must always have a well defined XML representation. (2) The requirement that the XML representation is constructed as a DOM like in memory representation. In all the examples you cite, (1) is satisfied. One of the goals of the Axis2 architecture is to make (2) a non-requirement, and that has never changed. Also note that in my post, I said "representable as XML", and not "represented as a fully built DOM like in memory object model". Therefore you didn't answer my question at all. Andreas >> >> or else, what would be the XML >> representation of a JSON message received by that message receiver? >> >> > >> >> >> >> >> >> Andreas >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> >> >> > >> > >> > >> > -- >> > Amila Suriarachchi >> > WSO2 Inc. >> > blog: http://amilachinthaka.blogspot.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> > > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
