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

Reply via email to