Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

Hi devs,

I hope to select an axis2 related project to do in 2012 GSOC. Therefore i
did some basic research about Axis2 and found that Current Json support in
Axis2 can be improved using a rich library such as google-gson to use
normal JSON object to communicate with java services without converting it
to Badgerfish.

Here is my proposal in brief.

There are two ways that xml string can be converted into JSON string,
Badgerfish and Mapped . Current Axis2 with JSON module completely supports
Badgerfish convention[1] while partialy supports Mapped convention[1] as
Mapped formatted JSON with namespaces are not supported in Axis2. Therefore
if the client side java-script code needs to talk with java service which
is deployed in Axis2, it should be sent as Badgerfish convention. It is
cumbersome to generate Badgerfish convention of JSON string again and again
to call services if there is no  xml representation string in client side.

If java script client can send JSON object to relevant java service in
Axis2, defining service and operation in request url, without doing any
modifications to JSON objects, then it would be very helpful for
Java-Script users at client side.

Here i propose a solution to implement this with some limitations by
using google-gson
[2] <http://code.google.com/p/google-gson/> library which is a rich library
to convert JSON string to Java object and vice-versa and also it is
released under Apache license. Using this library we can improve JSON
support in Axis2 to overcome above problem. Following are some advantages
of using gson to convert JSON to Java object and vice-versa.

   - Provide simple toJson() and fromJson() methods to convert Java objects
   to JSON and vice-versa
   - Allow pre-existing unmodifiable objects to be converted to and from
   JSON
   - Extensive support of Java Generics
   - Allow custom representations for objects
   - Support arbitrarily complex objects (with deep inheritance hierarchies
   and extensive use of generic types)

As i mentioned there are several limitations because we are not using
namespace mapping. As an example if wsdl has two methods with same name but
different namespace then this method will fail,But there are ways we can
find a solution to fix this to some extent.

Also i have some basic idea about how to implement this improvement, as
follows. Here i have assumed that service name and operation name can be
read from request URL. Then incoming message can be dispatched to correct
operation.


1. write a jsonMessagebuilder to read incoming json string under specific
content type.

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.


3. write a jsonMessageFormatter to write output stream according to content
type.


I would like to know that whether this is a good idea and will it be
allright to do this as GSOC project.

[1]http://wso2.org/library/768 <http://wso2.org/library/768>
[2]http://code.google.com/p/google-gson/<http://code.google.com/p/google-gson/>

Thanks
Shameera.

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

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

Re: Improve Json support with Axis2 using google-gson java library

[shivendra tripathi <sh...@gmail.com>]

+1

On Wed, Dec 28, 2011 at 1:11 PM, Shameera Rathnayaka <shameerainfo@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
>> <sh...@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?
>>
>
> According to the user perspective, if user has a xml representation
> of json object then user can convert it to json with Badgerfish convetion
> and send it to Axis2. But if user doesn't have such xml representation then
> he needs to generate Badgerfish convention of Json object. If Axis2 support
> normal json object then it would be easy to users to communicate without
> using Badgerfish convention.
>
> And there is no point of converting json to xml in middle as both are used
> for same purpose. and also Json is
> a light-weighted data exchangeable format so it would be great if axis2
> supports fully Json too as it support xml.
>
> JSON string is processed inside the JsonMessageReceiver. All dispatching
> things happen url based. Therefore Axis2 engine can identify service ,
> operation etc.. without processing incoming json string.
>
>
>
>>
>> Andreas
>>
>> ---------------------------------------------------------------------
>> 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/
>
>

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> <sh...@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?
>

According to the user perspective, if user has a xml representation of json
object then user can convert it to json with Badgerfish convetion and send
it to Axis2. But if user doesn't have such xml representation then he needs
to generate Badgerfish convention of Json object. If Axis2 support normal
json object then it would be easy to users to communicate without using
Badgerfish convention.

And there is no point of converting json to xml in middle as both are used
for same purpose. and also Json is
a light-weighted data exchangeable format so it would be great if axis2
supports fully Json too as it support xml.

JSON string is processed inside the JsonMessageReceiver. All dispatching
things happen url based. Therefore Axis2 engine can identify service ,
operation etc.. without processing incoming json string.



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

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

On Thu, Dec 29, 2011 at 8:25 PM, 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
>> <sh...@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.
>

Understood clearly i was thinking these too.


>
> 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.
>
+1 , Actually this would be very comfortable for users according to their
point of view.



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

got it.

Thanks
Shameera


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

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

Re: Improve Json support with Axis2 using google-gson java library

[Sagara Gunathunga <sa...@gmail.com>]

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
>> <am...@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
>> >> <sh...@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.
>

  +1

 Thanks !


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



-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Jan 10, 2012 at 10:55 PM, Shameera Rathnayaka <
shameerainfo@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
>> <sh...@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.
>>
>> 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.
>>
>
> I would like to start some backgroung  implementation for this project,
> while waiting for the start of gsoc.
> I appreciate if you can guide me to start this project with good starting
> point.
> As i think there are lot of background search is needed for make this
> improvement.
> As a first step I gathered some background knowledge of streaming and
> google-gson.
> i think it will help me lot in this project.
>

One of the starting point to familiarize the google-gson would be try to
implement a method like this,

invoke (inputStream, OutputStream)

Here you can use a file input stream to send the json stream, which is read
by the method implementation and write to the Output stream again it can be
a file out put stream.

Within the method you need to develop the code to parse the inputstream
invoke the service object and stream back the response.

Then you can think of how to get the real input stream from the http
request and write to the output stream.


>
> should i go through synapse plain text sample code or ...?  At the moment
> i haven't any experience with Synapse.
>

Basically you need to look at how axis2 message builders and formatters use.

thanks,
Amila.

>
>
>
>>
>> >  <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.
>>
>>
> Clearly undarstood, What if we use request uri to identify the service
> inside the message builder (in this case request uri should have service
> and operation names in its query string) and as you mentioned above we can
> use service parameter for mapping.
>
>
>> >
>> > 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
>> >> <sa...@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
>> >> > <an...@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
>> >> >> <sa...@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
>> >> >> > <am...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >> >> >> <an...@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >> >> >>> <am...@gmail.com> wrote:
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >> >> >>> > <an...@gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >> >> >>> >> <sh...@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
>>
>>
>
>
> --
> 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/

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
> <sh...@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.
>
> 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.
>

I would like to start some backgroung  implementation for this project,
while waiting for the start of gsoc.
I appreciate if you can guide me to start this project with good starting
point.
As i think there are lot of background search is needed for make this
improvement.
As a first step I gathered some background knowledge of streaming and
google-gson.
i think it will help me lot in this project.

should i go through synapse plain text sample code or ...?  At the moment i
haven't any experience with Synapse.



>
> >  <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.
>
>
Clearly undarstood, What if we use request uri to identify the service
inside the message builder (in this case request uri should have service
and operation names in its query string) and as you mentioned above we can
use service parameter for mapping.


> >
> > 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
> >> <sa...@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
> >> > <an...@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
> >> >> <sa...@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
> >> >> > <am...@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> >> <an...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >> >>> <am...@gmail.com> wrote:
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >> >>> > <an...@gmail.com>
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >> >>> >> <sh...@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
>
>


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

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

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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
>>> <sh...@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
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
>>> >> <sh...@gmail.com> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
>>> >>>> <an...@gmail.com> wrote:
>>> >>>>>
>>> >>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>>> >>>>> <sh...@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
>>> >>>>> > <an...@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
>>> >>>>> >> <sa...@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
>>> >>>>> >> > <an...@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
>>> >>>>> >> >> <sa...@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
>>> >>>>> >> >> > <am...@gmail.com> wrote:
>>> >>>>> >> >> >>
>>> >>>>> >> >> >>
>>> >>>>> >> >> >>
>>> >>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>> >>>>> >> >> >> <an...@gmail.com> wrote:
>>> >>>>> >> >> >>>
>>> >>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>> >>>>> >> >> >>> <am...@gmail.com> wrote:
>>> >>>>> >> >> >>> >
>>> >>>>> >> >> >>> >
>>> >>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>> >>>>> >> >> >>> > <an...@gmail.com>
>>> >>>>> >> >> >>> > wrote:
>>> >>>>> >> >> >>> >>
>>> >>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>> >>>>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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
>> <sh...@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
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
>> >> <sh...@gmail.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
>> >>>> <an...@gmail.com> wrote:
>> >>>>>
>> >>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>> >>>>> <sh...@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
>> >>>>> > <an...@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
>> >>>>> >> <sa...@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
>> >>>>> >> > <an...@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
>> >>>>> >> >> <sa...@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
>> >>>>> >> >> > <am...@gmail.com> wrote:
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >>
>> >>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >>>>> >> >> >> <an...@gmail.com> wrote:
>> >>>>> >> >> >>>
>> >>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >>>>> >> >> >>> <am...@gmail.com> wrote:
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> >
>> >>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >>>>> >> >> >>> > <an...@gmail.com>
>> >>>>> >> >> >>> > wrote:
>> >>>>> >> >> >>> >>
>> >>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >>>>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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
> <sh...@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
> > <am...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
> >> <sh...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
> >>>> <an...@gmail.com> wrote:
> >>>>>
> >>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
> >>>>> <sh...@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
> >>>>> > <an...@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
> >>>>> >> <sa...@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
> >>>>> >> > <an...@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
> >>>>> >> >> <sa...@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
> >>>>> >> >> > <am...@gmail.com> wrote:
> >>>>> >> >> >>
> >>>>> >> >> >>
> >>>>> >> >> >>
> >>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >>>>> >> >> >> <an...@gmail.com> wrote:
> >>>>> >> >> >>>
> >>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >>>>> >> >> >>> <am...@gmail.com> wrote:
> >>>>> >> >> >>> >
> >>>>> >> >> >>> >
> >>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >>>>> >> >> >>> > <an...@gmail.com>
> >>>>> >> >> >>> > wrote:
> >>>>> >> >> >>> >>
> >>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >>>>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Sagara Gunathunga <sa...@gmail.com>]

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.

Thanks !

On Sat, Mar 3, 2012 at 2:55 PM, Shameera Rathnayaka
<sh...@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
> <am...@gmail.com> wrote:
>>
>>
>>
>> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
>> <sh...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
>>>> <an...@gmail.com> wrote:
>>>>>
>>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>>>>> <sh...@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
>>>>> > <an...@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
>>>>> >> <sa...@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
>>>>> >> > <an...@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
>>>>> >> >> <sa...@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
>>>>> >> >> > <am...@gmail.com> wrote:
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>>>> >> >> >> <an...@gmail.com> wrote:
>>>>> >> >> >>>
>>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>>>> >> >> >>> <am...@gmail.com> wrote:
>>>>> >> >> >>> >
>>>>> >> >> >>> >
>>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>>>> >> >> >>> > <an...@gmail.com>
>>>>> >> >> >>> > wrote:
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>>>> >> >> >>> >> <sh...@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

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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
>>>> <sh...@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
>>>> >> <sa...@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
>>>> >> > <an...@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
>>>> >> >> <sa...@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
>>>> >> >> > <am...@gmail.com> wrote:
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>>> >> >> >> <an...@gmail.com> wrote:
>>>> >> >> >>>
>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>>> >> >> >>> <am...@gmail.com> wrote:
>>>> >> >> >>> >
>>>> >> >> >>> >
>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>>> >> >> >>> > <an...@gmail.com>
>>>> >> >> >>> > wrote:
>>>> >> >> >>> >>
>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

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
>>> <sh...@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
>>> >> <sa...@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
>>> >> > <an...@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
>>> >> >> <sa...@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
>>> >> >> > <am...@gmail.com> wrote:
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>> >> >> >> <an...@gmail.com> wrote:
>>> >> >> >>>
>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>> >> >> >>> <am...@gmail.com> wrote:
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>> >> >> >>> > <an...@gmail.com>
>>> >> >> >>> > wrote:
>>> >> >> >>> >>
>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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
>> <sh...@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 ? 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
>> >> <sa...@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
>> >> > <an...@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
>> >> >> <sa...@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
>> >> >> > <am...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >> >> >> <an...@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >> >> >>> <am...@gmail.com> wrote:
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >> >> >>> > <an...@gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
> <sh...@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.

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
> >> <sa...@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
> >> > <an...@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
> >> >> <sa...@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
> >> >> > <am...@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> >> <an...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >> >>> <am...@gmail.com> wrote:
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >> >>> > <an...@gmail.com>
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
<sh...@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.

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 <an...@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
>> <sa...@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
>> > <an...@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
>> >> <sa...@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
>> >> > <am...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >> >> <an...@gmail.com> wrote:
>> >> >>>
>> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >> >>> <am...@gmail.com> wrote:
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >> >>> > <an...@gmail.com>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >> >>> >> <sh...@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

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

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

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

On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
<an...@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
> <sa...@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
> >> > <am...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> <an...@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >>> <am...@gmail.com> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >>> > <an...@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Sagara Gunathunga <sa...@gmail.com>]

On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
<an...@gmail.com>wrote:

> I think it is useful to summarize a bit the discussion at this point.
>
> We have identified two approaches to address the SOAP infoset vs. JSON
> question:
>
> 1. As Amila suggests in his last post, put a dummy SOAP envelope in
> the message context and store the JSON message (actually a stream
> representing that message) in a message context property. This is
> technically simple, but it is not an innocent choice because it
> deviates from what we do elsewhere in Axis2. Therefore this requires
> some careful thinking about the implications of such a choice.
>
> 2. Preserve the requirement that a message must have a well defined
> SOAP infoset and use a trivial representation similar (or identical)
> to what we use for plain text. This has the advantage that it is more
> in line with the rest of the Axis2 architecture, but requires a
> careful analysis (and potentially some enhancements in Axiom or Axis2)
> to make sure that we can implement streaming. It should be noted that
> this has applications that are important in a context much broader
> than JSON. In particular, the ability to stream character data
> efficiently is important for Synapse as well.
>
> So, one of the tasks of the proposed GSOC project would be to analyze
> and evaluate both approaches, so that we can make an educated choice.
>
> 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?) 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?
>

  +1

  BTW one interesting question remains is how to dispatch JSON messages
specially in non-http transports ? current approach converts JSON into XML
hence this is not a problem. One solution can be use JSON wrapper element
and use gson.stream.JsonReader to read only that wrapper element before
dispatching and construct SOAP infoset up to that level. I think above
point 2.) is related to this.   Is there any good solution for this ?

Thanks !


>
> Andreas
>
> On Wed, Jan 4, 2012 at 13:54, Sagara Gunathunga
> <sa...@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
> >> > <am...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> <an...@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >>> <am...@gmail.com> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >>> > <an...@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >>> >> <sh...@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
>
>


-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
<an...@gmail.com>wrote:

> I think it is useful to summarize a bit the discussion at this point.
>
> We have identified two approaches to address the SOAP infoset vs. JSON
> question:
>
> 1. As Amila suggests in his last post, put a dummy SOAP envelope in
> the message context and store the JSON message (actually a stream
> representing that message) in a message context property. This is
> technically simple, but it is not an innocent choice because it
> deviates from what we do elsewhere in Axis2. Therefore this requires
> some careful thinking about the implications of such a choice.
>
> 2. Preserve the requirement that a message must have a well defined
> SOAP infoset and use a trivial representation similar (or identical)
> to what we use for plain text. This has the advantage that it is more
> in line with the rest of the Axis2 architecture, but requires a
> careful analysis (and potentially some enhancements in Axiom or Axis2)
> to make sure that we can implement streaming. It should be noted that
> this has applications that are important in a context much broader
> than JSON. In particular, the ability to stream character data
> efficiently is important for Synapse as well.
>
> So, one of the tasks of the proposed GSOC project would be to analyze
> and evaluate both approaches, so that we can make an educated choice.
>
> 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?) 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?
>

+1.

it is better to look at alternatives.

thanks,
Amila.


>
> Andreas
>
> On Wed, Jan 4, 2012 at 13:54, Sagara Gunathunga
> <sa...@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
> >> > <am...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> <an...@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >>> <am...@gmail.com> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >>> > <an...@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >>> >> <sh...@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
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
<an...@gmail.com>wrote:

> I think it is useful to summarize a bit the discussion at this point.
>
> We have identified two approaches to address the SOAP infoset vs. JSON
> question:
>
> 1. As Amila suggests in his last post, put a dummy SOAP envelope in
> the message context and store the JSON message (actually a stream
> representing that message) in a message context property. This is
> technically simple, but it is not an innocent choice because it
> deviates from what we do elsewhere in Axis2. Therefore this requires
> some careful thinking about the implications of such a choice.
>
> 2. Preserve the requirement that a message must have a well defined
> SOAP infoset and use a trivial representation similar (or identical)
> to what we use for plain text. This has the advantage that it is more
> in line with the rest of the Axis2 architecture, but requires a
> careful analysis (and potentially some enhancements in Axiom or Axis2)
> to make sure that we can implement streaming. It should be noted that
> this has applications that are important in a context much broader
> than JSON. In particular, the ability to stream character data
> efficiently is important for Synapse as well.
>
> So, one of the tasks of the proposed GSOC project would be to analyze
> and evaluate both approaches, so that we can make an educated choice.
>
> 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?) 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.
>

yes. This is specially true for json <-> XML conversion. This problem comes
when processing name spaces and serialising elements where it there is not
way to find whether an xml element is an first element of an array or one
element.

In order to solve this issue we try to use the XMLSchema as to get the
knowledge about xml message. This method may fit into this problem properly
compared to Badgerfish or Mapped types since they some what distort the
json message.

Currently Shameera is working on this approach and please see the relevant
mails on this list.

thanks,
Amila.

>
> 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
> <sa...@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
> >> > <am...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> >> <an...@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> >>> <am...@gmail.com> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> >>> > <an...@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >>> >> <sh...@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
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

I think it is useful to summarize a bit the discussion at this point.

We have identified two approaches to address the SOAP infoset vs. JSON question:

1. As Amila suggests in his last post, put a dummy SOAP envelope in
the message context and store the JSON message (actually a stream
representing that message) in a message context property. This is
technically simple, but it is not an innocent choice because it
deviates from what we do elsewhere in Axis2. Therefore this requires
some careful thinking about the implications of such a choice.

2. Preserve the requirement that a message must have a well defined
SOAP infoset and use a trivial representation similar (or identical)
to what we use for plain text. This has the advantage that it is more
in line with the rest of the Axis2 architecture, but requires a
careful analysis (and potentially some enhancements in Axiom or Axis2)
to make sure that we can implement streaming. It should be noted that
this has applications that are important in a context much broader
than JSON. In particular, the ability to stream character data
efficiently is important for Synapse as well.

So, one of the tasks of the proposed GSOC project would be to analyze
and evaluate both approaches, so that we can make an educated choice.

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?) 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
<sa...@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 <an...@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 <sa...@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
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >> <an...@gmail.com> wrote:
>> >>>
>> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >>> >> <sh...@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

Re: Improve Json support with Axis2 using google-gson java library

[Sagara Gunathunga <sa...@gmail.com>]

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
<an...@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 <sa...@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
> > <am...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> <an...@gmail.com> wrote:
> >>>
> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >>> >> <sh...@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

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jan 4, 2012 at 5:56 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

>
>
> 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.
>>
>
> I was also telling that a similar method like 2. Here I think even we
> don't have to think about the XML representation simply message builder can
> save the input stream as a message context property and set a dummy soap
> envelope. At the message receiver it can take the input stream and process.
> Then again save the out out java objects as message context property and
> use that at the formatter.
>
> I believe every one knows that Axis2 is designed only to process  SOAP
> messages. As I told earlier this is a drop of that requirement and making a
> way to process messages in a performance efficient manner.
>
>
>> 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.
>>
>
> That depends on how much work have to done at the MR implementation to
> handle different types of method signatures etc
>

I am not sure the amount of work to be done. But for an example jaxws
implementation uses jaxbri to marshal and unmarshal xml messages to java
objects. I think this is what geson provides for json messages. However
still some work has to be done in order to invoke the service classes
properly may be with some annotation support etc ...

thanks,
Amila.


> ..
>
> thanks,
> Amila.
>
>
>>
>> Andreas
>>
>> On Sun, Jan 1, 2012 at 16:25, Sanjiva Weerawarana <sa...@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
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> >> <an...@gmail.com> wrote:
>> >>>
>> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >>> >> <sh...@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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jan 4, 2012 at 4:27 PM, Andreas Veithen
<an...@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.
>

I was also telling that a similar method like 2. Here I think even we don't
have to think about the XML representation simply message builder can save
the input stream as a message context property and set a dummy soap
envelope. At the message receiver it can take the input stream and process.
Then again save the out out java objects as message context property and
use that at the formatter.

I believe every one knows that Axis2 is designed only to process  SOAP
messages. As I told earlier this is a drop of that requirement and making a
way to process messages in a performance efficient manner.


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

That depends on how much work have to done at the MR implementation to
handle different types of method signatures etc ..

thanks,
Amila.


>
> Andreas
>
> On Sun, Jan 1, 2012 at 16:25, Sanjiva Weerawarana <sa...@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
> > <am...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> >> <an...@gmail.com> wrote:
> >>>
> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >>> >> <sh...@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
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

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 <sa...@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
> <am...@gmail.com> wrote:
>>
>>
>>
>> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>> >> <sh...@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

Re: Improve Json support with Axis2 using google-gson java library

[Sanjiva Weerawarana <sa...@opensource.lk>]

+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
>> <am...@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
>> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jan 4, 2012 at 4:40 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Fri, Dec 30, 2011 at 05:55, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >>
> >> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> >> >> <sh...@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-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/
>
> ---------------------------------------------------------------------
> 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/

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

On Fri, Dec 30, 2011 at 05:55, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
> <an...@gmail.com> wrote:
>>
>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> >> <sh...@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-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/

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

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
> <am...@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
> >> <sh...@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/

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>> <sh...@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 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

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
> <sh...@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.



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

Re: Improve Json support with Axis2 using google-gson java library

[Andreas Veithen <an...@gmail.com>]

On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
<sh...@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?

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: Improve Json support with Axis2 using google-gson java library

[Shameera Rathnayaka <sh...@gmail.com>]

Thanks Amila and Sanjiva.

On Tue, Dec 27, 2011 at 9:13 AM, Sanjiva Weerawarana
<sa...@opensource.lk>wrote:

> +1 very nicely thought thru! You may also want to review how ADB
> serializes Java onto the wire without going to an in-memory XML form first
> .. you should be able to do something similar for JSON.
>

sure i will go through axis2 source code and relevant articles to
understand current scenario of ADB serialization. As i have basic idea of
how to do this improvement this will really help me to make a starting
point to do this project.

Thanks
Shameera



>
>
Sanjiva.
>
>
> On Mon, Dec 26, 2011 at 11:19 AM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>> looks good.
>>
>> thanks,
>> Amila.
>>
>>
>> On Sun, Dec 25, 2011 at 7:39 PM, Shameera Rathnayaka <
>> shameerainfo@gmail.com> wrote:
>>
>>> Hi devs,
>>>
>>> I hope to select an axis2 related project to do in 2012 GSOC. Therefore
>>> i did some basic research about Axis2 and found that Current Json support
>>> in Axis2 can be improved using a rich library such as google-gson to use
>>> normal JSON object to communicate with java services without converting it
>>> to Badgerfish.
>>>
>>> Here is my proposal in brief.
>>>
>>> There are two ways that xml string can be converted into JSON string,
>>> Badgerfish and Mapped . Current Axis2 with JSON module completely supports
>>> Badgerfish convention[1] while partialy supports Mapped convention[1] as
>>> Mapped formatted JSON with namespaces are not supported in Axis2. Therefore
>>> if the client side java-script code needs to talk with java service which
>>> is deployed in Axis2, it should be sent as Badgerfish convention. It is
>>> cumbersome to generate Badgerfish convention of JSON string again and again
>>> to call services if there is no  xml representation string in client side.
>>>
>>> If java script client can send JSON object to relevant java service in
>>> Axis2, defining service and operation in request url, without doing any
>>> modifications to JSON objects, then it would be very helpful for
>>> Java-Script users at client side.
>>>
>>> Here i propose a solution to implement this with some limitations by
>>> using google-gson [2] <http://code.google.com/p/google-gson/> library
>>> which is a rich library to convert JSON string to Java object and
>>> vice-versa and also it is released under Apache license. Using this library
>>> we can improve JSON support in Axis2 to overcome above problem. Following
>>> are some advantages of using gson to convert JSON to Java object and
>>> vice-versa.
>>>
>>>    - Provide simple toJson() and fromJson() methods to convert Java
>>>    objects to JSON and vice-versa
>>>    - Allow pre-existing unmodifiable objects to be converted to and
>>>    from JSON
>>>    - Extensive support of Java Generics
>>>    - Allow custom representations for objects
>>>    - Support arbitrarily complex objects (with deep inheritance
>>>    hierarchies and extensive use of generic types)
>>>
>>> As i mentioned there are several limitations because we are not using
>>> namespace mapping. As an example if wsdl has two methods with same name but
>>> different namespace then this method will fail,But there are ways we can
>>> find a solution to fix this to some extent.
>>>
>>> Also i have some basic idea about how to implement this improvement, as
>>> follows. Here i have assumed that service name and operation name can be
>>> read from request URL. Then incoming message can be dispatched to correct
>>> operation.
>>>
>>>
>>> 1. write a jsonMessagebuilder to read incoming json string under
>>> specific content type.
>>>
>>> 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.
>>>
>>>
>>> 3. write a jsonMessageFormatter to write output stream according to
>>> content type.
>>>
>>>
>>> I would like to know that whether this is a good idea and will it be
>>> allright to do this as GSOC project.
>>>
>>> [1]http://wso2.org/library/768 <http://wso2.org/library/768>
>>> [2]http://code.google.com/p/google-gson/<http://code.google.com/p/google-gson/>
>>>
>>> Thanks
>>> Shameera.
>>>
>>> --
>>> 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/
>>
>
>
>
> --
> 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/
>
>


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

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

Re: Improve Json support with Axis2 using google-gson java library

[Sanjiva Weerawarana <sa...@opensource.lk>]

+1 very nicely thought thru! You may also want to review how ADB serializes
Java onto the wire without going to an in-memory XML form first .. you
should be able to do something similar for JSON.

Sanjiva.

On Mon, Dec 26, 2011 at 11:19 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> looks good.
>
> thanks,
> Amila.
>
>
> On Sun, Dec 25, 2011 at 7:39 PM, Shameera Rathnayaka <
> shameerainfo@gmail.com> wrote:
>
>> Hi devs,
>>
>> I hope to select an axis2 related project to do in 2012 GSOC. Therefore i
>> did some basic research about Axis2 and found that Current Json support in
>> Axis2 can be improved using a rich library such as google-gson to use
>> normal JSON object to communicate with java services without converting it
>> to Badgerfish.
>>
>> Here is my proposal in brief.
>>
>> There are two ways that xml string can be converted into JSON string,
>> Badgerfish and Mapped . Current Axis2 with JSON module completely supports
>> Badgerfish convention[1] while partialy supports Mapped convention[1] as
>> Mapped formatted JSON with namespaces are not supported in Axis2. Therefore
>> if the client side java-script code needs to talk with java service which
>> is deployed in Axis2, it should be sent as Badgerfish convention. It is
>> cumbersome to generate Badgerfish convention of JSON string again and again
>> to call services if there is no  xml representation string in client side.
>>
>> If java script client can send JSON object to relevant java service in
>> Axis2, defining service and operation in request url, without doing any
>> modifications to JSON objects, then it would be very helpful for
>> Java-Script users at client side.
>>
>> Here i propose a solution to implement this with some limitations by
>> using google-gson [2] <http://code.google.com/p/google-gson/> library
>> which is a rich library to convert JSON string to Java object and
>> vice-versa and also it is released under Apache license. Using this library
>> we can improve JSON support in Axis2 to overcome above problem. Following
>> are some advantages of using gson to convert JSON to Java object and
>> vice-versa.
>>
>>    - Provide simple toJson() and fromJson() methods to convert Java
>>    objects to JSON and vice-versa
>>    - Allow pre-existing unmodifiable objects to be converted to and from
>>    JSON
>>    - Extensive support of Java Generics
>>    - Allow custom representations for objects
>>    - Support arbitrarily complex objects (with deep inheritance
>>    hierarchies and extensive use of generic types)
>>
>> As i mentioned there are several limitations because we are not using
>> namespace mapping. As an example if wsdl has two methods with same name but
>> different namespace then this method will fail,But there are ways we can
>> find a solution to fix this to some extent.
>>
>> Also i have some basic idea about how to implement this improvement, as
>> follows. Here i have assumed that service name and operation name can be
>> read from request URL. Then incoming message can be dispatched to correct
>> operation.
>>
>>
>> 1. write a jsonMessagebuilder to read incoming json string under specific
>> content type.
>>
>> 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.
>>
>>
>> 3. write a jsonMessageFormatter to write output stream according to
>> content type.
>>
>>
>> I would like to know that whether this is a good idea and will it be
>> allright to do this as GSOC project.
>>
>> [1]http://wso2.org/library/768 <http://wso2.org/library/768>
>> [2]http://code.google.com/p/google-gson/<http://code.google.com/p/google-gson/>
>>
>> Thanks
>> Shameera.
>>
>> --
>> 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/
>



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

AXIS2 matching requests with responses

[Nadir Amra <am...@us.ibm.com>]

I have a logger module and I was wondering if there is a way to match the 
SOAP request coming in with the corresponding SOAP response?

That is, is there some sort of identifier that indicates whether a 
response is associated with a request?

I tried org.apache.axis2.context.MessageContext method getLogCorrelationID
() but that is always unique - the request message context ID always 
differs from the response message context ID. 



Nadir Amra

Re: Improve Json support with Axis2 using google-gson java library

[Amila Suriarachchi <am...@gmail.com>]

looks good.

thanks,
Amila.

On Sun, Dec 25, 2011 at 7:39 PM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

> Hi devs,
>
> I hope to select an axis2 related project to do in 2012 GSOC. Therefore i
> did some basic research about Axis2 and found that Current Json support in
> Axis2 can be improved using a rich library such as google-gson to use
> normal JSON object to communicate with java services without converting it
> to Badgerfish.
>
> Here is my proposal in brief.
>
> There are two ways that xml string can be converted into JSON string,
> Badgerfish and Mapped . Current Axis2 with JSON module completely supports
> Badgerfish convention[1] while partialy supports Mapped convention[1] as
> Mapped formatted JSON with namespaces are not supported in Axis2. Therefore
> if the client side java-script code needs to talk with java service which
> is deployed in Axis2, it should be sent as Badgerfish convention. It is
> cumbersome to generate Badgerfish convention of JSON string again and again
> to call services if there is no  xml representation string in client side.
>
> If java script client can send JSON object to relevant java service in
> Axis2, defining service and operation in request url, without doing any
> modifications to JSON objects, then it would be very helpful for
> Java-Script users at client side.
>
> Here i propose a solution to implement this with some limitations by using google-gson
> [2] <http://code.google.com/p/google-gson/> library which is a rich
> library to convert JSON string to Java object and vice-versa and also it is
> released under Apache license. Using this library we can improve JSON
> support in Axis2 to overcome above problem. Following are some advantages
> of using gson to convert JSON to Java object and vice-versa.
>
>    - Provide simple toJson() and fromJson() methods to convert Java
>    objects to JSON and vice-versa
>    - Allow pre-existing unmodifiable objects to be converted to and from
>    JSON
>    - Extensive support of Java Generics
>    - Allow custom representations for objects
>    - Support arbitrarily complex objects (with deep inheritance
>    hierarchies and extensive use of generic types)
>
> As i mentioned there are several limitations because we are not using
> namespace mapping. As an example if wsdl has two methods with same name but
> different namespace then this method will fail,But there are ways we can
> find a solution to fix this to some extent.
>
> Also i have some basic idea about how to implement this improvement, as
> follows. Here i have assumed that service name and operation name can be
> read from request URL. Then incoming message can be dispatched to correct
> operation.
>
>
> 1. write a jsonMessagebuilder to read incoming json string under specific
> content type.
>
> 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.
>
>
> 3. write a jsonMessageFormatter to write output stream according to
> content type.
>
>
> I would like to know that whether this is a good idea and will it be
> allright to do this as GSOC project.
>
> [1]http://wso2.org/library/768 <http://wso2.org/library/768>
> [2]http://code.google.com/p/google-gson/<http://code.google.com/p/google-gson/>
>
> Thanks
> Shameera.
>
> --
> 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/