axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shameera Rathnayaka <shameerai...@gmail.com>
Subject Re: Improve Json support with Axis2 using google-gson java library
Date Sat, 24 Mar 2012 14:12:24 GMT
HI devs,

As i am making a good progress with the first approach of this proposal, I
would like to get a start to second approach, meanwhile i hope to polish
first approach. I am going to implement this as follows but this may not be
the best way to do it. In that case it would be very helpful if you can
point me out and explain the way you think that will best fit for that
which i hope to present in my proposal.

2nd approach:
I'll write a GsonXMLStreamReader class which implements XMLStreamReader[4]
interface. The main concern about this implementation is how we deal with
namespaces. For the implementation purposes i'll hard code a namespace
field under the GsonXMLStreamReader class, which value is "
http://axis2.apache.org/axis2/json". This might not be the best way so
please advice me about how i can improve this. I am going to override all
methods in XMLStreamReader intreface(Hope it is possible to do) using
google-gson library.

In builder, create a GsonXMLSreamReader using
JsonStreamParser/JsonReader[2][3] with inputstream.Then it will create SOAP
envelop and add method/operation(SOAP action). Now it will be able to do
body base dispatching also, therefore non HTTP transports request can
process, as pointed out by Sagara in his reply[1] to the corresponding JIRA
issue. After that GsonXMLStreamReader provides data, using
JsonStreamParser/JsonReader, when ever it is required .

Same thing happen in GsonXMLStreamWriter, which implements
XMLStreamWriter[5].

[1] https://issues.apache.org/jira/browse/AXIS2-5270
[2]
http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/JsonStreamParser.html
[3]
http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/stream/JsonReader.html
[4]
http://docs.oracle.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html
[5]
http://docs.oracle.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html


Thanks ,
Shameera.

On Fri, Mar 16, 2012 at 3:32 AM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

> Hi sagara,
>
> On Thu, Mar 15, 2012 at 9:46 PM, Sagara Gunathunga <
> sagara.gunathunga@gmail.com> wrote:
>
>> I have tested your patch and have some comments  to give. First, can
>> you create a JIRA issue for this and update above details with all
>> attachments there it's hard to keep the track  of progress of your
>> work in mail thread.
>>
>
>
> I have created an issue[1] for this. I'll attached samples, In above
> sample i dont use pojo classws so i think it would be better if i put a
> pojo sample. I already have implemented a pojo service and client for this
> il add those ASAP to the jira.
>
> [1]https://issues.apache.org/jira/browse/AXIS2-5270
>
> Thanks,
> Shameera.
>
>>
>> Thanks !
>>
>> On Sat, Mar 3, 2012 at 2:55 PM, Shameera Rathnayaka
>> <shameerainfo@gmail.com> wrote:
>> > Hi devs,
>> >
>> > As we discussed in this thread previously there are two ways we can add
>> this
>> > json implementation to axis2 .
>> > 1. First one is get the inputstream and use gson to create java beans
>> and
>> > use hava reflection to invoke method. In this scenario we assume it uses
>> > requiest url base dispatching and we know service and operation at this
>> > stage when it come to particular Message Receiver .
>> >
>> > 2. Second one is build this json string the way we can integrate with
>> > existing Architecture. Create an XMLStreamReader implementation with
>> gson
>> > reader or  construct a SOAPEnvelope that builds that representation
>> lazily
>> > (using the OMSourcedElement/OMDataSource API). I don't know the
>> different of
>> > these two, need to clarify more about this scenario.
>> >
>> > I did some background search and referred some code parts in Axis2. As i
>> > have been in touch with Axis2 project it was easy to understand the
>> basic
>> > things, therefore i implemented the first part which i have mentioned
>> above
>> > as a way of being prepared for GSoC 2012 in the coming months. However
>> this
>> > is not the final work in that first part, but is the progress i have
>> made so
>> > far with the project.
>> >
>> > I have attached my implementation as a patch for current trunk.
>> > For testing purposes i have attached a simple service and client which
>> send
>> > http post request to sample service(Sample service attached with this
>> reply)
>> > post request has required json string as a request entity.
>> >
>> > Feedbacks are appreciate as it would help me a lot in presenting my
>> final
>> > proposal for the project :)
>> >
>> > Attachments
>> >
>> > 1. json-iml.patch   --> my implementation patch for current trunk
>> > 2. JsonImlTest.aar  --> sample service to deploy in axis2
>> > 3. SimpleJsonClient.java --> simple code which send a request to
>> >  JsonService( in JsonImlTest) using http post method
>> > 4. axis2_json.xml  --> modified configuration file, i have added my json
>> > formatter and builder under the application/json-iml content type, Yes
>> we
>> > can decide a good content type later this is only for testing purpose.
>> >
>> >
>> >
>> >
>> > On Thu, Jan 12, 2012 at 2:05 PM, Amila Suriarachchi
>> > <amilasuriarachchi@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
>> >> <shameerainfo@gmail.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
>> >>> <amilasuriarachchi@gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
>> >>>> <andreas.veithen@gmail.com> wrote:
>> >>>>>
>> >>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>> >>>>> <shameerainfo@gmail.com> wrote:
>> >>>>> > Here what i understood simply is under the 1st approch Inside the
>> >>>>> > message
>> >>>>> > builder class i need to get the input stream and store it inside
>> the
>> >>>>> > message
>> >>>>> > context as a property to access later, while putting a dummy SOAP
>> >>>>> > envelope.
>> >>>>> > And dispatching will be occurred request uri based.i.e dummy
>> message
>> >>>>> > would
>> >>>>> > be some thing like
>> >>>>> >
>> >>>>> >
>> >>>>> >
>>  <soap:Envelope><soap:Body><ns:wrapper>Json</ns:wrapper></soap:Body></soap:Envelope>
>> >>>>> >
>> >>>>> > This input-stream is processed only inside the message receiver
>> when
>> >>>>> > gson
>> >>>>> > reads the input stream and create relavant java objects from that.
>> >>>>> >
>> >>>>> > Response is also handled same as request handle but bottom up way.
>> >>>>> >
>> >>>>> > In the 2nd approach Inside the message builder class i have to get
>> >>>>> > the input
>> >>>>> > stream and build the Json String first and then store it as
>> >>>>>
>> >>>>> Not exactly. You would not read the input stream in the message
>> >>>>> builder, but construct a SOAPEnvelope that builds that
>> representation
>> >>>>> lazily (using the OMSourcedElement/OMDataSource API). If something
>> >>>>> (e.g. a logging/auditing handler) between the message builder and
>> the
>> >>>>> message receiver attempts to access the SOAPEnvelope, then the input
>> >>>>> stream will be read and the corresponding Axiom objects created on
>> the
>> >>>>> fly. If the SOAPEnvelope reaches the message receiver untouched,
>> then
>> >>>>> you would feed the input stream (more or less) directly to
>> >>>>> google-gson.
>> >>>>
>> >>>>
>> >>>> Another option is to write an xmlstream reader/writer implementation
>> to
>> >>>> parse the json stream. And provide that xml stream implementation to
>> Axiom.
>> >>>>
>> >>>> This model works with other data bindings such as ADB as well.
>> >>>
>> >>>
>> >>> If we use xmlstream reader/writer to parse the json stream. How it
>> works
>> >>> with ADB ?
>> >>
>> >>
>> >> ADB I mean the ADB generated code. Which only uses the xmlstream API
>> >> instead of Axiom. Anyway Axiom is also written on top of xmlstream
>> layer. So
>> >> if we can create a json type implementation for xmlstreams that will
>> work
>> >> with any axis2 instance.
>> >>
>> >>>
>> >>> as i know ADB needs xml representation of all elements to process i.e
>> ADB
>> >>> create complex and simple types of relevant xml representation of the
>> >>> request, and process the request. But here we only have wrapped xml
>> >>> elements. Should i implement ADB to use with json?
>> >>>
>> >>>>
>> >>>> thanks,
>> >>>> Amila.
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> Once you start your GSOC project, we will point you to some samples
>> >>>>> (such as the plain text handling in Synapse) that show how this
>> works.
>> >>>>>
>> >>>>> >
>>  <soap:Envelope><soap:Body>json-string</soap:Body></soap:Envelope> ,
>> >>>>> > json-string would be something like "method":{"name":"value"}.
>> >>>>> >
>> >>>>> > After that inside the message receiver it is processed using
>> google
>> >>>>> > gson.
>> >>>>> > It can be dispatched using request uri based and qname based as
>> >>>>> > sagara
>> >>>>> > mentioned previous post.
>> >>>>> >
>> >>>>> > I'am interesting in doing these two approaches as the GSoc
>> project.
>> >>>>> >  According to the knowledge that i have in Axis2 this
>> implementation
>> >>>>> > can be done. But not sure about the workload of each approach
>> because
>> >>>>> >  most probably i will meet lot of problems with these approaches.
>> >>>>> >
>> >>>>> >
>> >>>>> > About the analyzing part - First as a student i would like touch
>> >>>>> > architecture
>> >>>>> > and designing side also, But can you clarify your idea a little
>> bit
>> >>>>> > as i
>> >>>>> > have seen
>> >>>>> > there are few blog posts explaining why axis2 cant support Mapped
>> >>>>> > convention?.
>> >>>>> >  Because it's not possible to know the namespace mappings used on
>> one
>> >>>>> > side
>> >>>>> > of the transport to the other side (client or service).
>> >>>>>
>> >>>>> The situation is actually somewhat similar to how WSDL 2.0 attempted
>> >>>>> to describe REST services: on one side you have a client that speaks
>> >>>>> REST (using various HTTP verbs, resource identifiers, etc.) and on
>> the
>> >>>>> other side you have a Web service with an abstract interface that is
>> >>>>> described in terms of operations, messages and XML schema
>> constructs.
>> >>>>> The Web service engine then also needs to know how to map REST
>> >>>>> requests/responses to operations, messages, etc. These mappings are
>> >>>>> described in a WSDL binding.
>> >>>>>
>> >>>>> In the case of mapped JSON, it's actually even simpler, because the
>> >>>>> engine "only" needs to map between JSON prefixes and XML namespaces.
>> >>>>> However, as in the REST/WSDL 2.0 case that mapping is specific to a
>> >>>>> given service. It would actually be trivial to implement something
>> >>>>> that lets the developer specify these mappings on a service (a
>> service
>> >>>>> parameter would be enough for that), but the problem is that the
>> >>>>> message builder (which is responsible to generate the XML
>> >>>>> representation) doesn't know which service will be invoked and is
>> >>>>> therefore unable to locate that configuration.
>> >>>>>
>> >>>>> >
>> >>>>> > On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
>> >>>>> > <andreas.veithen@gmail.com>
>> >>>>> > wrote:
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> I think that it would also be interesting to add another task in
>> the
>> >>>>> >> scope of that GSOC project, namely to analyze why Axis2 doesn't
>> have
>> >>>>> >> a
>> >>>>> >> good support for mapped JSON. In fact, if you look at Shameera's
>> >>>>> >> initial post, he (she?)
>> >>>>> >
>> >>>>> > It's he :)
>> >>>>> >
>> >>>>> >
>> >>>>> > Thanks
>> >>>>> > Shameera
>> >>>>> >
>> >>>>> >>
>> >>>>> >> takes the fact that "Mapped formatted JSON
>> >>>>> >> with namespaces are not supported in Axis2" as a basic
>> assumption.
>> >>>>> >> The
>> >>>>> >> interesting question is actually why this is so. I was thinking
>> >>>>> >> about
>> >>>>> >> this a couple of months ago, and I believe that this is actually
>> due
>> >>>>> >> to a too restrictive assumption that is made in the Axis2
>> >>>>> >> architecture
>> >>>>> >> (which is that it is possible to construct a SOAP infoset solely
>> >>>>> >> based
>> >>>>> >> on the properties of the incoming message, i.e. the content of
>> the
>> >>>>> >> message and its content type), and that this is connected to some
>> >>>>> >> other problems as well as the presence of code in Axis2 that
>> doesn't
>> >>>>> >> fit naturally into the architecture.
>> >>>>> >>
>> >>>>> >> Fixing that properly would probably be out of scope for a GSOC
>> >>>>> >> project, but doing an analysis would be highly interesting, in
>> >>>>> >> particular if Shameera is interested not only in development, but
>> >>>>> >> also
>> >>>>> >> in architecture and design.
>> >>>>> >>
>> >>>>> >> I think that if one includes these different things into the
>> >>>>> >> proposal,
>> >>>>> >> it would indeed make a very interesting GSOC project. Can we
>> agree
>> >>>>> >> on
>> >>>>> >> that?
>> >>>>> >>
>> >>>>> >> Andreas
>> >>>>> >>
>> >>>>> >> On Wed, Jan 4, 2012 at 13:54, Sagara Gunathunga
>> >>>>> >> <sagara.gunathunga@gmail.com> wrote:
>> >>>>> >> > This proposal is to address real issue with Axis2, that is in
>> >>>>> >> > Axis2 JSON
>> >>>>> >> > messages are not perform well as XML messages. Since we have
>> >>>>> >> > enough time
>> >>>>> >> > for
>> >>>>> >> > GSoC we can decide the best approach for this. With your
>> >>>>> >> > explanation 2nd
>> >>>>> >> > approach sound good to me , also this approach enable to use
>> QName
>> >>>>> >> > based
>> >>>>> >> > dispatching on JSON messages too.
>> >>>>> >> >
>> >>>>> >> > One design consideration need to fulfill is full streaming
>> support
>> >>>>> >> > in
>> >>>>> >> > builders/formatters level so that gson can process underline
>> >>>>> >> > stream
>> >>>>> >> > directly, otherwise this proposal is meaningless.
>> >>>>> >> >
>> >>>>> >> > My thought about project scope is first let student to define
>> the
>> >>>>> >> > goals
>> >>>>> >> > and
>> >>>>> >> > scope and give our comments later during community discussion
>> >>>>> >> > period so
>> >>>>> >> > that
>> >>>>> >> > he can add/remove some additional goals that he has confidence
>> on
>> >>>>> >> > implementing them.
>> >>>>> >> >
>> >>>>> >> > Thanks !
>> >>>>> >> >
>> >>>>> >> > On Wed, Jan 4, 2012 at 4:27 PM, Andreas Veithen
>> >>>>> >> > <andreas.veithen@gmail.com>
>> >>>>> >> > wrote:
>> >>>>> >> >>
>> >>>>> >> >> Axiom is an object model for XML and SOAP. Using it to store
>> >>>>> >> >> something
>> >>>>> >> >> that doesn't have an XML representation is sonsense. What you
>> are
>> >>>>> >> >> probably referring to is the fact that an OMDataSource that
>> backs
>> >>>>> >> >> an
>> >>>>> >> >> OMSourcedElement can store an arbitrary Java object. However,
>> the
>> >>>>> >> >> OMDataSource must be able to produce an XML representation of
>> >>>>> >> >> that
>> >>>>> >> >> data. More precisely it must be able to create a
>> representation
>> >>>>> >> >> in the
>> >>>>> >> >> form of an XMLStreamReader and it must be able to write the
>> XML
>> >>>>> >> >> representation to an XMLStreamWriter.
>> >>>>> >> >>
>> >>>>> >> >> At the level of Axis2 that translates into the fact that when
>> a
>> >>>>> >> >> message flows through the Axis2 engine, at any given point in
>> >>>>> >> >> time
>> >>>>> >> >> that message has a well defined SOAP infoset. In principle you
>> >>>>> >> >> could
>> >>>>> >> >> serialize the message to an XML document, deserialize it again
>> >>>>> >> >> and
>> >>>>> >> >> replace the SOAPEnvelope in the MessageContext with that
>> >>>>> >> >> deserialized
>> >>>>> >> >> message, without changing the outcome of the request.
>> >>>>> >> >>
>> >>>>> >> >> I don't know what you are doing in WSO2 products, but to my
>> >>>>> >> >> knowledge
>> >>>>> >> >> there is no exception to that rule in Axis2 or Synapse, even
>> for
>> >>>>> >> >> plain
>> >>>>> >> >> text and binary messages. For both types of messages,
>> >>>>> >> >> Axis2/Synapse
>> >>>>> >> >> internally uses a well defined SOAP infoset:
>> >>>>> >> >>
>> >>>>> >> >> - For plain text messages, the SOAP infoset uses an element
>> that
>> >>>>> >> >> wraps
>> >>>>> >> >> the entire text message as character data. E.g. for a message
>> >>>>> >> >> with
>> >>>>> >> >> content "my message", the SOAP infoset would be (namespaces
>> >>>>> >> >> removed):
>> >>>>> >> >>
>> >>>>> >> >> <soap:Envelope><soap:Body><ns:wrapper>my
>> >>>>> >> >> message</ns:wrapper></soap:Body></soap:Envelope>
>> >>>>> >> >>
>> >>>>> >> >> - For binary messages, the SOAP infoset uses an element that
>> >>>>> >> >> wraps the
>> >>>>> >> >> message encoded as base64Binary.
>> >>>>> >> >>
>> >>>>> >> >> That being said, Axis2 uses several Axiom features to avoid
>> >>>>> >> >> building a
>> >>>>> >> >> full DOM like in memory representation of the entire SOAP
>> >>>>> >> >> infoset:
>> >>>>> >> >>
>> >>>>> >> >> - For a request, the databindings consume the SOAP infoset
>> >>>>> >> >> without
>> >>>>> >> >> building the Axiom tree.
>> >>>>> >> >> - For a response, the databindings use an
>> >>>>> >> >> OMDataSource/OMSourcedElement that is able to write the XML
>> >>>>> >> >> representation directly to an XMLStreamWriter.
>> >>>>> >> >> - For plain text, we also use a special OMDataSource
>> >>>>> >> >> implementation
>> >>>>> >> >> that is able to produce the XML representation shown above,
>> but
>> >>>>> >> >> that
>> >>>>> >> >> at the same time allows to stream the character data.
>> >>>>> >> >> - For binary messages, we simply use the Axiom features that
>> are
>> >>>>> >> >> also
>> >>>>> >> >> used for XOP/MTOM, i.e. we construct a complete Axiom tree,
>> but
>> >>>>> >> >> with
>> >>>>> >> >> an OMText instance that refers to a DataHandler with the
>> binary
>> >>>>> >> >> data.
>> >>>>> >> >>
>> >>>>> >> >> However, these various optimizations don't change anything
>> about
>> >>>>> >> >> the
>> >>>>> >> >> fact that in Axis2, a message always has a well defined SOAP
>> >>>>> >> >> infoset.
>> >>>>> >> >>
>> >>>>> >> >> Since google-gson defines a direct mapping between JSON and
>> Java
>> >>>>> >> >> without defining an XML representation, you will have two
>> >>>>> >> >> options:
>> >>>>> >> >>
>> >>>>> >> >> 1. Use an OMDataSource that doesn't have an XML
>> representation,
>> >>>>> >> >> i.e.
>> >>>>> >> >> that doesn't have meaningful implementations of the getReader
>> and
>> >>>>> >> >> serialize methods, but that only acts as a holder for a Java
>> >>>>> >> >> object
>> >>>>> >> >> that can't be transformed to XML. That would clearly be a
>> misuse
>> >>>>> >> >> of
>> >>>>> >> >> Axiom.
>> >>>>> >> >>
>> >>>>> >> >> 2. Define a trivial XML representation, which would be the
>> JSON
>> >>>>> >> >> string
>> >>>>> >> >> wrapped in a wrapper element. Since this is the same thing as
>> we
>> >>>>> >> >> do
>> >>>>> >> >> for plain text, we already have the corresponding message
>> >>>>> >> >> builders and
>> >>>>> >> >> formatters, and one would simply map these
>> builders/formatters to
>> >>>>> >> >> the
>> >>>>> >> >> JSON content type. Implementing the proposal would then
>> require
>> >>>>> >> >> only
>> >>>>> >> >> three things:
>> >>>>> >> >>
>> >>>>> >> >> - Implementing the message receiver.
>> >>>>> >> >> - Probably one would have to create a specialized OMDataSource
>> >>>>> >> >> that
>> >>>>> >> >> enables streaming of the response.
>> >>>>> >> >> - Potentially some minor enhancements to Axiom and/or the
>> plain
>> >>>>> >> >> text
>> >>>>> >> >> message builders/formatters to make sure that streaming is
>> fully
>> >>>>> >> >> supported.
>> >>>>> >> >>
>> >>>>> >> >> Since the message receiver is basically glue gode between
>> >>>>> >> >> google-gson,
>> >>>>> >> >> Axiom and the service object, it will be fairly trivial. The
>> >>>>> >> >> problem
>> >>>>> >> >> is then that the scope of this is likely not large enough for
>> a
>> >>>>> >> >> GSOC
>> >>>>> >> >> project.
>> >>>>> >> >>
>> >>>>> >> >> Andreas
>> >>>>> >> >>
>> >>>>> >> >> On Sun, Jan 1, 2012 at 16:25, Sanjiva Weerawarana
>> >>>>> >> >> <sanjiva@opensource.lk>
>> >>>>> >> >> wrote:
>> >>>>> >> >> > +1 - while Andreas this functionality can be implemented
>> >>>>> >> >> > without
>> >>>>> >> >> > Axis2,
>> >>>>> >> >> > the
>> >>>>> >> >> > proposed feature would add a lot of value to use of Axis2
>> as a
>> >>>>> >> >> > way to
>> >>>>> >> >> > have
>> >>>>> >> >> > services that have a good JSON binding in addition to other
>> >>>>> >> >> > bindings.
>> >>>>> >> >> > Axiom's design allows passing of non-XML content without
>> >>>>> >> >> > forcing XML
>> >>>>> >> >> > and
>> >>>>> >> >> > that model performs perfectly fine and well (Synapse and
>> WSO2
>> >>>>> >> >> > ESB
>> >>>>> >> >> > both
>> >>>>> >> >> > leverage that heavily).
>> >>>>> >> >> >
>> >>>>> >> >> > Sanjiva.
>> >>>>> >> >> >
>> >>>>> >> >> >
>> >>>>> >> >> > On Fri, Dec 30, 2011 at 10:25 AM, Amila Suriarachchi
>> >>>>> >> >> > <amilasuriarachchi@gmail.com> wrote:
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >>>>> >> >> >> <andreas.veithen@gmail.com> wrote:
>> >>>>> >> >> >>>
>> >>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >>>>> >> >> >>> <amilasuriarachchi@gmail.com> wrote:
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >>>>> >> >> >>> > <andreas.veithen@gmail.com>
>> >>>>> >> >> >>> > wrote:
>> >>>>> >> >> >>> >>
>> >>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >>>>> >> >> >>> >> <shameerainfo@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-unsubscribe@axis.apache.org
>> >>>>> >> >> >>> >> For additional commands, e-mail:
>> >>>>> >> >> >>> >> java-dev-help@axis.apache.org
>> >>>>> >> >> >>> >>
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> > --
>> >>>>> >> >> >>> > Amila Suriarachchi
>> >>>>> >> >> >>> > WSO2 Inc.
>> >>>>> >> >> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>>>> >> >> >>>
>> >>>>> >> >> >>>
>> >>>>> >> >> >>>
>> >>>>> >> >> >>>
>> ---------------------------------------------------------------------
>> >>>>> >> >> >>> To unsubscribe, e-mail:
>> java-dev-unsubscribe@axis.apache.org
>> >>>>> >> >> >>> For additional commands, e-mail:
>> >>>>> >> >> >>> java-dev-help@axis.apache.org
>> >>>>> >> >> >>>
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >> --
>> >>>>> >> >> >> Amila Suriarachchi
>> >>>>> >> >> >> WSO2 Inc.
>> >>>>> >> >> >> blog: http://amilachinthaka.blogspot.com/
>> >>>>> >> >> >
>> >>>>> >> >> >
>> >>>>> >> >> >
>> >>>>> >> >> >
>> >>>>> >> >> > --
>> >>>>> >> >> > Sanjiva Weerawarana, Ph.D.
>> >>>>> >> >> > Founder, Director & Chief Scientist; Lanka Software
>> Foundation;
>> >>>>> >> >> > http://www.opensource.lk/
>> >>>>> >> >> > Founder, Chairman & CEO; WSO2; http://wso2.com/
>> >>>>> >> >> > Founder & Director; Thinkcube Systems;
>> >>>>> >> >> > http://www.thinkcube.com/
>> >>>>> >> >> > Member; Apache Software Foundation; http://www.apache.org/
>> >>>>> >> >> > Visiting Lecturer; University of Moratuwa;
>> >>>>> >> >> > http://www.cse.mrt.ac.lk/
>> >>>>> >> >> >
>> >>>>> >> >> > Blog: http://sanjiva.weerawarana.org/
>> >>>>> >> >> >
>> >>>>> >> >>
>> >>>>> >> >>
>> >>>>> >> >>
>> ---------------------------------------------------------------------
>> >>>>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>>> >> >> For additional commands, e-mail:
>> java-dev-help@axis.apache.org
>> >>>>> >> >>
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> > --
>> >>>>> >> > Sagara Gunathunga
>> >>>>> >> >
>> >>>>> >> > Blog      - http://ssagara.blogspot.com
>> >>>>> >> > Web      - http://people.apache.org/~sagara/
>> >>>>> >> > LinkedIn - http://www.linkedin.com/in/ssagara
>> >>>>> >>
>> >>>>> >>
>> >>>>> >>
>> ---------------------------------------------------------------------
>> >>>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>>> >>
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> > --
>> >>>>> > Shameera Rathnayaka
>> >>>>> > Undergraduate
>> >>>>> > Department of Computer Science and Engineering
>> >>>>> > University of Moratuwa.
>> >>>>> > Sri Lanka.
>> >>>>> >
>> >>>>> > Blog : http://shameerarathnayaka.blogspot.com/
>> >>>>> >
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Amila Suriarachchi
>> >>>> WSO2 Inc.
>> >>>> blog: http://amilachinthaka.blogspot.com/
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Shameera Rathnayaka
>> >>> Undergraduate
>> >>> Department of Computer Science and Engineering
>> >>> University of Moratuwa.
>> >>> Sri Lanka.
>> >>>
>> >>> Blog : http://shameerarathnayaka.blogspot.com/
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >
>> >
>> >
>> >
>> > --
>> > Shameera Rathnayaka
>> > Undergraduate
>> > Department of Computer Science and Engineering
>> > University of Moratuwa.
>> > Sri Lanka.
>> >
>> > Blog : http://shameerarathnayaka.blogspot.com/
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> > For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Blog      - http://ssagara.blogspot.com
>> Web      - http://people.apache.org/~sagara/
>> LinkedIn - http://www.linkedin.com/in/ssagara
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Shameera Rathnayaka
> Undergraduate
> Department of Computer Science and Engineering
> University of Moratuwa.
> Sri Lanka.
>
> Blog : http://shameerarathnayaka.blogspot.com/
>
>


-- 
Shameera Rathnayaka
Undergraduate
Department of Computer Science and Engineering
University of Moratuwa.
Sri Lanka.

Blog : http://shameerarathnayaka.blogspot.com/

Mime
View raw message