[jira] Resolved: (AXIS2C-865) It didn't mention where to copy mod_axis2 shared library On MS Windows
[ https://issues.apache.org/jira/browse/AXIS2C-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera resolved AXIS2C-865. --- Resolution: Fixed This issue fixed. It didn't mention where to copy mod_axis2 shared library On MS Windows -- Key: AXIS2C-865 URL: https://issues.apache.org/jira/browse/AXIS2C-865 Project: Axis2-C Issue Type: Bug Components: documentation Reporter: Manoj Pushpakumara Priority: Minor Fix For: Current (Nightly) In Apache Axis2c/C Manual , it has mention where to copy mod_axis2 shared library On Linux as follows. cp $AXIS2C_HOME/lib/libmod_axis2.so.0.0.0 /usr/lib/apache2/modules/mod_axis2.so copy C:\axis2c\build\deploy\lib\mod_axis2.dll C:\Apache2\modules\mod_axis2.so But it didn't mention where to copy mod_axis2 shared library On MS Windows -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-852) Build breaks if user has older version of Winsock2.h
[ https://issues.apache.org/jira/browse/AXIS2C-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera resolved AXIS2C-852. --- Resolution: Fixed Assignee: Sanjaya Ratnaweera Patch applied. Thanks Senaka for the patch. Build breaks if user has older version of Winsock2.h Key: AXIS2C-852 URL: https://issues.apache.org/jira/browse/AXIS2C-852 Project: Axis2-C Issue Type: Bug Components: build system (Windows), util Affects Versions: 1.2.0 Environment: Windows XP SP2 Reporter: Senaka Fernando Assignee: Sanjaya Ratnaweera Attachments: diff.txt Build breaks if user has older version of Winsock2.h. This can be due to various reasons. I have added a patch that solves this issue (refer diff.txt) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-296) tcpmon fails to operate correctly with dual clients
[ https://issues.apache.org/jira/browse/AXIS2C-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera resolved AXIS2C-296. --- Resolution: Fixed Assignee: Sanjaya Ratnaweera Patch applied. Thanks senaka for the patch. tcpmon fails to operate correctly with dual clients --- Key: AXIS2C-296 URL: https://issues.apache.org/jira/browse/AXIS2C-296 Project: Axis2-C Issue Type: Bug Components: tcpmon Affects Versions: Current (Nightly) Reporter: Samisa Abeysinghe Assignee: Sanjaya Ratnaweera Attachments: diff.txt If I run a dual client with tcpmon, the client hangs infinitely after sending request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-929) Support for HTTP HEAD Method
[ https://issues.apache.org/jira/browse/AXIS2C-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando updated AXIS2C-929: --- Attachment: (was: diff.txt) Support for HTTP HEAD Method Key: AXIS2C-929 URL: https://issues.apache.org/jira/browse/AXIS2C-929 Project: Axis2-C Issue Type: New Feature Components: transport/http Affects Versions: Current (Nightly) Reporter: Senaka Fernando Fix For: 1.2.1 Attachments: diff.txt I have added support for handling HTTP HEAD Requests. Refer diff.txt for proposed patch. Regards, Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-929) Support for HTTP HEAD Method
[ https://issues.apache.org/jira/browse/AXIS2C-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando updated AXIS2C-929: --- Attachment: diff.txt Support for HTTP HEAD Method Key: AXIS2C-929 URL: https://issues.apache.org/jira/browse/AXIS2C-929 Project: Axis2-C Issue Type: New Feature Components: transport/http Affects Versions: Current (Nightly) Reporter: Senaka Fernando Fix For: 1.2.1 Attachments: diff.txt I have added support for handling HTTP HEAD Requests. Refer diff.txt for proposed patch. Regards, Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-929) Support for HTTP HEAD Method
[ https://issues.apache.org/jira/browse/AXIS2C-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dushshantha Chandradasa resolved AXIS2C-929. Resolution: Fixed Assignee: Dushshantha Chandradasa applied the patch. Thank Senaka for the patch Support for HTTP HEAD Method Key: AXIS2C-929 URL: https://issues.apache.org/jira/browse/AXIS2C-929 Project: Axis2-C Issue Type: New Feature Components: transport/http Affects Versions: Current (Nightly) Reporter: Senaka Fernando Assignee: Dushshantha Chandradasa Fix For: 1.2.1 Attachments: diff.txt I have added support for handling HTTP HEAD Requests. Refer diff.txt for proposed patch. Regards, Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unsubscribe not working
I apologize for bothering the group as a whole, but... Is there someone who can help unsubscribe my address from this group? I've emailed the link provided ([EMAIL PROTECTED]) multiple times over several weeks and I continue to receive group emailings. Thank you, Horst http://www.unify.com/ www.unify.com http://www.unify.com/ Horst de Lorenzi [EMAIL PROTECTED] W:814.321.4671 image001.jpg
RESTful services, services.xml
Hi all,
After discussing with Axis2/Java folk, I believe that we should improve
the services.xml to support RESTful Services as we don't have a WSDL2.0
mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
[2]. Specification of the default HTTPMethod for a service:
parameter name=HTTPMethod locked=xsd:falseGET/parameter
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
service name=sample
parameter name=HTTPMethod locked=xsd:falseGET/parameter
description
This is a sample service.
/description
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
/service
[4]. This is a sample request to this service
ex:- http://localhost:9090/sample/foo/bar/12/14?query
Please add your comments and suggestions.
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
Senaka Fernando wrote:
Hi all,
After discussing with Axis2/Java folk, I believe that we should improve
the services.xml to support RESTful Services as we don't have a WSDL2.0
mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
These are REST specific parameters. With or without those in place, SOAP
should also work, as it used to be. I do think the parameter names
should reflect that they are REST specific. Otherwise the user will
confuse them with SOAP cases as well.
So why not prefix them with REST.
Also, should we not be able to expose the same service operation, e,g,
foo, with multiple HTTP methods? How are we supposed to handle that with
this syntax? If we combine HTTP method with location, I think we can
handle that case
e.g.
operation name=foo
parameter name=RESTPUT:foo/barp/{x}/{y}/parameter
parameter name=RESTGET:foo/barg/{a}/{b}/parameter
/operation
Would that be really RESTful?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Becuase the payload comes in the request body. I think it is only GET
and DELETE need those {} parts. Am I missing something here?
Thanks,
Samisa...
[2]. Specification of the default HTTPMethod for a service:
parameter name=HTTPMethod locked=xsd:falseGET/parameter
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
service name=sample
parameter name=HTTPMethod locked=xsd:falseGET/parameter
description
This is a sample service.
/description
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
/service
[4]. This is a sample request to this service
ex:- http://localhost:9090/sample/foo/bar/12/14?query
Please add your comments and suggestions.
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: version incompatibilities
Oops! That is a glitch :( We should add this to our check list in the release process Wiki. Devs, should we do a patch release fixing this? I think we should. Thanks, Samisa... Michael Sutter wrote: Hello list, I have found two incompatibilities in version 1.2. First one is in axutil_version.h. There the AXIS2_MINOR_VERSION is defined as 1 and should be 2. The second one is in axis2.pc config file. If I use pkg-config to find the correct libraries I think the provided output is not correct: pkg-config --libs axis2c produces -L/home/auger/axis2c-1.2.0/lib -laxis2 -lxml2 -lz -ldl But there exists no axis2 library. So it produces a error when used for compiling. The -laxis2 is defined in axis2.pc.in. It would be nice if both could be fixed. Kind regards Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: version incompatibilities
On Jan 24, 2008 10:37 PM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Oops! That is a glitch :( We should add this to our check list in the release process Wiki. Devs, should we do a patch release fixing this? I think we should. +1 -Dumindu. -- Dumindu Pallewela http://blog.dumindu.com GPG ID: 0x9E131672 WSO2 | Oxygenating the Web Service Platform | http://wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
Senaka Fernando wrote:
Hi all,
After discussing with Axis2/Java folk, I believe that we should improve
the services.xml to support RESTful Services as we don't have a WSDL2.0
mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
These are REST specific parameters. With or without those in place, SOAP
should also work, as it used to be. I do think the parameter names
should reflect that they are REST specific. Otherwise the user will
confuse them with SOAP cases as well.
So why not prefix them with REST.
Also, should we not be able to expose the same service operation, e,g,
foo, with multiple HTTP methods? How are we supposed to handle that with
this syntax? If we combine HTTP method with location, I think we can
handle that case
e.g.
operation name=foo
parameter name=RESTPUT:foo/barp/{x}/{y}/parameter
parameter name=RESTGET:foo/barg/{a}/{b}/parameter
/operation
Would that be really RESTful?
Well, in fact WSDL 2.0 includes extensions supporting RESTful services,
and the attempt here, was to mimic the WSDL2.0 spec. Also, each operation
wouldn't have more than one method against it. Thus, I believe it is not
possible to combine the method and the location. This is explained in [1].
However, in order to avoid confusion, I'm +1 for adding the REST prefix,
making it,
1. REST_HTTPMethod
2. REST_HTTPLocation
Any thoughts?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Because the payload comes in the request body. I think it is only GET
and DELETE need those {} parts. Am I missing something here?
Thanks,
Samisa...
Yes, I believe that the Service Author is not restricted not to add such
parts in the RESTful scenario. So even in PUT and DELETE he may do so, as
in [2].
I believe that the following resources, [3], and [4], would also be useful.
[1] http://www.w3.org/TR/wsdl20-adjuncts/#http-binding-id
[2] http://www.w3.org/TR/wsdl20-adjuncts/#_http_serialization
[3] http://www.bloglines.com/blog/sanjiva?id=227
[4] https://wadl.dev.java.net/
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RESTful services, services.xml
I agree that for a given operation, multiple HTTP methods need to be
supported. For my update item operation, I want to support taking a big
XML chunk with lots of data to update (PUT), or allow the caller to
simply specify one or two pieces of data in the query string to update
(GET). I know GET is not supposed to side effect the data, but I still
want to support this simplified way of updating (is this okay?).
Alternatively I may want to allow a PUT where all the data is in the URL
and there is actually no XML data being posted. So we would still need
to allow the {x}/{y}/parameter part of the URL on PUT in order to
accomplish this.
-Dave.
-Original Message-
From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 24, 2008 8:38 AM
To: Apache AXIS C Developers List
Subject: Re: RESTful services, services.xml
Senaka Fernando wrote:
Hi all,
After discussing with Axis2/Java folk, I believe that we should
improve the services.xml to support RESTful Services as we don't have
a WSDL2.0 mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation
foo/bar/{x}/{y}/parameter
/operation
These are REST specific parameters. With or without those in place, SOAP
should also work, as it used to be. I do think the parameter names
should reflect that they are REST specific. Otherwise the user will
confuse them with SOAP cases as well.
So why not prefix them with REST.
Also, should we not be able to expose the same service operation, e,g,
foo, with multiple HTTP methods? How are we supposed to handle that with
this syntax? If we combine HTTP method with location, I think we can
handle that case e.g.
operation name=foo
parameter name=RESTPUT:foo/barp/{x}/{y}/parameter
parameter name=RESTGET:foo/barg/{a}/{b}/parameter
/operation
Would that be really RESTful?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Becuase the payload comes in the request body. I think it is only GET
and DELETE need those {} parts. Am I missing something here?
Thanks,
Samisa...
[2]. Specification of the default HTTPMethod for a service:
parameter name=HTTPMethod locked=xsd:falseGET/parameter
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be
matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
service name=sample
parameter name=HTTPMethod locked=xsd:falseGET/parameter
description
This is a sample service.
/description
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation
foo/bar/{x}/{y}/parameter
/operation
/service
[4]. This is a sample request to this service
ex:- http://localhost:9090/sample/foo/bar/12/14?query
Please add your comments and suggestions.
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. Any
unauthorized review, use, disclosure or distribution is prohibited. If you are
not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RESTful services, services.xml
Hi Dave,
I guess it is not done that way. Your GET operation would target the GET
call and the PUT operation would target the PUT call. The engine is not
supposed to relay the operation's behavior depending on the HTTP Method.
You can have multiple operations doing multiple tasks of course, as you
are not limited to one operation per service.
Of course you have this option. Your client will see both operations by
the same name, if there would be no ambiguity. As you see, the behavior is
not like SOAP. For instance this is possible.
ex:- GET http://localhost:9090/service/upload/file?blah=blah and PUT
http://localhost:9090/service/upload/file.
After reading below you may notice, that this is not ambiguous. The
mapping would be like this.
service name=service
parameter name=HTTPMethod locked=xsd:falseGET/parameter
description
This is a sample service.
/description
operation name=foo
parameter name=HTTPMethodPUT/parameter
parameter name=HTTPLocationupload/{x}/parameter
/operation
operation name=upload
parameter name=HTTPMethodGET/parameter
parameter name=HTTPLocationupload/{x}/parameter
/operation
/service
What I'm trying to tell is that you only need to have this
operation-has-only-one-method limitation on the server side. The consuming
client will not at all notice.
Regards,
Senaka
I agree that for a given operation, multiple HTTP methods need to be
supported. For my update item operation, I want to support taking a big
XML chunk with lots of data to update (PUT), or allow the caller to
simply specify one or two pieces of data in the query string to update
(GET). I know GET is not supposed to side effect the data, but I still
want to support this simplified way of updating (is this okay?).
Alternatively I may want to allow a PUT where all the data is in the URL
and there is actually no XML data being posted. So we would still need
to allow the {x}/{y}/parameter part of the URL on PUT in order to
accomplish this.
-Dave.
-Original Message-
From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 24, 2008 8:38 AM
To: Apache AXIS C Developers List
Subject: Re: RESTful services, services.xml
Senaka Fernando wrote:
Hi all,
After discussing with Axis2/Java folk, I believe that we should
improve the services.xml to support RESTful Services as we don't have
a WSDL2.0 mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation
foo/bar/{x}/{y}/parameter
/operation
These are REST specific parameters. With or without those in place, SOAP
should also work, as it used to be. I do think the parameter names
should reflect that they are REST specific. Otherwise the user will
confuse them with SOAP cases as well.
So why not prefix them with REST.
Also, should we not be able to expose the same service operation, e,g,
foo, with multiple HTTP methods? How are we supposed to handle that with
this syntax? If we combine HTTP method with location, I think we can
handle that case e.g.
operation name=foo
parameter name=RESTPUT:foo/barp/{x}/{y}/parameter
parameter name=RESTGET:foo/barg/{a}/{b}/parameter
/operation
Would that be really RESTful?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Becuase the payload comes in the request body. I think it is only GET
and DELETE need those {} parts. Am I missing something here?
Thanks,
Samisa...
[2]. Specification of the default HTTPMethod for a service:
parameter name=HTTPMethod locked=xsd:falseGET/parameter
[3]. This is the explanation of HTTPLocation parameter.
1. This is the trailing portion of the URL after the service name.
2. This may or may not start with the operation name.
3. This may include constant portions and variable portions.
4. Variable portions are included inside '{' '}' (curly braces).
5. Curly braces are escaped as {{ or }}.
6. Escaping of curly braces adds another limitation, being we can't
specify constant portions inside a variable portion and vice versa.
7. Separation of portions is done by '/'s.
8. HTTPLocation can include query-string portions that need 2 be
matched.
9. Thus, someone can make the order of the query string parameters
significant.
10. Un-specified areas are not captured.
This is a sample RESTful services' service.xml:
service name=sample
parameter name=HTTPMethod locked=xsd:falseGET/parameter
description
This is a sample service.
/description
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation
foo/bar/{x}/{y}/parameter
/operation
/service
[4]. This is a sample request to this service
ex:-
Axis2C support for dynamic operations
Hi All, I have a requirement to support dynamically generated wsdls. Each wsdl will contain a core set of operations, but will then have additional operations defined. I want to use the wsdl with the core set of operations as my service in Axis2C, but then write code in my invoke method that will know about the additional new operations as they will follow a standard pattern. My question is, how can I get Axis2C to forward the request to my invoke method, for operations that are not in the services.xml file? In services.xml could I somehow use wildcards? Like this: operation name=Update* parameter name=wsamapping\\/parameter /operation So then a custom wsdl file would be given to a client and it could have operations like UpdateFoo and UpdateBar, which are not in the services.xml, but the Update* could match them. Then in my invoke method I could analyze the operation name and know what to do with it (e.g. UpdateFoo would tell me to use Foo logic and I would know how to handle that). The purpose for this is ease of use to the client. We have many operations that are generalized, but if I can generate new wsdl to do specifically what the user is trying to do, they can use these custom operation names directly. This will result in greatly increased usability. I think most of the work is on the service in my code, but I need a way to tell Axis2C to forward along the request even if it is not in the known set. Is there a way to do this, or is there a way to modify the code to support this? Thank you much, -Dave. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Axis2C support for dynamic operations
Hi Devs, I believe we are still working on WSDL support. But, even if we do, is this possible without hot-deployment? Thanks, Senaka Hi All, I have a requirement to support dynamically generated wsdls. Each wsdl will contain a core set of operations, but will then have additional operations defined. I want to use the wsdl with the core set of operations as my service in Axis2C, but then write code in my invoke method that will know about the additional new operations as they will follow a standard pattern. My question is, how can I get Axis2C to forward the request to my invoke method, for operations that are not in the services.xml file? In services.xml could I somehow use wildcards? Like this: operation name=Update* parameter name=wsamapping\\/parameter /operation So then a custom wsdl file would be given to a client and it could have operations like UpdateFoo and UpdateBar, which are not in the services.xml, but the Update* could match them. Then in my invoke method I could analyze the operation name and know what to do with it (e.g. UpdateFoo would tell me to use Foo logic and I would know how to handle that). The purpose for this is ease of use to the client. We have many operations that are generalized, but if I can generate new wsdl to do specifically what the user is trying to do, they can use these custom operation names directly. This will result in greatly increased usability. I think most of the work is on the service in my code, but I need a way to tell Axis2C to forward along the request even if it is not in the known set. Is there a way to do this, or is there a way to modify the code to support this? Thank you much, -Dave. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful services, services.xml
Senaka Fernando wrote:
Senaka Fernando wrote:
Hi all,
After discussing with Axis2/Java folk, I believe that we should improve
the services.xml to support RESTful Services as we don't have a WSDL2.0
mode. This is the proposed scheme.
[1]. Adding a local http_location mapping for each operation:
operation name=foo
parameter name=HTTPMethod PUT/parameter
parameter name=HTTPLocation foo/bar/{x}/{y}/parameter
/operation
These are REST specific parameters. With or without those in place, SOAP
should also work, as it used to be. I do think the parameter names
should reflect that they are REST specific. Otherwise the user will
confuse them with SOAP cases as well.
So why not prefix them with REST.
Also, should we not be able to expose the same service operation, e,g,
foo, with multiple HTTP methods? How are we supposed to handle that with
this syntax? If we combine HTTP method with location, I think we can
handle that case
e.g.
operation name=foo
parameter name=RESTPUT:foo/barp/{x}/{y}/parameter
parameter name=RESTGET:foo/barg/{a}/{b}/parameter
/operation
Would that be really RESTful?
Well, in fact WSDL 2.0 includes extensions supporting RESTful services,
and the attempt here, was to mimic the WSDL2.0 spec. Also, each operation
wouldn't have more than one method against it. Thus, I believe it is not
possible to combine the method and the location. This is explained in [1].
Our concept of operation is differernt form the REST concept of
operation here. Our operation maps to a function and RESTful
operation maps to a piece of logic in that function.
Anyway I need to have revisit the WSDL 2.0 spec to clear this up. Till
then I still think, conceptually, an operation in our description
hierarchy should be mapped to multiple HTTP methods.
Samisa...
However, in order to avoid confusion, I'm +1 for adding the REST prefix,
making it,
1. REST_HTTPMethod
2. REST_HTTPLocation
Any thoughts?
Also, I was wondering, in case of POST and PUT, do we need {x}/{y} part?
Because the payload comes in the request body. I think it is only GET
and DELETE need those {} parts. Am I missing something here?
Thanks,
Samisa...
Yes, I believe that the Service Author is not restricted not to add such
parts in the RESTful scenario. So even in PUT and DELETE he may do so, as
in [2].
I believe that the following resources, [3], and [4], would also be useful.
[1] http://www.w3.org/TR/wsdl20-adjuncts/#http-binding-id
[2] http://www.w3.org/TR/wsdl20-adjuncts/#_http_serialization
[3] http://www.bloglines.com/blog/sanjiva?id=227
[4] https://wadl.dev.java.net/
Regards,
Senaka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: version incompatibilities
On Jan 24, 2008 10:37 PM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Oops! That is a glitch :( We should add this to our check list in the release process Wiki. Devs, should we do a patch release fixing this? I think we should. +1 thanks, Dinesh -- http://nethu.org/
Accessing the SOAP headers at the svc_client side
Hi, Is it possible to access the SOAP headers from the client side in Axis2/c. In service side, we have the access to SOAP headers in 'invoke' method using axis2_msg_ctx_t, where we can get in_msg_ctx through axis2_op_ctx_t. Can we do this kind of thing in svc_client side? axis2_svc_client provides a way to get to get svc_ctx through axis2_svc_client_get_svc_ctx, but how we can access msg_ctx through this? Thanks. Kasun
Re: Accessing the SOAP headers at the svc_client side
I think you can get the last response SOAP envelope from axis2_svc_client_get_last_response_soap_envelope() method. From the SOAP envelope you can get SOAP headers. You can't access the msg_ctx directly from svc_client. For that you need to get axis2_op_client from, axis2_svc_client_get_op_client() Then using that op_client you can retrieve msg_ctx by calling axis2_op_client_get_msg_ctx() -Manjula. On Fri, 2008-01-25 at 09:15 +0530, Kasun Indrasiri wrote: Hi, Is it possible to access the SOAP headers from the client side in Axis2/c. In service side, we have the access to SOAP headers in 'invoke' method using axis2_msg_ctx_t, where we can get in_msg_ctx through axis2_op_ctx_t. Can we do this kind of thing in svc_client side? axis2_svc_client provides a way to get to get svc_ctx through axis2_svc_client_get_svc_ctx, but how we can access msg_ctx through this? Thanks. Kasun - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing the SOAP headers at the svc_client side
Hi Kasun, Kasun Indrasiri [EMAIL PROTECTED] writes: Hi, Is it possible to access the SOAP headers from the client side in Axis2/c. In service side, we have the access to SOAP headers in 'invoke' method using axis2_msg_ctx_t, where we can get in_msg_ctx through axis2_op_ctx_t. Can we do this kind of thing in svc_client side? axis2_svc_client provides a way to get to get svc_ctx through axis2_svc_client_get_svc_ctx, but how we can access msg_ctx through this? op_client = axis2_svc_client_get_op_client(svc_client, env); msg_ctx = (axis2_msg_ctx_t *)axis2_op_client_get_msg_ctx (op_client, env, AXIS2_WSDL_MESSAGE_LABEL_IN); If you want to get incoming msg_ctx AXIS2_WSDL_MESSAGE_LABEL_IN outgoing msg_ctx AXIS2_WSDL_MESSAGE_LABEL_OUT should use. thanks, Dinesh -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: version incompatibilities
Hi Devs, Samisa Abeysinghe [EMAIL PROTECTED] writes: So looks devs are OK to do a patch release. I am a bit occupied, can we have a RM volunteer to do the job, preferably a PMC. I can work on this next week. thanks, Dinesh -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: version incompatibilities
Samisa Abeysinghe wrote: Oops! That is a glitch :( We should add this to our check list in the release process Wiki. Devs, should we do a patch release fixing this? I think we should. +1 -Kau Thanks, Samisa... Michael Sutter wrote: Hello list, I have found two incompatibilities in version 1.2. First one is in axutil_version.h. There the AXIS2_MINOR_VERSION is defined as 1 and should be 2. The second one is in axis2.pc config file. If I use pkg-config to find the correct libraries I think the provided output is not correct: pkg-config --libs axis2c produces -L/home/auger/axis2c-1.2.0/lib -laxis2 -lxml2 -lz -ldl But there exists no axis2 library. So it produces a error when used for compiling. The -laxis2 is defined in axis2.pc.in. It would be nice if both could be fixed. Kind regards Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] [Vote] Dinesh as Release Manager for Apache Axis2/C 1.2.1 Release
Hi All, I would like to propose Dinesh Premalal as the release manager for Apache Axis2/C 1.2.1 release. Since we have identified few glitches, it is worth to fix them with a patch release, along with any bugs we have fixed since the release of 1.2.0. Dinesh was volunteered to be the release manager and I would like to call this vote confirm his role as RM. Here is my vote: +1. Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] [Vote] Dinesh as Release Manager for Apache Axis2/C 1.2.1 Release
+1 Thanks ~sanjaya Samisa Abeysinghe wrote: Hi All, I would like to propose Dinesh Premalal as the release manager for Apache Axis2/C 1.2.1 release. Since we have identified few glitches, it is worth to fix them with a patch release, along with any bugs we have fixed since the release of 1.2.0. Dinesh was volunteered to be the release manager and I would like to call this vote confirm his role as RM. Here is my vote: +1. Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Can we make Guththila the default parser?
Hi devs, I tested Rampart/C with Axis2/c (guththila enabled). All the secpolicy samples were successful. I think above mentioned fix by supun has fixed the bugs in guththila when working with Rampart/C. Thanks, Milinda On Jan 24, 2008 11:30 AM, Supun Kamburugamuva [EMAIL PROTECTED] wrote: On 1/23/08, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Supun Kamburugamuva wrote: Making guththila as the default parser may cause us few problems in the short terms. What sort of? There are few issues reported in the Jira and we need to fix them as soon as possible and there may be new bugs that are not yet discovered. These bugs (if there are any) will start to surface as soon as guththila is used by many users with different needs. Regards, Supun.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://think2ed.blogspot.com thinksquared http://wsaxc.blogspot.com Web Services With Axis2/C
Re: [Axis2] [Vote] Dinesh as Release Manager for Apache Axis2/C 1.2.1 Release
Samisa Abeysinghe wrote: Hi All, I would like to propose Dinesh Premalal as the release manager for Apache Axis2/C 1.2.1 release. Since we have identified few glitches, it is worth to fix them with a patch release, along with any bugs we have fixed since the release of 1.2.0. Dinesh was volunteered to be the release manager and I would like to call this vote confirm his role as RM. Here is my vote: +1. +1 for Dinesh as the release manager. -Kau Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Can we make Guththila the default parser?
Let us *not* do this change for the 1.2.1 patch release. Because we did 1.2.0 with libxml. Thanks, Samisa... Milinda Pathirage wrote: Hi devs, I tested Rampart/C with Axis2/c (guththila enabled). All the secpolicy samples were successful. I think above mentioned fix by supun has fixed the bugs in guththila when working with Rampart/C. Thanks, Milinda On Jan 24, 2008 11:30 AM, Supun Kamburugamuva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 1/23/08, Samisa Abeysinghe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Supun Kamburugamuva wrote: Making guththila as the default parser may cause us few problems in the short terms. What sort of? There are few issues reported in the Jira and we need to fix them as soon as possible and there may be new bugs that are not yet discovered. These bugs (if there are any) will start to surface as soon as guththila is used by many users with different needs. Regards, Supun.. - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- http://think2ed.blogspot.com thinksquared http://wsaxc.blogspot.com http://wsaxc.blogspot.com Web Services With Axis2/C No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date: 1/23/2008 5:47 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] [Vote] Dinesh as Release Manager for Apache Axis2/C 1.2.1 Release
+1 Nandika On Jan 25, 2008 11:47 AM, Dumindu Pallewela [EMAIL PROTECTED] wrote: +1 On Jan 25, 2008 11:25 AM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Hi All, I would like to propose Dinesh Premalal as the release manager for Apache Axis2/C 1.2.1 release. Since we have identified few glitches, it is worth to fix them with a patch release, along with any bugs we have fixed since the release of 1.2.0. Dinesh was volunteered to be the release manager and I would like to call this vote confirm his role as RM. Here is my vote: +1. Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dumindu Pallewela http://blog.dumindu.com GPG ID: 0x9E131672 WSO2 | Oxygenating the Web Service Platform | http://wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://nandikajayawardana.blogspot.com/ WSO2 Inc: http://www.wso2.com
Re: [Axis2] Can we make Guththila the default parser?
Hi, Tested and works fine... :) -Kau Milinda Pathirage wrote: Hi devs, I tested Rampart/C with Axis2/c (guththila enabled). All the secpolicy samples were successful. I think above mentioned fix by supun has fixed the bugs in guththila when working with Rampart/C. Thanks, Milinda On Jan 24, 2008 11:30 AM, Supun Kamburugamuva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 1/23/08, Samisa Abeysinghe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Supun Kamburugamuva wrote: Making guththila as the default parser may cause us few problems in the short terms. What sort of? There are few issues reported in the Jira and we need to fix them as soon as possible and there may be new bugs that are not yet discovered. These bugs (if there are any) will start to surface as soon as guththila is used by many users with different needs. Regards, Supun.. - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- http://think2ed.blogspot.com thinksquared http://wsaxc.blogspot.com http://wsaxc.blogspot.com Web Services With Axis2/C -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
