You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Luís Bilo <lp...@gmail.com> on 2008/10/27 17:05:56 UTC

REST requests, adb's and namespaces

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ís Bilo

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


Re: REST requests, adb's and namespaces

Posted by Luís Bilo <lp...@gmail.com>.
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="get_message" uri_ns="http://mps">
	  <parameter name="wsamapping">urn:get_message</parameter>
	  <parameter name="RESTMethod">GET</parameter>
	  <parameter name="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 <di...@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 namespaces
> 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 any
> 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 doesn'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�s Bilo <lp...@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�s 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
>

Re: REST requests, adb's and namespaces

Posted by Dimuthu Gamage <di...@gmail.com>.
Hi Luis,
It is a very interesting question. Thanks for raising it.

I got to know, Java solved this problem by adding the necessary namespaces
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 any
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 doesn'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ís Bilo <lp...@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ís 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