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
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
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 t
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 feature
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
true
Thanks,
Keith.
[1] http://markmail.org/message/mbnxc2ysq2bt7v6a
On Mon, Sep 22, 2008 at 8:53 PM, E
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 o
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
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
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 w
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.
> Th
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 (a
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 (http://www.w3.o
> 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.
> 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
> application/x-www
ion is of a confidential nature 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 22:42:43 +0530
From: [EMAIL PROTECTED]
To: axis-dev@ws.apache.org
Subject: Re
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]
messages be considered as REST?
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&qu
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
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 o
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
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 REST
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 occurs
+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 an
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
--
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
> org.apache.axis2.uti
25 matches
Mail list logo
