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
<shameerai...@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
> <amilasuriarach...@gmail.com> wrote:
>>
>>
>>
>> On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka
>> <shameerai...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi
>>> <amilasuriarach...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen
>>>> <andreas.veit...@gmail.com> wrote:
>>>>>
>>>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>>>>> <shameerai...@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.veit...@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> I think that it would also be interesting to add another task in the
>>>>> >> scope of that GSOC project, namely to analyze why Axis2 doesn't have
>>>>> >> a
>>>>> >> good support for mapped JSON. In fact, if you look at Shameera's
>>>>> >> initial post, he (she?)
>>>>> >
>>>>> > It's he :)
>>>>> >
>>>>> >
>>>>> > Thanks
>>>>> > Shameera
>>>>> >
>>>>> >>
>>>>> >> takes the fact that "Mapped formatted JSON
>>>>> >> with namespaces are not supported in Axis2" as a basic assumption.
>>>>> >> The
>>>>> >> interesting question is actually why this is so. I was thinking
>>>>> >> about
>>>>> >> this a couple of months ago, and I believe that this is actually due
>>>>> >> to a too restrictive assumption that is made in the Axis2
>>>>> >> architecture
>>>>> >> (which is that it is possible to construct a SOAP infoset solely
>>>>> >> based
>>>>> >> on the properties of the incoming message, i.e. the content of the
>>>>> >> message and its content type), and that this is connected to some
>>>>> >> other problems as well as the presence of code in Axis2 that doesn't
>>>>> >> fit naturally into the architecture.
>>>>> >>
>>>>> >> Fixing that properly would probably be out of scope for a GSOC
>>>>> >> project, but doing an analysis would be highly interesting, in
>>>>> >> particular if Shameera is interested not only in development, but
>>>>> >> also
>>>>> >> in architecture and design.
>>>>> >>
>>>>> >> I think that if one includes these different things into the
>>>>> >> proposal,
>>>>> >> it would indeed make a very interesting GSOC project. Can we agree
>>>>> >> on
>>>>> >> that?
>>>>> >>
>>>>> >> Andreas
>>>>> >>
>>>>> >> On Wed, Jan 4, 2012 at 13:54, Sagara Gunathunga
>>>>> >> <sagara.gunathu...@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.veit...@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
>>>>> >> >> <sanj...@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
>>>>> >> >> > <amilasuriarach...@gmail.com> wrote:
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>>>> >> >> >> <andreas.veit...@gmail.com> wrote:
>>>>> >> >> >>>
>>>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>>>> >> >> >>> <amilasuriarach...@gmail.com> wrote:
>>>>> >> >> >>> >
>>>>> >> >> >>> >
>>>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>>>> >> >> >>> > <andreas.veit...@gmail.com>
>>>>> >> >> >>> > wrote:
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>>>> >> >> >>> >> <shameerai...@gmail.com> wrote:
>>>>> >> >> >>> >> > 2. store json string without doing any process untill it
>>>>> >> >> >>> >> > reaches
>>>>> >> >> >>> >> > JsonMessageReceiver. JsonMessageReceiver is a new
>>>>> >> >> >>> >> > Message
>>>>> >> >> >>> >> > Receiver
>>>>> >> >> >>> >> > which
>>>>> >> >> >>> >> > use
>>>>> >> >> >>> >> > gson to convert json to java objects, call relevant
>>>>> >> >> >>> >> > operation
>>>>> >> >> >>> >> > and
>>>>> >> >> >>> >> > get
>>>>> >> >> >>> >> > result.
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> What this means in practice is that you will have a
>>>>> >> >> >>> >> message
>>>>> >> >> >>> >> builder, a
>>>>> >> >> >>> >> message receiver and a message formatter that interact
>>>>> >> >> >>> >> with each
>>>>> >> >> >>> >> other, but that have no meaningful interaction with any
>>>>> >> >> >>> >> other
>>>>> >> >> >>> >> component of the Axis2 framework (the fundamental reason
>>>>> >> >> >>> >> being
>>>>> >> >> >>> >> that
>>>>> >> >> >>> >> google-gson defines a mapping between JSON and Java
>>>>> >> >> >>> >> objects, but
>>>>> >> >> >>> >> eliminates XML from the picture). The question is then why
>>>>> >> >> >>> >> would
>>>>> >> >> >>> >> a
>>>>> >> >> >>> >> user go through all the pain of setting up Axis2 for this?
>>>>> >> >> >>> >
>>>>> >> >> >>> >
>>>>> >> >> >>> > if you look into a point where users only need to expose a
>>>>> >> >> >>> > POJO
>>>>> >> >> >>> > with
>>>>> >> >> >>> > json
>>>>> >> >> >>> > then they don't have to use Axis2.
>>>>> >> >> >>> >
>>>>> >> >> >>> > But if the user want to expose the same POJO service both
>>>>> >> >> >>> > soap
>>>>> >> >> >>> > and
>>>>> >> >> >>> > json
>>>>> >> >> >>> > formats this provides a value in terms of performance for
>>>>> >> >> >>> > latter
>>>>> >> >> >>> > case.
>>>>> >> >> >>> > In
>>>>> >> >> >>> > this case JSON message receiver can be written extending
>>>>> >> >> >>> > RPC
>>>>> >> >> >>> > message
>>>>> >> >> >>> > receiver and call the normal RPC processing if the received
>>>>> >> >> >>> > message
>>>>> >> >> >>> > is
>>>>> >> >> >>> > not a
>>>>> >> >> >>> > json one.
>>>>> >> >> >>> >
>>>>> >> >> >>> > thanks,
>>>>> >> >> >>> > Amila.
>>>>> >> >> >>>
>>>>> >> >> >>> As you know, Axis2 assumes that every message it processes is
>>>>> >> >> >>> representable as XML (which is different from CXF where a
>>>>> >> >> >>> message
>>>>> >> >> >>> can
>>>>> >> >> >>> have different representations, depending on the phase that
>>>>> >> >> >>> is
>>>>> >> >> >>> executed). Until now this has always been the case, even for
>>>>> >> >> >>> plain
>>>>> >> >> >>> text and unstructured binary data. Are you going to drop that
>>>>> >> >> >>> requirement from the Axis2 architecture
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> Drop that requirement ( I would say initially Axis2 is
>>>>> >> >> >> designed like
>>>>> >> >> >> that
>>>>> >> >> >> but latter specially in all contract first approaches it has
>>>>> >> >> >> not
>>>>> >> >> >> followed
>>>>> >> >> >> this for performance reasons) and make an efficient way to
>>>>> >> >> >> work
>>>>> >> >> >> with
>>>>> >> >> >> JSON.
>>>>> >> >> >> Then obviously this won't support WS-Security etc .. which are
>>>>> >> >> >> anyway
>>>>> >> >> >> meaningless for json.
>>>>> >> >> >>
>>>>> >> >> >> If you look at how ADB works for non security (or non message
>>>>> >> >> >> building
>>>>> >> >> >> case) is similar to this. It stores the xml stream in the
>>>>> >> >> >> Axiom
>>>>> >> >> >> object
>>>>> >> >> >> (this
>>>>> >> >> >> feature has come from axiom differed building) and get that
>>>>> >> >> >> underline
>>>>> >> >> >> stream
>>>>> >> >> >> at the message receiver and directly build the java objects
>>>>> >> >> >> from
>>>>> >> >> >> that.
>>>>> >> >> >> Then
>>>>> >> >> >> at the response also it save the response in OMDatasource and
>>>>> >> >> >> directly
>>>>> >> >> >> serialize to the xml stream at the formatter.
>>>>> >> >> >>
>>>>> >> >> >> So idea for this is to provide such a direct stream parsing
>>>>> >> >> >> serializing
>>>>> >> >> >> technique which performs well for POJO objects to communicate
>>>>> >> >> >> using
>>>>> >> >> >> json.
>>>>> >> >> >>
>>>>> >> >> >> thanks,
>>>>> >> >> >> Amila.
>>>>> >> >> >>
>>>>> >> >> >>>
>>>>> >> >> >>> or else, what would be the XML
>>>>> >> >> >>> representation of a JSON message received by that message
>>>>> >> >> >>> receiver?
>>>>> >> >> >>>
>>>>> >> >> >>> >
>>>>> >> >> >>> >>
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> Andreas
>>>>> >> >> >>> >>
>>>>> >> >> >>> >>
>>>>> >> >> >>> >>
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> ---------------------------------------------------------------------
>>>>> >> >> >>> >> To unsubscribe, e-mail:
>>>>> >> >> >>> >> java-dev-unsubscr...@axis.apache.org
>>>>> >> >> >>> >> For additional commands, e-mail:
>>>>> >> >> >>> >> java-dev-h...@axis.apache.org
>>>>> >> >> >>> >>
>>>>> >> >> >>> >
>>>>> >> >> >>> >
>>>>> >> >> >>> >
>>>>> >> >> >>> > --
>>>>> >> >> >>> > Amila Suriarachchi
>>>>> >> >> >>> > WSO2 Inc.
>>>>> >> >> >>> > blog: http://amilachinthaka.blogspot.com/
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>> ---------------------------------------------------------------------
>>>>> >> >> >>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
>>>>> >> >> >>> For additional commands, e-mail:
>>>>> >> >> >>> java-dev-h...@axis.apache.org
>>>>> >> >> >>>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> --
>>>>> >> >> >> Amila Suriarachchi
>>>>> >> >> >> WSO2 Inc.
>>>>> >> >> >> blog: http://amilachinthaka.blogspot.com/
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > --
>>>>> >> >> > 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-unsubscr...@axis.apache.org
>>>>> >> >> For additional commands, e-mail: java-dev-h...@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-unsubscr...@axis.apache.org
>>>>> >> For additional commands, e-mail: java-dev-h...@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-unsubscr...@axis.apache.org
>>>>> For additional commands, e-mail: java-dev-h...@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-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-dev-h...@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-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
