Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (athena.apache.org: domain of lp.bilo@gmail.com designates
 209.85.217.19 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=JQ3DXx77Ev8upHr+HtcsrBJArH4kpZqYZdmCxMV4wfgknNebz8Uu3Fd/jGFEKj+/wR
         y0cds/gTJVRVjYldkoQAYW92ABmIigvkTdbiGcWTqen0uCu2OFezUWLBrqyeQbU1hm4K
         HLU2UEpFeN2vTivxViTlpVnyD2lSV472Jlzvs=
Message-ID: <aede9f250810280639l74b3f667v654fe52535c5caec@mail.gmail.com>
Date: Tue, 28 Oct 2008 13:39:20 +0000
From: "=?ISO-8859-1?Q?Lu=EDs_Bilo?=" <lp.bilo@gmail.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Subject: Re: REST requests, adb's and namespaces
In-Reply-To: <a9dcda00810272300i112a78bdtd500d706cecbc0c3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Part_28800_7754176.1225201160719"
References: <aede9f250810270905s523c9ef6iaf126af8657cc190@mail.gmail.com>
	 <a9dcda00810272300i112a78bdtd500d706cecbc0c3@mail.gmail.com>

------=_Part_28800_7754176.1225201160719
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In that case the patch my colleague developed follows in attachment.

With these changes rest requests won't have any issues as long as the
namespace is defined @ services.xml in the following manner for each
operation:

<operation name=3D"get_message" uri_ns=3D"http://mps">
=09  <parameter name=3D"wsamapping">urn:get_message</parameter>
=09  <parameter name=3D"RESTMethod">GET</parameter>
=09  <parameter name=3D"RESTLocation">message/{uuid}/</parameter>
</operation>

There is one optimization that can be done, which is allowing a
default namespace for the whole service to be defined as a parameter
also @ services.xml, and only when needed overidding for one operation
the way it is now.

On Tue, Oct 28, 2008 at 6:00 AM, Dimuthu Gamage <dimuthuc@gmail.com> wrote:
> Hi Luis,
> It is a very interesting question. Thanks for raising it.
>
> I got to know, Java solved this problem by adding the necessary namespace=
s
> when building the request axiom from (name, value) pairs. Since they have
> the schema model at the time of processing the request, they don't need a=
ny
> parameter to specify in the services.xml as you suggested.
>
> But since in Axis2/C we don't have the message schema at the processing
> request, we have to go for one of your suggestion. I prefer the first one
> editing services.xml because it is more analogue to what Axis2/Java is
> doing. Or we can give an option to the code generator to ignore the
> namespace validation. But since we are using Axis2/Java codegen tool, it =
is
> not practicle to add an option that only Axis2/C need and Axis2/Java does=
n't
> need. So I think soluiton 1 is more preferrable.
>
> If you already have that patch working, you are really welcomed to add it=
 to
> Axis2/C.
>
>
> Thanks
> Dimuthu
>
>
>
> On Mon, Oct 27, 2008 at 9:35 PM, Lu=EDs Bilo <lp.bilo@gmail.com> wrote:
>>
>> Greetings,
>>
>> I've been using axis for a while now, supporting simultaneously rest
>> and soap requests. I'm also using the adb codegeneration tool from
>> axis2/java project (c data bindings creation from wsdl document ). Now
>> there is one issue when using the auto generated adb's and REST
>> requests. As you know adb will also ensure the parameters in the
>> request have the correct namespace. Problem is only using rest
>> requests we can specify that namespace. When using rest it would be
>> possible to parse the request with axiom, and ignore the namespace.
>> But with adb's that is not an option and rest requests fail within adb
>> serializarion as they miss the required namespace. This seems like a
>> flaw to me, unless i'm missing something here in which case i'd like
>> to hear some feedback.
>>
>> Anyways in order to address this issue we've come across 2 solutions.
>> The first was to include an attribute for each operation @
>> services.xml specifying the default namespace which is then used in
>> rest requests (patched src/core/deployment/svc_builder.c). The second
>> solution was to patch the xls document that specifies adb generation,
>> so there is no namespace verification for any adb (patched
>> /org/apache/axis2/schema/template/CADBBeanTemplateSource.xsl from
>> axis2/java). What are your thoughs on this matter? Is this something
>> you will be addressing in future versions of Axis2/c?
>>
>> Regards,
>> Lu=EDs Bilo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>
>
>
> --
> Thanks,
> Dimuthu Gamage
>
> http://www.dimuthu.org
> http://www.wso2.org
>

------=_Part_28800_7754176.1225201160719
Content-Type: text/x-diff; name=op_ns_uri.diff
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fmukgocv0
Content-Disposition: attachment; filename=op_ns_uri.diff

ZGlmZiAtdSBheGlzMmMxLjUuY2xlYW4vc3JjL2NvcmUvZGVwbG95bWVudC9heGlzMl9kZXBsb3lt
ZW50LmggYXhpczJjLXNyYy0xLjUuMC9zcmMvY29yZS9kZXBsb3ltZW50L2F4aXMyX2RlcGxveW1l
bnQuaAotLS0gYXhpczJjMS41LmNsZWFuL3NyYy9jb3JlL2RlcGxveW1lbnQvYXhpczJfZGVwbG95
bWVudC5oCTIwMDgtMDctMTAgMTM6NTE6NTkuMDAwMDAwMDAwICswMTAwCisrKyBheGlzMmMtc3Jj
LTEuNS4wL3NyYy9jb3JlL2RlcGxveW1lbnQvYXhpczJfZGVwbG95bWVudC5oCTIwMDgtMTAtMjgg
MTM6MDI6MzMuMDAwMDAwMDAwICswMDAwCkBAIC02OSw2ICs2OSw3IEBACiAKIC8qIGZvciBvcGVy
YXRpb25zICovCiAjZGVmaW5lIEFYSVMyX01FUCAibWVwIgorI2RlZmluZSBBWElTMl9BVFRVUklf
TlMgInVyaV9ucyIKIAogLyogZm9yIG1lc3NhZ2VzICovCiAjZGVmaW5lIEFYSVMyX01FU1NBR0Ug
Im1lc3NhZ2UiCmRpZmYgLXUgYXhpczJjMS41LmNsZWFuL3NyYy9jb3JlL2RlcGxveW1lbnQvc3Zj
X2J1aWxkZXIuYyBheGlzMmMtc3JjLTEuNS4wL3NyYy9jb3JlL2RlcGxveW1lbnQvc3ZjX2J1aWxk
ZXIuYwotLS0gYXhpczJjMS41LmNsZWFuL3NyYy9jb3JlL2RlcGxveW1lbnQvc3ZjX2J1aWxkZXIu
YwkyMDA4LTA3LTEwIDEzOjUxOjU5LjAwMDAwMDAwMCArMDEwMAorKysgYXhpczJjLXNyYy0xLjUu
MC9zcmMvY29yZS9kZXBsb3ltZW50L3N2Y19idWlsZGVyLmMJMjAwOC0xMC0yOCAxMzowMDo0NC4w
MDAwMDAwMDAgKzAwMDAKQEAgLTUxMCw2ICs1MTAsNyBAQAogICAgICAgICBheGlvbV9lbGVtZW50
X3QgKm9wX2VsZW1lbnQgPSBOVUxMOwogICAgICAgICBheGlvbV9ub2RlX3QgKm9wX25vZGUgPSBO
VUxMOwogICAgICAgICBheGlvbV9hdHRyaWJ1dGVfdCAqb3BfbmFtZV9hdHQgPSBOVUxMOworICAg
ICAgICBheGlvbV9hdHRyaWJ1dGVfdCAqb3BfdXJpX25zX2F0dCA9IE5VTEw7CiAgICAgICAgIGF4
aW9tX2F0dHJpYnV0ZV90ICpvcF9tZXBfYXR0ID0gTlVMTDsKICAgICAgICAgYXh1dGlsX3FuYW1l
X3QgKnFtZXAgPSBOVUxMOwogICAgICAgICBheHV0aWxfcW5hbWVfdCAqcW9wbmFtZSA9IE5VTEw7
CkBAIC01MTcsOCArNTE4LDEwIEBACiAgICAgICAgIGF4dXRpbF9xbmFtZV90ICpxbXNncmVjdiA9
IE5VTEw7CiAgICAgICAgIGF4dXRpbF9xbmFtZV90ICpxbW9kdWxlc3QgPSBOVUxMOwogICAgICAg
ICBheHV0aWxfcW5hbWVfdCAqcWF0dG5hbWUgPSBOVUxMOworICAgICAgICBheHV0aWxfcW5hbWVf
dCAqcWF0dHVyaV9ucyA9IE5VTEw7CiAgICAgICAgIGF4aXMyX2NoYXJfdCAqbWVwX3VybCA9IE5V
TEw7CiAgICAgICAgIGF4aXMyX2NoYXJfdCAqb3BfbmFtZSA9IE5VTEw7CisgICAgICAgIGF4aXMy
X2NoYXJfdCAqb3BfdXJpX25zID0gTlVMTDsKICAgICAgICAgYXhpczJfb3BfdCAqb3BfZGVzYyA9
IE5VTEw7CiAgICAgICAgIGF4aW9tX2NoaWxkcmVuX3FuYW1lX2l0ZXJhdG9yX3QgKnBhcmFtc19p
dHIgPSBOVUxMOwogICAgICAgICBheGlvbV9jaGlsZHJlbl9xbmFtZV9pdGVyYXRvcl90ICptb2R1
bGVfaXRyID0gTlVMTDsKQEAgLTUzNyw4ICs1NDAsMTEgQEAKICAgICAgICAgb3BfZWxlbWVudCA9
IGF4aW9tX25vZGVfZ2V0X2RhdGFfZWxlbWVudChvcF9ub2RlLCBlbnYpOwogICAgICAgICBxYXR0
bmFtZSA9IGF4dXRpbF9xbmFtZV9jcmVhdGUoZW52LCBBWElTMl9BVFROQU1FLCBOVUxMLCBOVUxM
KTsKICAgICAgICAgb3BfbmFtZV9hdHQgPSBheGlvbV9lbGVtZW50X2dldF9hdHRyaWJ1dGUob3Bf
ZWxlbWVudCwgZW52LCBxYXR0bmFtZSk7CisKKwogICAgICAgICBheHV0aWxfcW5hbWVfZnJlZShx
YXR0bmFtZSwgZW52KTsKICAgICAgICAgcWF0dG5hbWUgPSBOVUxMOworCiAgICAgICAgIGlmICgh
b3BfbmFtZV9hdHQpCiAgICAgICAgIHsKICAgICAgICAgICAgIEFYSVMyX0VSUk9SX1NFVChlbnYt
PmVycm9yLCBBWElTMl9FUlJPUl9PUF9OQU1FX01JU1NJTkcsCkBAIC01NDYsOSArNTUyLDIwIEBA
CiAgICAgICAgICAgICBBWElTMl9MT0dfRVJST1IoZW52LT5sb2csIEFYSVMyX0xPR19TSSwgIiIp
OwogICAgICAgICAgICAgcmV0dXJuIE5VTEw7CiAgICAgICAgIH0KLQogICAgICAgICBvcF9uYW1l
ID0gYXhpb21fYXR0cmlidXRlX2dldF92YWx1ZShvcF9uYW1lX2F0dCwgZW52KTsKLSAgICAgICAg
cW9wbmFtZSA9IGF4dXRpbF9xbmFtZV9jcmVhdGUoZW52LCBvcF9uYW1lLCBOVUxMLCBOVUxMKTsK
KworCS8qIGdldHRpbmcgb3BlcmF0aW9uIG5hbWVzcGFjZSB1cmkgKi8KKworICAgICAgICBxYXR0
dXJpX25zID0gYXh1dGlsX3FuYW1lX2NyZWF0ZShlbnYsIEFYSVMyX0FUVFVSSV9OUywgTlVMTCwg
TlVMTCk7CisgICAgICAgIG9wX3VyaV9uc19hdHQgPSBheGlvbV9lbGVtZW50X2dldF9hdHRyaWJ1
dGUob3BfZWxlbWVudCwgZW52LCBxYXR0dXJpX25zKTsKKworCWlmIChvcF91cmlfbnNfYXR0KQor
CSAgICBvcF91cmlfbnMgPSBheGlvbV9hdHRyaWJ1dGVfZ2V0X3ZhbHVlKG9wX3VyaV9uc19hdHQs
IGVudik7CisKKyAgICAgICAgYXh1dGlsX3FuYW1lX2ZyZWUocWF0dHVyaV9ucywgZW52KTsKKwor
CisgICAgICAgIHFvcG5hbWUgPSBheHV0aWxfcW5hbWVfY3JlYXRlKGVudiwgb3BfbmFtZSwgb3Bf
dXJpX25zLCBOVUxMKTsKICAgICAgICAgb3BfZGVzYyA9IGF4aXMyX29wX2NyZWF0ZShlbnYpOwog
ICAgICAgICBheGlzMl9vcF9zZXRfcW5hbWUob3BfZGVzYywgZW52LCBxb3BuYW1lKTsKICAgICAg
ICAgYXh1dGlsX3FuYW1lX2ZyZWUocW9wbmFtZSwgZW52KTsK

------=_Part_28800_7754176.1225201160719
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
------=_Part_28800_7754176.1225201160719--