Hi,
What we mean by custom types in the context of MessageBuilders/formatters
is that different serializations of the XML infoset. One example would be
fast infoset. When supporting JSON we are using the existing XML--JSON
transformation standards (or rather agreements) and I beleive this
Thilina Gunarathne wrote:
Hi,
Hope I'm not too late to catch up...
In reply to Eran's questions about the fundaments,
Then the question comes as to what really Axis2 is. If we enable
plugging custom types, which are not compatible with SOAP or REST,
then
aren't we redefining what Axis2
On Sun, Sep 21, 2008 at 11:05 PM, Sanjiva Weerawarana [EMAIL PROTECTED]
wrote:
Sorry Chinthaka can't blame me ;-) .. no way that I told you WSDL 2.0 can
only deal with XML :).
Hehe, No no I was not blaming. Trying to get things clarified/confirmed from
Achilles :D
--
With Mettha,
Eran
Since our discussion is over on Faults and JSON messages, let's discuss one
of the good points raised by Dr. Sanjiva.
I think content negotiation is a cool feature to have, especially when we
are using HTTP. This is one of the features I personally definitely like to
have.
Are you guys thinking
Hi Chinthaka,
I did implement content-negotiation in Axis2 some time ago [1]. It was
implemented using the Accept header. It can be enabled by adding the
following parameter to the axis2.xml
parameter name=httpContentNegotiationtrue/parameter
Thanks,
Keith.
[1]
Ah excellent! So does the message formatter get selected based on the
accept headers sent (which refer to media types IIRC)? That's perfect.
Chinthaka, the idea of bringing content negotiation into SOAP is
interesting but IMO not that useful. While content neg is a favorite
RESTafarian
Keith, great piece of work. Is there a way to give preference to
content-types too, during the negotiation?
Ok let me tell one use case why I like content negotiations enabled for
conversations.
As we might know already, when we do performance analysis of Axis2, we send
large number of messages
Hi Chinthaka,
Currently it picks the first matching content-type in the accept header. If
for e.g the Accept header was Accept:
foo/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=
0.8,image/png,*/*;q=0.5 then the response would be application/xml
(Assuming that there was
Hi Chinthaka,
See comments inline,
On Sun, Sep 21, 2008 at 12:43 AM, Eran Chinthaka
[EMAIL PROTECTED]wrote:
Hi Keith and all,
This argument is based on the following assumption ( You know about
assumptions, if you've watched Under Siege 2 ;) )
Axis2 REST implementation is based on WSDL
On Sun, Sep 21, 2008 at 12:21 AM, Eran Chinthaka
[EMAIL PROTECTED]wrote:
Hi Keith,
This solution will solve the JSON problem (if we consider JSON messages as
REST, which I'll comment in a different email), but will not solve the more
general question IMO.
Agreed. It would be nice if we
and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
Date: Sun, 21 Sep 2008 19:31:42 +0530
From: [EMAIL PROTECTED]
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Should JSON
not necessarily endorse content contained within this
transmission.
--
Date: Sun, 21 Sep 2008 19:31:42 +0530
From: [EMAIL PROTECTED]
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Should JSON messages be considered as REST?
Hi Chinthaka,
See comments inline
intended recipient. Sender does
not necessarily endorse content contained within this transmission.
Date: Sun, 21 Sep 2008 22:42:43 +0530
From: [EMAIL PROTECTED]
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Should JSON messages be considered as REST?
I'm not too familiar with YAML. For what
In the spec, it says, if we have our own custom content-type, then it
should be compatible with application/xml (
http://www.w3.org/TR/wsdl20-adjuncts/#_http_ser_xml).
I don't think that thats the case. The WSDL 2.0 spec specifies three
serializations, they are
With current MessageBuilders/MessageFormatters they build/format requests
based on content-type. I'm not too familiar with the fault message flow in
Axis2 (Will have a look on that and get back) But why arn't we allowing the
corresponding builder/formatter to format faults too?
Exactly.
Sorry Chinthaka can't blame me ;-) .. no way that I told you WSDL 2.0
can only deal with XML :).
Sanjiva.
Eran Chinthaka wrote:
In the spec, it says, if we have our own custom
content-type, then it should be compatible with application/xml
I think the whole question of "REST" is not the point here.
Axis2's underlying data model is a SOAP Infoset. As a result, any type
of data that runs thru the system has to be represented as a SOAP
Infoset. That's not a big deal - essentially it means we need to create
two extra Axiom nodes
On Mon, Sep 22, 2008 at 9:00 AM, Sanjiva Weerawarana
[EMAIL PROTECTED]wrote:
I think the whole question of REST is not the point here.
Axis2's underlying data model is a SOAP Infoset. As a result, any type of
data that runs thru the system has to be represented as a SOAP Infoset.
That's not
Hi,
Hope I'm not too late to catch up...
In reply to Eran's questions about the fundaments,
Then the question comes as to what really Axis2 is. If we enable plugging
custom types, which are not compatible with SOAP or REST, then aren't we
redefining what Axis2 is? Do we wanna make it something
Hi Keith,
This solution will solve the JSON problem (if we consider JSON messages as
REST, which I'll comment in a different email), but will not solve the more
general question IMO.
We have enabled to plug custom content types, and do we wanna restrict these
custom types to always be either
Hi Keith and all,
This argument is based on the following assumption ( You know about
assumptions, if you've watched Under Siege 2 ;) )
Axis2 REST implementation is based on WSDL 2.0 HTTP Binding. At least this
was the case, when I was implementing and sorry if the implementation is now
changed.
+1 .. but I'm a bit confused. I assume by "REST" you meant that the
response has media type text/xml instead of application/soap+xml, right?
If we think about it that way, can we get rid of the "isDoingREST"
flag??
(I've hated that from day 1 and haven't had a chance to really dig thru
it
Let me describe the problem in more detail. As of now Axis2 enables you to
plug in various message types by registering them in the axis2.xml. Some of
these message types will be SOAP based (like text/xml and
application/soap+xml) while others are not. And in the latter case when a
exception
Any input on this would be appreciated.
Thanks,
Keith.
On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED]wrote:
Hi devs,
This idea came up because of the following scenario.
Currently the logic for creating a AxisFault for a fault received lies in
On Thu, Sep 4, 2008 at 4:10 AM, keith chapman [EMAIL PROTECTED] wrote:
Hi devs,
...
When the fault message is JSON its neither SOAP and the
messageContext.isDoingREST() returns false. Should we consider JSON
messages as REST messages? I believe so.
WDYT?
I agree.
David
Hi devs,
This idea came up because of the following scenario.
Currently the logic for creating a AxisFault for a fault received lies in
org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly
when the received fault is SOAP or REST. But it does not work as expected
when the
26 matches
Mail list logo
