On Wed, Jan 4, 2012 at 4:40 PM, Andreas Veithen <andreas.veit...@gmail.com>wrote:
> 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. > ???? your question was Are you going to drop that requirement from the Axis2 architecture or else, what would be the XML representation of a JSON message received by that message receiver? Answer - Drop that requirement. thanks, Amila. > > 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 > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
