[jira] Created: (AXIS2C-324) adding methods set_target_endpoint_ref and get_target_endpoint_ref to axis2_svc_client
adding methods set_target_endpoint_ref and get_target_endpoint_ref to axis2_svc_client -- Key: AXIS2C-324 URL: http://issues.apache.org/jira/browse/AXIS2C-324 Project: Axis2-C Issue Type: Improvement Components: core/clientapi Reporter: Damitha Kumarage Adding following two methods to svc_client. These methods are useful so that one can define the target independantly of wsa:to. Now the following scenario is possible. I can set the target endpoint as the tcpmon listening at a port and wsa:to as the actual target to send the request at. /** * Gets the target endpoint ref. * @param svc_client pointer to service client struct * @param env pointer to environment struct * @return pointer to the endpoint_ref struct. Returns a reference, * not a cloned copy. */ const axis2_endpoint_ref_t *(AXIS2_CALL * get_target_endpoint_ref)( const axis2_svc_client_t *svc_client, const axis2_env_t *env); /** * Sets the target endpoint ref. If this is not set then the target * is deduced from wsa to epr. * @param svc_client pointer to service client struct * @param env pointer to environment struct * @param target_epr pointer to the endpoint_ref struct to be set as * target. service client takes over the ownership of the struct. * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE */ axis2_status_t (AXIS2_CALL * set_target_endpoint_ref)( axis2_svc_client_t *svc_client, const axis2_env_t *env, axis2_endpoint_ref_t *target_epr); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-323) Added set_listen_port method to svc_client
Added set_listen_port method to svc_client -- Key: AXIS2C-323 URL: http://issues.apache.org/jira/browse/AXIS2C-323 Project: Axis2-C Issue Type: Improvement Components: core/clientapi Reporter: Damitha Kumarage axis2_status_t (AXIS2_CALL * set_listen_port)( const axis2_svc_client_t *svc_client, const axis2_env_t *env, axis2_char_t *port); method is added so that this can be used to specify the actual port the callback server is listening to. Previosly this is set in axis2.xml which is not good for users using wsclient or php clients. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2_svc_client_get_options returns a "const" ?
Samisa Abeysinghe wrote: Ishan De Silva wrote: Hi, The get_option function of the service client returns a const axis2_options_t pointer. The idea is that use would create options and would own options. Hence not need to access options from service client in your client program. Rather use the pointer to options that you passes to service client. I came across this problem when writing a module. I'm providing a library function which takes in a service client as an IN parameter. Inside the function, I want to change the wsa:Action and use that client to send a message. I remember the old action so that I can set it back when returning from the function. So in this situation, I don't own the options nor the client. As a work around, I can forcefully cast the return value from get_option fn to a non-const type. Is that the correct way to go? Thanks, Ishan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2C-316) We send action is content-type by deffault when using SOAP 1.2; this may lead to interop problems
[ http://issues.apache.org/jira/browse/AXIS2C-316?page=all ] Samisa Abeysinghe closed AXIS2C-316. Fix Version/s: 0.95 Resolution: Fixed The code was assuming WSA action to be SOAP action and that lead to errors. Fixed the code so that it does not. Now no SOAP action is sent, if only yhe WSA action is set > We send action is content-type by deffault when using SOAP 1.2; this may lead > to interop problems > - > > Key: AXIS2C-316 > URL: http://issues.apache.org/jira/browse/AXIS2C-316 > Project: Axis2-C > Issue Type: Bug > Components: xml/soap >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > Fix For: 0.95 > > > May be sending action in content type by default is not required. Should look > into specs and fix this -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2C-314) If there is a " in mime boundrary, the mime boundary location fails in MIME parser
[ http://issues.apache.org/jira/browse/AXIS2C-314?page=all ] Samisa Abeysinghe closed AXIS2C-314. Fix Version/s: 0.95 Resolution: Fixed Fixed this so that it skips '"' character when comparing the MIME boundary to that present in the mime parts > If there is a " in mime boundrary, the mime boundary location fails in MIME > parser > -- > > Key: AXIS2C-314 > URL: http://issues.apache.org/jira/browse/AXIS2C-314 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > Fix For: 0.95 > > > Sometimes, other platforms use " char to delimit the mime boundary. But in > the message content, they use the boundary without ". This is a leagal case. > But mime parser tries to locate the mime boundary with " chars in place and > fails. Need to strip the wrapping " in this case -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-317) Sending MIME headers when client did not use MIME haders
[ http://issues.apache.org/jira/browse/AXIS2C-317?page=all ] Samisa Abeysinghe resolved AXIS2C-317. -- Fix Version/s: 0.95 Resolution: Fixed Some of the problems related to MIME headers were fixed at code level. Now the idea is not to set enableMime in axis2.xml. If that is not set, still the client or server can handle optimized attachments. When sending attachments, if the sender (either server or client) wants it to be optimized, it needs to set enableMTOM, else base 64 would be sent. > Sending MIME headers when client did not use MIME haders > > > Key: AXIS2C-317 > URL: http://issues.apache.org/jira/browse/AXIS2C-317 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > Fix For: 0.95 > > > Sending MIME headers when client did not use MIME haders is a bad idea. In > this case, we have to drop mime haders if we are not sending MTOM optimized. > Even if are are sending MTOM, we need to figure out if the client could > understand us - that is select between optimized vs base64 automatically. > Need to look into this to do the correct thig here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][ANN]Apache Axis2/c 0.94 Released.
Eran Chinthaka wrote: Excellent !! I just followed your installation guide and everything worked as described (not like in Axis2/Java :) ). Credit to all the folks tested the release; especially yo the release manager Dinesh. I was amazed to see how it was to do echo invocation compared to the time it takes in Axis2 java. Anyway, I have couple of minor comments. 1. Logs are by default set to debug level in the release. Don't you think it better be set to INFO (I'm thinking in terms of log4j :) ) when you release it. Good point, users may not need all the debug garbage. We developers use debug level all the time. 2. I saw a 0 byte file, AUTHORS, in the root directory of the release. Was it intentional? Nop it is not intentional - its a mistake :( Thanks for the feedback. Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2C-318) xmlBufferPtr is used incorrectly in libxml2_writer_wrapper
[ http://issues.apache.org/jira/browse/AXIS2C-318?page=all ] Samisa Abeysinghe closed AXIS2C-318. Fix Version/s: 0.95 Resolution: Fixed Fixed using following logic output = AXIS2_MALLOC(env->allocator, sizeof(axis2_char_t) * ( writer_impl->buffer->size + 1)); memcpy(output, writer_impl->buffer->content, writer_impl->buffer->size); output[writer_impl->buffer->size] = '\0'; > xmlBufferPtr is used incorrectly in libxml2_writer_wrapper > -- > > Key: AXIS2C-318 > URL: http://issues.apache.org/jira/browse/AXIS2C-318 > Project: Axis2-C > Issue Type: Bug > Components: xml/parser >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > Fix For: 0.95 > > > in axis2_libxml2_writer_wrapper_get_xml function we have: > output = AXIS2_MALLOC(env->allocator, > sizeof(axis2_char_t) * ( > strlen((const > axis2_char_t*)(writer_impl->buffer->content)) + 1)); > sprintf(output, > ((const axis2_char_t*)(writer_impl->buffer->content))); > Where buffer is defined as: > xmlBufferPtr buffer; > Looking at the definition of xmlBuffer, it looks to me that there is a size > field that we should look into. Hence, just taking strlen of buffer content > is error prone. Also, content is of type 'unsigned char'. Hence casting that > to 'axis2_char_t' may also lead to errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2C-315) content-id problems in MTOM
[ http://issues.apache.org/jira/browse/AXIS2C-315?page=all ] Samisa Abeysinghe closed AXIS2C-315. Fix Version/s: 0.95 Resolution: Fixed Fixed. Added a strcasestr and used that to solve the problem > content-id problems in MTOM > --- > > Key: AXIS2C-315 > URL: http://issues.apache.org/jira/browse/AXIS2C-315 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > Fix For: 0.95 > > > Mime parser looks for "content-id", but it is leagl to use "Content-Id", we > need to use a case insensitive comparison in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-315) content-id problems in MTOM
[ http://issues.apache.org/jira/browse/AXIS2C-315?page=comments#action_12439913 ] Samisa Abeysinghe commented on AXIS2C-315: -- What I really need to solve this is strcasestr > content-id problems in MTOM > --- > > Key: AXIS2C-315 > URL: http://issues.apache.org/jira/browse/AXIS2C-315 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) >Reporter: Samisa Abeysinghe > Assigned To: Samisa Abeysinghe > > Mime parser looks for "content-id", but it is leagl to use "Content-Id", we > need to use a case insensitive comparison in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][ANN]Apache Axis2/c 0.94 Released.
Excellent !! I just followed your installation guide and everything worked as described (not like in Axis2/Java :) ). I was amazed to see how it was to do echo invocation compared to the time it takes in Axis2 java. Anyway, I have couple of minor comments.1. Logs are by default set to debug level in the release. Don't you think it better be set to INFO (I'm thinking in terms of log4j :) ) when you release it. 2. I saw a 0 byte file, AUTHORS, in the root directory of the release. Was it intentional? 3. This is a tiny mistake. The release date was mentioned as 3rd and not 4th (today).Those are very minute things. Well done !!-- ChinthakaOn 10/4/06, Dinesh Premalal <[EMAIL PROTECTED]> wrote: We are pleased to announce the release of Apache Axis2/C version 0.94.You can download this release fromhttp://ws.apache.org/axis2/c/download.cgi Key Features 1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages. This has complete XML infoset support. 2. Support for one-way messaging (In-Only) and request response messaging (In-Out) 3. Description hierarchy (configuration, service groups, services, operations and messages) 4. Directory based deployment model 5. Archive based deployment model 6. Context hierarchy (corresponding contexts to map to each level of description hierarchy) 7. Raw XML message receiver 8. Module architecture, mechanism to extend the SOAP processing model 9. Module version support 10. Transports supports: HTTPo Both simple axis server and Apache2 httpd module for server side o Client transport with ability to enable SSL support 11. Service client and operation client APIs 12. REST support (HTTP POST case) 13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions 14. MTOM/XOP support 15. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool)o Axis Data Binding (ADB) support 16. Security module with UsernameToken support 17. REST support (HTTP GET case) 18. Dynamic invocation support (based on XML schema and WSDL implementations) 19. Guththila pull parser support - New 20. WSDL2C code generation tool- with schema code generation (experimental) - New 21. TCP Monitor - C implementation (experimental) - NewMajor Changes Since Last Release 1. Guththila pull parser support 2. WSDL2C code generation tool 3. TCP Monitor - C implementation 4. Major Memory leak fixes 5. Fixes to code generation with Java Tool 6. Many Bug FixesTODOs Remaining for 1.0 1. Complete API documentation and API improvements 2. Fix further memory leaks 3. Put in place a comprehensive functional test frameworkWe welcome your early feedback on this implementation.Thanks for your interest in Axis2C-- Apache Axis2C Team --- To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED] -- Eran ChinthakaLanka Software FoundationTel : (+94) 777 257633 E-Mail : [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-313) improve autoconf support
[ http://issues.apache.org/jira/browse/AXIS2C-313?page=comments#action_12439886 ] Chris Darroch commented on AXIS2C-313: -- Oh, and I meant to add that --libexecdir is probably the most GNU-ish place to install service and module libraries. I suspect that the directory structure of the Axis2/C project is largely derived from the Java one, and so these GNU-style package layout suggestions are probably somewhat at odds with that. However, in my case I'm installing it along with a lot of other packages, all of which follow the GNU standard, so these issues came to the forefront for me. For example, httpd modules that are compiled as dynamically loadable libraries live in $INSTALL_PATH/libexec, so it would be nice to have axis2 service and module libraries in there too. > improve autoconf support > > > Key: AXIS2C-313 > URL: http://issues.apache.org/jira/browse/AXIS2C-313 > Project: Axis2-C > Issue Type: Improvement > Components: build system (Unix/Linux) >Affects Versions: 0.93 > Environment: Unix/Linux, maybe Windows and others. >Reporter: Chris Darroch > > The autoconf system really isn't being used effectively for the axis2c > package. First, as noted > in another bug report, some of the code searches for libraries in > $AXIS2C_HOME/lib regardless > of what is specified by the user when using the --libdir configure option. > Second, it would be better if include files were installed in, say, > $includedir/axis2, the way > the APR project installs them in $includedir/apr-$majorversion and httpd > installs them > in $includedir/apache2. Given that 375 files are installed, this is > otherwise a major source > of pollution in a common location. > Third, if one uses --libdir, --includedir, and --bindir, then each successive > installation > of an axis2c sub-project (like xml_schema or woden) and the main axis2c > installation itself > should use these locations to search for dependencies. As it is, the util > sub-project > installs quite neatly, but then all the others require patches to their > Makefiles and/or specific > CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' > headers and libraries. This really shouldn't be necessary; they should look > in --libdir > and --includedir automatically. > Fourth, the various test suites that run when "make check" is used fail in a > wide variety of > ways. Many of the test suites depend on libcutest.a -- but this isn't > something the CuTest > package provides! Instead, you have to dig out a posting to the mailing list: > http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile > (An alternative would be the derived version that the APR test suite uses.) > Other tests > depend on data files that aren't in the distribution; for example, the > xml_schema tests > seem to require the files from > https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ > in a "resources" directory. The woden tests require a Calculator.wsdl file > that I found in > https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, > but it > required that the xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; attribute > *not* have a > trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The > util/test/util/test_util.c file calls run_test_string(env) after freeing the > env variable, producing > a segfault. And so forth. > Fifth, while I realize this would be a pain, it would be really superb if one > could control > the layout of the $AXIS2C_HOME location using the kinds of options provided > by the > config.layout file in the httpd package. More, instead of requiring > directories under > $AXIS2C_HOME named "logs", "services", "modules", and so forth, and requiring > that > the libraries in the services and modules directories be accompanied by XML > files, > it would be great if you could ask for a layout like this: > $prefix = $MY_INSTALL_DIR > $bindir = $prefix/bin (by default, use --bindir to change) > $includedir = $prefix/include/axis2 (by default, use --includedir to change) > $libdir = $prefix/lib/axis2 (by default, use --libdir to change) > $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) > $localstatedir = $prefix (by default, use --localstatedir to change) > $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml > to change) > $servicesdir = $libdir/services (by default, use config.layout or axis2.xml > to change) > $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to > change) > The axis2.xml file would be expected to reside in $sysconfdir. There would be > runtime options (like httpd's -f option) that would allow the user to point > to another > non-standard file, though. This file wo
[jira] Closed: (AXIS2C-320) Attachments handling mechanism is too restrictive
[ http://issues.apache.org/jira/browse/AXIS2C-320?page=all ] Samisa Abeysinghe closed AXIS2C-320. Resolution: Duplicate AXIS2C-281 is the same > Attachments handling mechanism is too restrictive > - > > Key: AXIS2C-320 > URL: http://issues.apache.org/jira/browse/AXIS2C-320 > Project: Axis2-C > Issue Type: Improvement > Environment: linux / windows >Reporter: Nandika Jayawardana >Priority: Critical > > Axis2c attachment handling mechanism is to save the attachment to a file. > This is a very restrictive mechanism and leads to many problems such as > security issues and file writing permission issues . Need a way to access the > attachment as a stream or a buffer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2][ANN]Apache Axis2/c 0.94 Released.
We are pleased to announce the release of Apache Axis2/C version 0.94. You can download this release from http://ws.apache.org/axis2/c/download.cgi Key Features 1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages. This has complete XML infoset support. 2. Support for one-way messaging (In-Only) and request response messaging (In-Out) 3. Description hierarchy (configuration, service groups, services, operations and messages) 4. Directory based deployment model 5. Archive based deployment model 6. Context hierarchy (corresponding contexts to map to each level of description hierarchy) 7. Raw XML message receiver 8. Module architecture, mechanism to extend the SOAP processing model 9. Module version support 10. Transports supports: HTTP o Both simple axis server and Apache2 httpd module for server side o Client transport with ability to enable SSL support 11. Service client and operation client APIs 12. REST support (HTTP POST case) 13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions 14. MTOM/XOP support 15. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool) o Axis Data Binding (ADB) support 16. Security module with UsernameToken support 17. REST support (HTTP GET case) 18. Dynamic invocation support (based on XML schema and WSDL implementations) 19. Guththila pull parser support - New 20. WSDL2C code generation tool- with schema code generation (experimental) - New 21. TCP Monitor - C implementation (experimental) - New Major Changes Since Last Release 1. Guththila pull parser support 2. WSDL2C code generation tool 3. TCP Monitor - C implementation 4. Major Memory leak fixes 5. Fixes to code generation with Java Tool 6. Many Bug Fixes TODOs Remaining for 1.0 1. Complete API documentation and API improvements 2. Fix further memory leaks 3. Put in place a comprehensive functional test framework We welcome your early feedback on this implementation. Thanks for your interest in Axis2C -- Apache Axis2C Team -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-321) Registered handlers not invoked at all on REST GET requests
[
http://issues.apache.org/jira/browse/AXIS2C-321?page=comments#action_12439859 ]
Samisa Abeysinghe commented on AXIS2C-321:
--
While agreeing we have to fix the hard coding, I am interested in knowing, what
sort of handlers you are interested in invoking when REST is in use.
Handlers *usually* deal with SOAP headers, hence when doing REST, my
understanding is that, you hardly need any handlers.
> Registered handlers not invoked at all on REST GET requests
> ---
>
> Key: AXIS2C-321
> URL: http://issues.apache.org/jira/browse/AXIS2C-321
> Project: Axis2-C
> Issue Type: Bug
> Components: core/engine
>Affects Versions: Current (Nightly), 0.93, 0.94
>Reporter: Jean-Sebastien Delfino
>
> Modules registered in the Dispatch phase are not invoked at all by the engine
> during the processing of REST / HTTP GET requests.
> The following code hardcodes a call to the req_uri_disp dispatcher. Instead
> it should call the handlers registered in the Dispatch phase like is done for
> regular Web Service requests.
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_http_transport_utils_dispatch_and_verify(
> const axis2_env_t *env,
> axis2_msg_ctx_t *msg_ctx)
> {
> axis2_disp_t *req_uri_disp = NULL;
> axis2_handler_t *handler = NULL;
> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
> AXIS2_PARAM_CHECK(env->error, msg_ctx, AXIS2_FAILURE);
> req_uri_disp = axis2_req_uri_disp_create(env);
> handler = AXIS2_DISP_GET_BASE(req_uri_disp, env);
> AXIS2_HANDLER_INVOKE(handler, env, msg_ctx);
> if(NULL == AXIS2_MSG_CTX_GET_SVC(msg_ctx, env) || NULL ==
> AXIS2_MSG_CTX_GET_OP(msg_ctx, env))
> {
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_SVC_OR_OP_NOT_FOUND,
> AXIS2_FAILURE);
> return AXIS2_FAILURE;
> }
> return AXIS2_SUCCESS;
> }
> This issue is blocking for us (the Tuscany project) and prevents us from
> using Axis2C to handle REST / GET requests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2_svc_client_get_options returns a "const" ?
Ishan De Silva wrote: Hi, The get_option function of the service client returns a const axis2_options_t pointer. The idea is that use would create options and would own options. Hence not need to access options from service client in your client program. Rather use the pointer to options that you passes to service client. Samisa... const axis2_options_t *AXIS2_CALL axis2_svc_client_get_options( const axis2_svc_client_t *svc_client, const axis2_env_t *env); This makes it difficult to use it in the following manner: const axis2_options_t *options = NULL; const axis2_char_t *old_action = NULL; options = AXIS2_SVC_CLIENT_GET_OPTIONS (svc_client, env); old_action = AXIS2_OPTIONS_GET_ACTION(options, env); AXIS2_OPTIONS_SET_ACTION(options, env, "new action"); /* problem here because set_action modifies options */ Is the const modifier required in this function? Cheers, Ishan. - 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]Code Freeze for 0.94 Release
I tagged the svn , uploaded the release files. I would like to declare that the code freeze is over. thanks, Dinesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
axis2_svc_client_get_options returns a "const" ?
Hi, The get_option function of the service client returns a const axis2_options_t pointer. const axis2_options_t *AXIS2_CALL axis2_svc_client_get_options( const axis2_svc_client_t *svc_client, const axis2_env_t *env); This makes it difficult to use it in the following manner: const axis2_options_t *options = NULL; const axis2_char_t *old_action = NULL; options = AXIS2_SVC_CLIENT_GET_OPTIONS (svc_client, env); old_action = AXIS2_OPTIONS_GET_ACTION(options, env); AXIS2_OPTIONS_SET_ACTION(options, env, "new action"); /* problem here because set_action modifies options */ Is the const modifier required in this function? Cheers, Ishan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
