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. > 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/
