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/

Reply via email to