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 Tue, 24 Apr 2012 06:19:06 GMT
Hi Amila, Sagara and Andreas,

Thank you all for leading me to submit a better proposal for this project.
As GSoC has started now, looking forward to finish my project as a success
in this summer.
I will update the progress of the project here in future too.

Thanks!
Shameera

On Sat, Mar 24, 2012 at 7:42 PM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

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


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

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

Mime
View raw message