[jira] Resolved: (AXIS2C-1309) Memory leaks in axis2_svc_client_set_proxy_with_auth()
[ https://issues.apache.org/jira/browse/AXIS2C-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1309. -- Resolution: Fixed Patch applied in revision 731496. Thank you very much for the patch Memory leaks in axis2_svc_client_set_proxy_with_auth() -- Key: AXIS2C-1309 URL: https://issues.apache.org/jira/browse/AXIS2C-1309 Project: Axis2-C Issue Type: Bug Components: core/clientapi Affects Versions: 1.5.0 Reporter: Dmitry Goncharov Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: axis2_svc_memleak.patch axis2_svc_client_set_proxy_with_auth() uses axiom_attribute_create(), but doesn't set axutil_generic_obj_set_free_func() to properly release the memory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1230) Added Axis2/C environment and formatted code in tcp mon code
[ https://issues.apache.org/jira/browse/AXIS2C-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1230. -- Resolution: Fixed Patch is applied in revision 731527. Thank you very much for the patch. However, modification to tcpmon_util.h is not attached in the patch. I corrected it. Added Axis2/C environment and formatted code in tcp mon code Key: AXIS2C-1230 URL: https://issues.apache.org/jira/browse/AXIS2C-1230 Project: Axis2-C Issue Type: Improvement Components: tcpmon Environment: Fedora 9 Reporter: Rajika Kumarasiri Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: tcpmon.patch Axis2/C environment was added. Utility functions were moved to utils. Some code formatting were added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1311) Memory leaks in http_client.c
[ https://issues.apache.org/jira/browse/AXIS2C-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1311. -- Resolution: Fixed Patch applied in revision 731501. Thank you very much for the patch Memory leaks in http_client.c - Key: AXIS2C-1311 URL: https://issues.apache.org/jira/browse/AXIS2C-1311 Project: Axis2-C Issue Type: Bug Components: core/transport Affects Versions: 1.5.0 Reporter: Dmitry Goncharov Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: axis2_http_client.patch Different memory and socket leaks in http_client.c. Also a bug which makes an attempt to make an https connection though http proxy fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1241) uninitialised value in axis2_apache_out_transport_info_set_char_encoding
[ https://issues.apache.org/jira/browse/AXIS2C-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1241. -- Resolution: Fixed Fixed in revision 731520 uninitialised value in axis2_apache_out_transport_info_set_char_encoding Key: AXIS2C-1241 URL: https://issues.apache.org/jira/browse/AXIS2C-1241 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Environment: linux fc6 Reporter: Frederic Heem Assignee: S.Uthaiyashankar Fix For: 1.6.0 When apache is used with In-Out message, valgrind complains about Conditional jump or move depends on uninitialised value(s) Here is the backtrace: ==17491== Thread 5: ==17491== Conditional jump or move depends on uninitialised value(s) ==17491==at 0x40169FC: axis2_apache_out_transport_info_set_char_encoding (apache2_out_transport_info.c:110) ==17491==by 0x46D6ABB: axis2_http_out_transport_info_set_char_encoding (http_out_transport_info.c:238) ==17491==by 0x484582E: axis2_http_transport_sender_invoke (http_transport_sender.c:342) ==17491==by 0x461D862: axis2_engine_send (engine.c:176) ==17491==by 0x462C716: axis2_msg_recv_receive_impl (msg_recv.c:359) ==17491==by 0x462C83A: axis2_msg_recv_receive (msg_recv.c:436) ==17491==by 0x461DE74: axis2_engine_receive (engine.c:318) ==17491==by 0x401AB5B: axis2_http_transport_utils_process_http_post_request (http_transport_utils.c:659) ==17491==by 0x4018325: axis2_apache2_worker_process_request (apache2_worker.c:619) ==17491==by 0x4015752: axis2_handler (mod_axis2.c:373) ==17491==by 0x8071B27: ap_run_handler (in /usr/local/apache2/bin/httpd) ==17491==by 0x8073FEF: ap_invoke_handler (in /usr/local/apache2/bin/httpd) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1267) HTTP headers case sensitive in http_sender.c
[
https://issues.apache.org/jira/browse/AXIS2C-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar resolved AXIS2C-1267.
--
Resolution: Fixed
Patch applied in revision 731522. Thank you very much for the patch
HTTP headers case sensitive in http_sender.c
Key: AXIS2C-1267
URL: https://issues.apache.org/jira/browse/AXIS2C-1267
Project: Axis2-C
Issue Type: Bug
Components: core/transport
Affects Versions: 1.5.0
Reporter: Mats Staffansson
Assignee: S.Uthaiyashankar
Fix For: 1.6.0
Attachments: jira-1267.patch
Original Estimate: 0.08h
Remaining Estimate: 0.08h
HTTP headers should be compared case insensitive.
--- src/core/transport/http/sender/http_sender.c2008-09-18
11:25:39.0 +0200
+++ src/core/transport/http/sender/http_sender.c.patched2008-09-18
12:02:09.0 +0200
@@ -1471,7 +1471,7 @@
header, env);
if (name)
{
-if (0 == axutil_strcmp (name,
AXIS2_HTTP_HEADER_TRANSFER_ENCODING)
+if (0 == axutil_strcasecmp (name,
AXIS2_HTTP_HEADER_TRANSFER_ENCODING)
0 ==
axutil_strcmp (axis2_http_header_get_value (header, env),
AXIS2_HTTP_HEADER_TRANSFER_ENCODING_CHUNKED))
@@ -1485,7 +1485,7 @@
env, transfer_encoding);
}
-if (0 != axutil_strcmp (name, AXIS2_HTTP_HEADER_CONTENT_TYPE))
+if (0 != axutil_strcasecmp (name,
AXIS2_HTTP_HEADER_CONTENT_TYPE))
{
axis2_char_t *tmp_charset = NULL;
axis2_char_t *content_type =
[
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1241) uninitialised value in axis2_apache_out_transport_info_set_char_encoding
[ https://issues.apache.org/jira/browse/AXIS2C-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12660713#action_12660713 ] S.Uthaiyashankar commented on AXIS2C-1241: -- Problem is due to uninitialized axis2_http_out_transport_info-encoding. axis2_http_out_transport_info is created in axis2_apache2_out_transport_info_create. initializing axis2_http_out_transport_info-encoding to NULL solved the problem. uninitialised value in axis2_apache_out_transport_info_set_char_encoding Key: AXIS2C-1241 URL: https://issues.apache.org/jira/browse/AXIS2C-1241 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Environment: linux fc6 Reporter: Frederic Heem Assignee: S.Uthaiyashankar Fix For: 1.6.0 When apache is used with In-Out message, valgrind complains about Conditional jump or move depends on uninitialised value(s) Here is the backtrace: ==17491== Thread 5: ==17491== Conditional jump or move depends on uninitialised value(s) ==17491==at 0x40169FC: axis2_apache_out_transport_info_set_char_encoding (apache2_out_transport_info.c:110) ==17491==by 0x46D6ABB: axis2_http_out_transport_info_set_char_encoding (http_out_transport_info.c:238) ==17491==by 0x484582E: axis2_http_transport_sender_invoke (http_transport_sender.c:342) ==17491==by 0x461D862: axis2_engine_send (engine.c:176) ==17491==by 0x462C716: axis2_msg_recv_receive_impl (msg_recv.c:359) ==17491==by 0x462C83A: axis2_msg_recv_receive (msg_recv.c:436) ==17491==by 0x461DE74: axis2_engine_receive (engine.c:318) ==17491==by 0x401AB5B: axis2_http_transport_utils_process_http_post_request (http_transport_utils.c:659) ==17491==by 0x4018325: axis2_apache2_worker_process_request (apache2_worker.c:619) ==17491==by 0x4015752: axis2_handler (mod_axis2.c:373) ==17491==by 0x8071B27: ap_run_handler (in /usr/local/apache2/bin/httpd) ==17491==by 0x8073FEF: ap_invoke_handler (in /usr/local/apache2/bin/httpd) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1280) Headers don't compile with warnings turned on due to not entirely valid prototypes.
[ https://issues.apache.org/jira/browse/AXIS2C-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661059#action_12661059 ] S.Uthaiyashankar commented on AXIS2C-1280: -- this problem is due to -Wstrict-prototypes flag. Not because of -Werror flag.. Headers don't compile with warnings turned on due to not entirely valid prototypes. --- Key: AXIS2C-1280 URL: https://issues.apache.org/jira/browse/AXIS2C-1280 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: 1.5.0 Environment: gcc 3.4.4 with -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wno-missing-prototypes -Wno-unused Reporter: Eric Haszlakiewicz Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: axis_headers.diff Original Estimate: 0.25h Remaining Estimate: 0.25h The function prototypes in several header files cause problem when they are used with warnings turned on. The attached patch corrects the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1280) Headers don't compile with warnings turned on due to not entirely valid prototypes.
[ https://issues.apache.org/jira/browse/AXIS2C-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1280. -- Resolution: Fixed Patch applied in revision 731852. Thank you very much for the patch. Headers don't compile with warnings turned on due to not entirely valid prototypes. --- Key: AXIS2C-1280 URL: https://issues.apache.org/jira/browse/AXIS2C-1280 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: 1.5.0 Environment: gcc 3.4.4 with -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wno-missing-prototypes -Wno-unused Reporter: Eric Haszlakiewicz Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: axis_headers.diff Original Estimate: 0.25h Remaining Estimate: 0.25h The function prototypes in several header files cause problem when they are used with warnings turned on. The attached patch corrects the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1255) httpd takes considerable amount of time to load when secconv services are deployed with Global pool enabled.
[ https://issues.apache.org/jira/browse/AXIS2C-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1255: - Component/s: (was: build system (Unix/Linux)) httpd module httpd takes considerable amount of time to load when secconv services are deployed with Global pool enabled. Key: AXIS2C-1255 URL: https://issues.apache.org/jira/browse/AXIS2C-1255 Project: Axis2-C Issue Type: Bug Components: httpd module Reporter: Manjula Peiris This happens only when global pool is enabled. In order to run WSSeconv samples global pool should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-787) axutil_qname_to_string serialize with the prefix.
[ https://issues.apache.org/jira/browse/AXIS2C-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-787: Fix Version/s: 1.6.0 axutil_qname_to_string serialize with the prefix. - Key: AXIS2C-787 URL: https://issues.apache.org/jira/browse/AXIS2C-787 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: 1.2.0 Environment: Linux Ubuntu, But this is a bug in every platform Reporter: Dimuthu Gamage Assignee: Damitha Kumarage Fix For: 1.6.0 Currently the axutil_qname_to_serialize function serialize the qname with the prefix. localpart|namespace_uri|prefix This cause problems in comparing qnames, I.e. although axutil_qname_equals has get rid of this using different approaches (just not comparing prefixes), In other places like axiom this serialized strings kept in the hashes. (e.g. attribute hash in the element). This leads axiom_element_get_attribute not to work on occasions where the prefix of the given qname is different. This is a problem for interoperability. I think these bugs can be fixed if we remove the prefix in the serialized string generated from axutil_qname_to_string -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1323) Cannot enable libcurl and ssl together.
Cannot enable libcurl and ssl together. Key: AXIS2C-1323 URL: https://issues.apache.org/jira/browse/AXIS2C-1323 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Affects Versions: 1.5.0 Environment: Window XP Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: 1.6.0 When enable libcurl and ssl together, linking error occurs. http_client.c http_sender.c http_transport_sender.c ssl_stream.c ssl_utils.c Creating library ..\deploy\lib\axis2_http_sender.lib and object ..\deploy\lib\axis2_http_sender.exp http_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_s...@28 referenced in function _axis2_libcurl_http_s...@28 http_transport_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_cre...@4 referenced in function _axis2_http_transport_sender_cre...@4 http_transport_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_f...@8 referenced in function _axis2_http_transport_sender_f...@8 ..\deploy\lib\axis2_http_sender.dll : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.exe' : return code '0x460' Stop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1323) Cannot enable libcurl and ssl together.
[ https://issues.apache.org/jira/browse/AXIS2C-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1323. -- Resolution: Fixed Fixed in revision 731887 Cannot enable libcurl and ssl together. Key: AXIS2C-1323 URL: https://issues.apache.org/jira/browse/AXIS2C-1323 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Affects Versions: 1.5.0 Environment: Window XP Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: 1.6.0 When enable libcurl and ssl together, linking error occurs. http_client.c http_sender.c http_transport_sender.c ssl_stream.c ssl_utils.c Creating library ..\deploy\lib\axis2_http_sender.lib and object ..\deploy\lib\axis2_http_sender.exp http_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_s...@28 referenced in function _axis2_libcurl_http_s...@28 http_transport_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_cre...@4 referenced in function _axis2_http_transport_sender_cre...@4 http_transport_sender.obj : error LNK2019: unresolved external symbol _axis2_libcurl_f...@8 referenced in function _axis2_http_transport_sender_f...@8 ..\deploy\lib\axis2_http_sender.dll : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.exe' : return code '0x460' Stop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1169) axis2_http_server denial of service
[ https://issues.apache.org/jira/browse/AXIS2C-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1169. -- Resolution: Fixed Fixed in revision 731918. Caused by an endless-loop. axis2_http_server denial of service --- Key: AXIS2C-1169 URL: https://issues.apache.org/jira/browse/AXIS2C-1169 Project: Axis2-C Issue Type: Bug Components: samples Affects Versions: 1.4.0 Environment: linux fc6 Reporter: Frederic Heem Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: echoString.txt Use the following netcat command to trigger a 100% CPU for axis2_http_server: nc 127.0.0.1 9090 echoString.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1166) axis2_http_server remote crash
[ https://issues.apache.org/jira/browse/AXIS2C-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1166. -- Resolution: Fixed Fixed in revision 731933 axis2_http_server remote crash --- Key: AXIS2C-1166 URL: https://issues.apache.org/jira/browse/AXIS2C-1166 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.4.0 Environment: linux fc6 Reporter: Frederic Heem Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: echoString.txt Please run netcat as follows: nc 127.0.0.1 9090 echoString.txt This leads to a segmentation fault: ==17690== Thread 3: ==17690== Invalid read of size 4 ==17690==at 0x400F14A: axis2_http_header_create_by_str (http_header.c:64) ==17690==by 0x4012C2B: axis2_simple_http_svr_conn_read_request (simple_http_svr_conn.c:264) ==17690==by 0x316B496B: ??? ==17690== Address 0x4371796c is not stack'd, malloc'd or (recently) free'd ==17690== ==17690== Process terminating with default action of signal 11 (SIGSEGV) ==17690== Access not within mapped region at address 0x4371796C ==17690==at 0x400F14A: axis2_http_header_create_by_str (http_header.c:64) ==17690==by 0x4012C2B: axis2_simple_http_svr_conn_read_request (simple_http_svr_conn.c:264) ==17690==by 0x316B496B: ??? ==17690== ==17690== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 65 from 1) ==17690== malloc/free: in use at exit: 470,266 bytes in 10,435 blocks. ==17690== malloc/free: 17,660 allocs, 7,225 frees, 1,202,705 bytes allocated. ==17690== For counts of detected errors, rerun with: -v ==17690== searching for pointers to 10,435 not-freed blocks. ==17690== checked 21,606,456 bytes. ==17690== ==17690== LEAK SUMMARY: ==17690==definitely lost: 1,222 bytes in 45 blocks. ==17690== possibly lost: 272 bytes in 2 blocks. ==17690==still reachable: 468,772 bytes in 10,388 blocks. ==17690== suppressed: 0 bytes in 0 blocks. ==17690== Rerun with --leak-check=full to see details of leaked memory. Killed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1171) axis2_http_server remote crash, invalid read in axutil_stream_peek_socket
[ https://issues.apache.org/jira/browse/AXIS2C-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1171. -- Resolution: Fixed This issue got fixed when fixing AXIS2C-1166 axis2_http_server remote crash, invalid read in axutil_stream_peek_socket - Key: AXIS2C-1171 URL: https://issues.apache.org/jira/browse/AXIS2C-1171 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.4.0 Environment: linux fc6 Reporter: Frederic Heem Assignee: S.Uthaiyashankar Fix For: 1.6.0 Attachments: echoStringAxutil_stream_peek_socket.txt The following netcat command makes axis2_http_server crash nc 127.0.0.1 9090 echoStringAxutil_stream_peek_socket.txt Here the valgrind output: ==32180== Thread 3: ==32180== Invalid read of size 4 ==32180==at 0x404CB40: axutil_stream_peek_socket (stream.c:650) ==32180==by 0x4012A0D: axis2_simple_http_svr_conn_read_request (simple_http_svr_conn.c:164) ==32180==by 0x7A5A5336: ??? ==32180== Address 0x53794645 is not stack'd, malloc'd or (recently) free'd ==32180== ==32180== Process terminating with default action of signal 11 (SIGSEGV) ==32180== Access not within mapped region at address 0x53794645 ==32180==at 0x404CB40: axutil_stream_peek_socket (stream.c:650) ==32180==by 0x4012A0D: axis2_simple_http_svr_conn_read_request (simple_http_svr_conn.c:164) ==32180==by 0x7A5A5336: ??? ==32180== ==32180== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 65 from 1) ==32180== malloc/free: in use at exit: 467,710 bytes in 10,401 blocks. ==32180== malloc/free: 17,610 allocs, 7,209 frees, 1,197,675 bytes allocated. ==32180== For counts of detected errors, rerun with: -v ==32180== searching for pointers to 10,401 not-freed blocks. ==32180== checked 21,596,240 bytes. ==32180== ==32180== LEAK SUMMARY: ==32180==definitely lost: 1,222 bytes in 45 blocks. ==32180== possibly lost: 272 bytes in 2 blocks. ==32180==still reachable: 466,216 bytes in 10,354 blocks. ==32180== suppressed: 0 bytes in 0 blocks. ==32180== Rerun with --leak-check=full to see details of leaked memory. Killed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1187) HTTP Authentication related code should be moved to a separate method.
[ https://issues.apache.org/jira/browse/AXIS2C-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1187: - Fix Version/s: (was: 1.6.0) Assignee: (was: S.Uthaiyashankar) HTTP Authentication related code should be moved to a separate method. -- Key: AXIS2C-1187 URL: https://issues.apache.org/jira/browse/AXIS2C-1187 Project: Axis2-C Issue Type: Improvement Components: transport/http Affects Versions: Current (Nightly) Environment: Any Reporter: Nandika Jayawardana All the code related to HTTP Authentication is implemented in axis2_http_sender_send method. As a result, sender_send method has become very long and is difficult to maintain. Therefore HTTP Authentication code should be moved to separate methods and called from sender_send method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1281) A web service client should be allowed to turn off certificate validation when dealing with web service under https/SSL
[ https://issues.apache.org/jira/browse/AXIS2C-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1281: - Component/s: (was: core/engine) core/transport Assignee: S.Uthaiyashankar A web service client should be allowed to turn off certificate validation when dealing with web service under https/SSL --- Key: AXIS2C-1281 URL: https://issues.apache.org/jira/browse/AXIS2C-1281 Project: Axis2-C Issue Type: Bug Components: core/transport Affects Versions: 1.3.0 Environment: widnows, but I guess all other platformas too. web service client accessing https/SSL Reporter: Frank Zhou Assignee: S.Uthaiyashankar Priority: Minor Fix For: 1.6.0 Currently when a web service client try to access a web service under https/SSL, the client has to provide a valid certificate. We should make it as an option, that is, a client is allowed to choose not validate the certificate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1255) httpd takes considerable amount of time to load when secconv services are deployed with Global pool enabled.
[ https://issues.apache.org/jira/browse/AXIS2C-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1255: - Fix Version/s: 1.6.0 Assignee: S.Uthaiyashankar httpd takes considerable amount of time to load when secconv services are deployed with Global pool enabled. Key: AXIS2C-1255 URL: https://issues.apache.org/jira/browse/AXIS2C-1255 Project: Axis2-C Issue Type: Bug Components: httpd module Reporter: Manjula Peiris Assignee: S.Uthaiyashankar Fix For: 1.6.0 This happens only when global pool is enabled. In order to run WSSeconv samples global pool should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1236) Memory issues in Axis2/C service client
[ https://issues.apache.org/jira/browse/AXIS2C-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1236: - Fix Version/s: 1.6.0 Assignee: S.Uthaiyashankar Description: Some memory errors are cropping up when I run the client API through valgrind, some of which are leaks, others of which are problems with accessing previously-freed memory. When calling axis2_svc_client_send_receive, there is an invalid read from a previously-freed AXIOM node structure. This occurs during SOAP fault processing: ==17373== Invalid read of size 4 ==17373==at 0x4544A82: axiom_node_is_complete (om_node.c:991) ==17373==by 0x454E5FE: axiom_stax_builder_end_element (om_stax_builder.c:755) ==17373==by 0x454EF51: axiom_stax_builder_next_with_token (om_stax_builder.c:1154) ==17373==by 0x4558F9D: axiom_soap_builder_next (soap_builder.c:300) ==17373==by 0x455099D: axiom_soap_fault_get_reason (soap_fault.c:274) ==17373==by 0x4557791: axiom_soap_body_convert_fault_to_soap11 (soap_body.c:422) ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname (svc_client.c:932) ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949) ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487) ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084) ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404) ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982) ==17373== Address 0x4455bb8 is 32 bytes inside a block of size 40 free'd ==17373==at 0x400543C: free (vg_replace_malloc.c:323) ==17373==by 0x4519EA3: axutil_allocator_free_impl (allocator.c:91) ==17373==by 0x4543886: axiom_node_free_detached_subtree (om_node.c:154) ==17373==by 0x4543760: axiom_node_free_detached_subtree (om_node.c:106) ==17373==by 0x45438BC: axiom_node_free_tree (om_node.c:178) ==17373==by 0x4557765: axiom_soap_body_convert_fault_to_soap11 (soap_body.c:413) ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname (svc_client.c:932) ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949) ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487) ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084) ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404) ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982) ==17373== ==17373== Invalid read of size 4 ==17373==at 0x4544883: axiom_node_get_parent (om_node.c:876) ==17373==by 0x454E617: axiom_stax_builder_end_element (om_stax_builder.c:757) ==17373==by 0x454EF51: axiom_stax_builder_next_with_token (om_stax_builder.c:1154) ==17373==by 0x4558F9D: axiom_soap_builder_next (soap_builder.c:300) ==17373==by 0x455099D: axiom_soap_fault_get_reason (soap_fault.c:274) ==17373==by 0x4557791: axiom_soap_body_convert_fault_to_soap11 (soap_body.c:422) ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname (svc_client.c:932) ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949) ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487) ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084) ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404) ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982) ==17373== Address 0x4455ba0 is 8 bytes inside a block of size 40 free'd ==17373==at 0x400543C: free (vg_replace_malloc.c:323) ==17373==by 0x4519EA3: axutil_allocator_free_impl (allocator.c:91) ==17373==by 0x4543886: axiom_node_free_detached_subtree (om_node.c:154) ==17373==by 0x4543760: axiom_node_free_detached_subtree (om_node.c:106) ==17373==by 0x45438BC: axiom_node_free_tree (om_node.c:178) ==17373==by 0x4557765: axiom_soap_body_convert_fault_to_soap11 (soap_body.c:413) ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname (svc_client.c:932) ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949) ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487) ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084) ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404) ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982) ==17373== ==17373== Invalid write of size 4 ==17373==at 0x4544ED1: axiom_node_set_complete (om_node.c:1117) ==17373==by 0x454E63A: axiom_stax_builder_end_element (om_stax_builder.c:760) ==17373==by 0x454EF51: axiom_stax_builder_next_with_token (om_stax_builder.c:1154) ==17373==by 0x4558F9D: axiom_soap_builder_next (soap_builder.c:300) ==17373==by 0x455099D: axiom_soap_fault_get_reason (soap_fault.c:274) ==17373==by 0x4557791: axiom_soap_body_convert_fault_to_soap11 (soap_body.c:422) ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname (svc_client.c:932) ==17373==by 0x45BF082
[jira] Updated: (AXIS2C-1024) Neethi does not support ExactlyOne to allow using OR when defining two tokens where only one or the other is desired
[ https://issues.apache.org/jira/browse/AXIS2C-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1024: - Issue Type: New Feature (was: Bug) Neethi does not support ExactlyOne to allow using OR when defining two tokens where only one or the other is desired Key: AXIS2C-1024 URL: https://issues.apache.org/jira/browse/AXIS2C-1024 Project: Axis2-C Issue Type: New Feature Components: rampart Affects Versions: Current (Nightly) Environment: Windows XP. Reporter: Dave Meier The spec I'm looking at is http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf in section 4.1.1. The spec shows how to OR things together in the policy, but when I tried that it in rampart/c it didn't work. Here's what I tried (showing just the SignedSupportingTokens: sp:SignedSupportingTokens xmlns:sp=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy; wsp:Policy wsp:ExactlyOne sp:UsernameToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ sp:SamlToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ /wsp:ExactlyOne /wsp:Policy /sp:SignedSupportingTokens This should accept either UsernameToken or SamlToken. Also tried the following without success: sp:SignedSupportingTokens xmlns:sp=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy; wsp:Policy wsp:All wsp:ExactlyOne sp:UsernameToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ sp:SamlToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ /wsp:ExactlyOne /wsp:All /wsp:Policy /sp:SignedSupportingTokens -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1005) dual clients report an error in log
[ https://issues.apache.org/jira/browse/AXIS2C-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1005: - Fix Version/s: 1.6.0 dual clients report an error in log --- Key: AXIS2C-1005 URL: https://issues.apache.org/jira/browse/AXIS2C-1005 Project: Axis2-C Issue Type: Bug Components: xml/soap Affects Versions: Current (Nightly) Reporter: Dinesh Premalal Assignee: Senaka Fernando Fix For: 1.6.0 Although echo_blocking_dual and echo_non_blocking_dual clients executes successfully , they dump following message into log. [Tue Feb 26 15:30:01 2008] [error] libxml2_reader_wrapper.c(945) Extra content at the end of the document -- SEVERITY_ERROR [Tue Feb 26 15:30:01 2008] [error] libxml2_reader_wrapper.c(456) error occured in reading xml stream [Tue Feb 26 15:30:01 2008] [critical] soap_builder.c(812) SOAP message does not have a SOAP envelope element -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-677) Clone method required for axiom_node
[ https://issues.apache.org/jira/browse/AXIS2C-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-677: Issue Type: New Feature (was: Bug) Clone method required for axiom_node Key: AXIS2C-677 URL: https://issues.apache.org/jira/browse/AXIS2C-677 Project: Axis2-C Issue Type: New Feature Components: xml/om Reporter: Jamie Lyon There is no clone method for axiom_node in the current implementation of axiom/c, it should have one as the axiom/java version does. Without a clone method, there is no easy way to alter a tree without affecting the original. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-934) Organize Test Cases
[ https://issues.apache.org/jira/browse/AXIS2C-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-934: Fix Version/s: 1.6.0 Organize Test Cases --- Key: AXIS2C-934 URL: https://issues.apache.org/jira/browse/AXIS2C-934 Project: Axis2-C Issue Type: Task Components: tests Reporter: Senaka Fernando Assignee: Sanjaya Ratnaweera Fix For: 1.6.0 Hi all, recently we've added several test_cases, especially to util. They all do have a build.sh and are in an independent directory structure. BTW, some wont build, when I run the build.sh. :( Therefore, We need to, 1. Organize it to the original test_case directory structure. 2. Remove the build.sh and add it to the Makefiles. (both Unix and Windows, if it exists) 3. Make sure that they build, especially on Windows (this requires testing definition and declaration of variables) 4. Make sure that the configure option '--enable-tests' is enforced. 5. Minimize number of additional files, when you could add several related tests onto one file Regards, Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1204) memory leak for In-Only message with no parameter
[ https://issues.apache.org/jira/browse/AXIS2C-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1204: - Fix Version/s: 1.6.0 memory leak for In-Only message with no parameter - Key: AXIS2C-1204 URL: https://issues.apache.org/jira/browse/AXIS2C-1204 Project: Axis2-C Issue Type: Bug Components: core/receivers Affects Versions: 1.4.0 Environment: linux fc5 Reporter: Frederic Heem Assignee: Supun Kamburugamuva Fix For: 1.6.0 Fro In-Only message with no parameter, memory is leaked for each invokation of the service: ==24947== 819 (280 direct, 539 indirect) bytes in 7 blocks are definitely lost in loss record 48 of 53 ==24947==at 0x4005858: malloc (vg_replace_malloc.c:207) ==24947==by 0x402ABDD: axiom_node_create (om_node.c:75) ==24947==by 0x402E8D7: axiom_element_create (om_element.c:78) ==24947==by 0x4FA4874: ??? ==24947==by 0x409AC39: axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync (raw_xml_in_out_msg_recv.c:266) ==24947==by 0x4099F33: axis2_msg_recv_invoke_business_logic (msg_recv.c:392) ==24947==by 0x409A563: axis2_msg_recv_receive_impl (msg_recv.c:319) ==24947==by 0x4099FB3: axis2_msg_recv_receive (msg_recv.c:431) ==24947==by 0x408F638: axis2_engine_receive (engine.c:315) ==24947==by 0x401978D: axis2_http_transport_utils_process_http_post_request (http_transport_utils.c:595) ==24947==by 0x4016883: axis2_http_worker_process_request (http_worker.c:899) ==24947==by 0x411DEE0: axis2_svr_thread_worker_func (http_svr_thread.c:259) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1232) SOAP builder builds the whole tree in order to find a soap_fault
[ https://issues.apache.org/jira/browse/AXIS2C-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1232: - Fix Version/s: 1.6.0 SOAP builder builds the whole tree in order to find a soap_fault Key: AXIS2C-1232 URL: https://issues.apache.org/jira/browse/AXIS2C-1232 Project: Axis2-C Issue Type: Bug Components: xml/soap Affects Versions: Current (Nightly) Reporter: Manjula Peiris Fix For: 1.6.0 axiom_soap_body_has_fault function does not stop searching for soap_fault when it failed to find such element as the first child of the soap_body. According to the SOAP specs the soap_fault element must be the first child of the soap_body if there is a fault. Further in SOAP 1.2 it should be the only child of SOAP body. This behavior of this function cause unnecessary building of om_tree for non fault cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-995) mod_axis2 fails to call svc_skeleton_free
[
https://issues.apache.org/jira/browse/AXIS2C-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar updated AXIS2C-995:
Fix Version/s: 1.6.0
mod_axis2 fails to call svc_skeleton_free
-
Key: AXIS2C-995
URL: https://issues.apache.org/jira/browse/AXIS2C-995
Project: Axis2-C
Issue Type: Bug
Components: core/transport
Affects Versions: 1.2.0
Environment: solaris 10 x86, apache 2.2.4
Reporter: Ben Wyckoff
Assignee: Supun Kamburugamuva
Fix For: 1.6.0
Attachments: mod_axis2_shut_down.patch
mod_axis2 calls AXIS2_SVC_SKELETON_INIT but never calls
AXIS2_SVC_SKELETON_FREE (or the equivalent), which leaves resources allocated
at init time dangling. The axis2_hhtp_server does properly call free,
allowing the service to properly clean up after itself.
This issue was submitted to the axis2-c users list, and Dumindu Pallewela
replied with the following patch.
Index: mod_axis2.c
===
--- mod_axis2.c (revision 629362)
+++ mod_axis2.c (working copy)
@@ -425,6 +425,19 @@
#endif
}
+typedef struct worker_cleanup_data
+{
+const axutil_env_t * env;
+axis2_apache2_worker_t * worker;
+} worker_cleanup_data_t;
+
+static apr_status_t worker_cleanup(void *data)
+{
+worker_cleanup_data_t *d = (worker_cleanup_data_t *) data;
+axis2_apache2_worker_free(d-worker, d-env);
+return APR_SUCCESS;
+}
+
static int axis2_post_config(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t
*ptemp, server_rec *svr_rec)
{
@@ -592,6 +605,14 @@
[Axis2] Error creating mod_axis2 apache2 worker);
exit(APEXIT_CHILDFATAL);
}
+else
+{
+worker_cleanup_data_t *data = apr_palloc(pconf,
sizeof(worker_cleanup_data_t));
+data-env = axutil_env;
+data-worker = axis2_worker;
+apr_pool_cleanup_register(pconf, data, worker_cleanup,
apr_pool_cleanup_null);
+}
+
return OK;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1222) Axis2/C AXIOM libxml2 parser frees the IO context before calling the AXIS2_CLOSE_INPUT_CALLBACK
[ https://issues.apache.org/jira/browse/AXIS2C-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1222: - Fix Version/s: 1.6.0 Axis2/C AXIOM libxml2 parser frees the IO context before calling the AXIS2_CLOSE_INPUT_CALLBACK --- Key: AXIS2C-1222 URL: https://issues.apache.org/jira/browse/AXIS2C-1222 Project: Axis2-C Issue Type: Bug Components: xml/parser Affects Versions: 1.4.0 Environment: Linux/Unix with libxml2 parser Reporter: Chris Rose Assignee: Supun Kamburugamuva Fix For: 1.6.0 Running under valgrind, I get this invalid read error: ==21882== Invalid read of size 4 ==21882==at 0x43F6F69: axiom_close_gstream (axis2c_util.c:246) ==21882==by 0x44F418F: axis2_libxml2_reader_wrapper_close_input_callback (libxml2_reader_wrapper.c:964) ==21882==by 0x451BD8C: xmlFreeParserInputBuffer (xmlIO.c:2307) ==21882==by 0x4571E6A: xmlTextReaderClose (xmlreader.c:2255) ==21882==by 0x44F381C: axis2_libxml2_reader_wrapper_free (libxml2_reader_wrapper.c:505) ==21882==by 0x44F2686: axiom_xml_reader_free (xml_reader.c:34) ==21882==by 0x444F914: axiom_stax_builder_free (om_stax_builder.c:909) ==21882==by 0x43F6D65: Axis2_axiom_deserialize_buffer (axis2c_util.c:152) ==21882==by 0x43F6820: Axis2c_cmd_svc_client (axis2c.c:419) ==21882==by 0x402EA62: TclEvalObjvInternal (tclBasic.c:3084) ==21882==by 0x402F56B: Tcl_EvalEx (tclBasic.c:3674) ==21882==by 0x4083D91: Tcl_FSEvalFile (tclIOUtil.c:1651) ==21882== Address 0x47616F0 is 0 bytes inside a block of size 56 free'd ==21882==at 0x400513F: free (vg_replace_malloc.c:233) ==21882==by 0x441AEA3: axutil_allocator_free_impl (allocator.c:91) ==21882==by 0x44F3804: axis2_libxml2_reader_wrapper_free (libxml2_reader_wrapper.c:500) ==21882==by 0x44F2686: axiom_xml_reader_free (xml_reader.c:34) ==21882==by 0x444F914: axiom_stax_builder_free (om_stax_builder.c:909) ==21882==by 0x43F6D65: Axis2_axiom_deserialize_buffer (axis2c_util.c:152) ==21882==by 0x43F6820: Axis2c_cmd_svc_client (axis2c.c:419) ==21882==by 0x402EA62: TclEvalObjvInternal (tclBasic.c:3084) ==21882==by 0x402F56B: Tcl_EvalEx (tclBasic.c:3674) ==21882==by 0x4083D91: Tcl_FSEvalFile (tclIOUtil.c:1651) ==21882==by 0x408C036: Tcl_Main (tclMain.c:292) ==21882==by 0x80486B3: main (in /home/rosec/install/fc/bin/tclsh8.4) From this I can see that in the libxml2 reader wrapper code, the context of the parser -- provided when the IO parser was created -- is freed before the close callback is invoked by calling xmlFreeTextReader. This is an error in this instance, because the context handle cannot simply be free()d, in our application it requires specific destructor work to occur. This might be a lack of undestanding of the purpose of the close callback, but it's clear that AXIS2_FREE is invoked on the context handle before the close callback is invoked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1223) Ws-Addressing Module, extracting information from EPR
[ https://issues.apache.org/jira/browse/AXIS2C-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1223: - Fix Version/s: 1.6.0 Ws-Addressing Module, extracting information from EPR - Key: AXIS2C-1223 URL: https://issues.apache.org/jira/browse/AXIS2C-1223 Project: Axis2-C Issue Type: Bug Components: core/addressing Affects Versions: 1.4.0, 1.4.1 Environment: Linux, Windows Reporter: Julien Billon Assignee: Damitha Kumarage Fix For: 1.6.0 Original Estimate: 0.17h Remaining Estimate: 0.17h According to the WS-Addressing specification, an EndPoint Reference (EPR) can be specified in the wsa:ReplyTo node. In the WS-Addressing Module, the function axis2_addr_in_extract_epr_information() is responsible for extracting the datas from an EPR. But if we look more closely at this function (around line 600), we see that the reference parameters are parsed and ... that's all ! these parameters are never stored in the EPR structure. Example : With a message like soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope\; xmlns:wsa=http://www.w3.org/2005/08/addressing; soapenv:Header wsa:Tohttp://example.com/services/echo/wsa:To wsa:Actionhttp://example.com/OTA_PINGRQ/wsa:Action wsa:MessageID6dc6e535-1a70-4544-9715-26f06cdcf7bb/wsa:MessageID wsa:ReplyTo wsa:Addresshttp://requester.com/wsa:Address wsa:ReferenceParameterstestexample/test/wsa:ReferenceParameters /wsa:ReplyTo /soapenv:Header soapenv:BodyTESTXMLBody/TEST/soapenv:Body /soapenv:Envelope We call the ws-addressing module to extract information from the soap header. Then if we call axis2_msg_ctx_get_reply_to() and axis2_endpoint_ref_get_ref_param_list() this last function always return NULL. Patch : File addr_in_handler.c Line 600 REPLACE om_ele = (axiom_element_t *) axiom_node_get_data_element(om_node, env); BY axis2_endpoint_ref_add_ref_param(endpoint_ref, env, om_node); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1180) SSL Communication and the CA certificate
[ https://issues.apache.org/jira/browse/AXIS2C-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1180: - Fix Version/s: 1.6.0 SSL Communication and the CA certificate Key: AXIS2C-1180 URL: https://issues.apache.org/jira/browse/AXIS2C-1180 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.3.0 Reporter: Frank Huebbers Assignee: Senaka Fernando Fix For: 1.6.0 I'm trying to get SSL communication going with Axis2/C for our application. To this end, I have followed the instructions from the manual, i.e., http://ws.apache.org/axis2/c/docs/axis2c_manual.html#ssl_client So far, I have configured the axis2.xml file to add the transportReceiver and transportSender and I am using the server's certificate (as explained in the manual using openssl to get the certificate) to set the SERVER_CERT parameter in the axis2.xml file. With this setup, everything works fine for me. Now, I have to mention that I'm not interested in SSL client authentication. All I'm interested in is that the communication between the client and our servers is encrypted. So, what I have not been able to do is get rid of the step of setting the SERVER_CERT parameter as i receive an error in http_sender.c stating that status_code 0. I'm thus wondering whether it's possible to not set the SERVER_CERT parameter (and I believe that this should be possible) and, if so, how I could accomplish this task. Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1197) CodeGenerationException thrown without info about input files problem.
[ https://issues.apache.org/jira/browse/AXIS2C-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1197: - Fix Version/s: 1.6.0 CodeGenerationException thrown without info about input files problem. -- Key: AXIS2C-1197 URL: https://issues.apache.org/jira/browse/AXIS2C-1197 Project: Axis2-C Issue Type: Bug Components: code generation, wsdl2c tool Affects Versions: 1.4.0 Environment: Windows XP Professional Java Sun SE6 1.6.0_05-b13 Reporter: Daniel Gorodowienko Assignee: Milinda Lakmal Pathirage Fix For: 1.6.0 Attachments: siri-1.0modified.zip An exception thrown without pointing for location of problem in input files. Input files included as an attachment 'siri-1.0modified.zip'. They are seem to be right. oXygen handles it right and gSOAP almost (excluding subsequences, but code for the rest is generated). Command used to generate source: java org.apache.axis2.wsdl.WSDL2C -uri siri_wsProducer.wsdl -ss -sd -d adb -u Output: Retrieving document at 'siri_wsProducer.wsdl'. Retrieving schema wsdl:imported from 'siri.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_wsProducer.wsdl'. Retrieving schema at 'siri_common.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri.xsd'. Retrieving schema at 'ref/siri_location-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_common.xsd'. Retrieving schema at 'ref/siri_requests-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_common.xsd'. Retrieving schema at 'siri_types-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_requests-v1.0.xsd'. Retrieving schema at '../xml/xml.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_types-v1.0.xsd'. Retrieving schema at 'siri_location-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_requests-v1.0.xsd'. Retrieving schema at 'siri_productionTimetable_service.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri.xsd'. Retrieving schema at 'ref/siri_requests-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_productionTimetable_service.xsd'. Retrieving schema at 'ref/siri_journey-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_productionTimetable_service.xsd'. Retrieving schema at 'siri_facility-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_journey-v1.0.xsd'. Retrieving schema at 'siri_reference-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_facility-v1.0.xsd'. Retrieving schema at 'siri_types-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_reference-v1.0.xsd'. Retrieving schema at 'siri_location-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_reference-v1.0.xsd'. Retrieving schema at 'siri_time-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_reference-v1.0.xsd'. Retrieving schema at 'siri_facilities-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_facility-v1.0.xsd'. Retrieving schema at 'siri_time-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_facility-v1.0.xsd'. Retrieving schema at 'siri_reference-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_journey-v1.0.xsd'. Retrieving schema at 'ref/siri_permissions-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_productionTimetable_service.xsd'. Retrieving schema at 'siri_requests-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_permissions-v1.0.xsd'. Retrieving schema at 'siri_reference-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/ref/siri_permissions-v1.0.xsd'. Retrieving schema at 'ref/siri_reference-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_productionTimetable_service.xsd'. Retrieving schema at 'siri_common.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_productionTimetable_service.xsd'. Retrieving schema at 'siri_estimatedTimetable_service.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri.xsd'. Retrieving schema at 'ref/siri_requests-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_estimatedTimetable_service.xsd'. Retrieving schema at 'ref/siri_journey-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_estimatedTimetable_service.xsd'. Retrieving schema at 'ref/siri_permissions-v1.0.xsd', relative to 'file:/C:/axis2c-bin-1.4.0-win32/siri-1.0/siri_estimatedTimetable_service.xsd'. Retrieving schema at 'siri_stopMonitoring_service.xsd', relative
[jira] Updated: (AXIS2C-1227) engine not freed when server return an error
[ https://issues.apache.org/jira/browse/AXIS2C-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1227: - Fix Version/s: 1.6.0 engine not freed when server return an error Key: AXIS2C-1227 URL: https://issues.apache.org/jira/browse/AXIS2C-1227 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Environment: linux fc6 Reporter: Frederic Heem Assignee: Damitha Kumarage Fix For: 1.6.0 Attachments: http_worker.patch In http_worker.c at line 1181, the engine is created but not destroyed, this happens when the server returns a fault. ==17539== 12 bytes in 3 blocks are definitely lost in loss record 4 of 103 ==17539==at 0x4005858: malloc (vg_replace_malloc.c:207) ==17539==by 0x4091E75: axis2_engine_create (engine.c:52) ==17539==by 0x4016B40: axis2_http_worker_process_request (http_worker.c:1181) ==17539==by 0x4123ED0: axis2_svr_thread_worker_func (http_svr_thread.c:259) ==17539==by 0x405EEE5: dummy_worker (thread_unix.c:93) ==17539==by 0x8E145A: start_thread (in /lib/libpthread-2.5.so) ==17539==by 0x71323D: clone (in /lib/libc-2.5.so) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1262) Leaking a axiom_soap_envelope_t in axiom_soap_builder_create error path
[ https://issues.apache.org/jira/browse/AXIS2C-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1262: - Fix Version/s: 1.6.0 Leaking a axiom_soap_envelope_t in axiom_soap_builder_create error path --- Key: AXIS2C-1262 URL: https://issues.apache.org/jira/browse/AXIS2C-1262 Project: Axis2-C Issue Type: Bug Components: xml/soap Affects Versions: 1.5.0 Reporter: Sebastien Bigot Assignee: Supun Kamburugamuva Fix For: 1.6.0 Attachments: jira-1262.patch Original Estimate: 0.02h Remaining Estimate: 0.02h We're leaking memory in case we can't decode the soap envelope creating the axiom_soap_builder_t (in this case, wrong soap NS). [Wed Sep 10 09:58:33 2008] [error] soap_builder.c(886) AXIS2_ERROR_TRANSPORT_LEVEL_INFORMATION_DOES_NOT_MATCH_WITH_SOAP ==31384== 48 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==31384==at 0x4A1A0A7: malloc (vg_replace_malloc.c:207) ==31384==by 0x6746A5: axutil_allocator_malloc_impl (allocator.c:78) ==31384==by 0x65E907: axiom_soap_envelope_create_null (soap_envelope.c:59) ==31384==by 0x66037A: axiom_soap_builder_construct_node (soap_builder.c:546) ==31384==by 0x65FE86: axiom_soap_builder_create_om_element (soap_builder.c:352) ==31384==by 0x65FD8D: axiom_soap_builder_next (soap_builder.c:314) ==31384==by 0x65FC19: axiom_soap_builder_get_soap_envelope (soap_builder.c:242) ==31384==by 0x660C98: axiom_soap_builder_identify_soap_version (soap_builder.c:844) ==31384==by 0x65F9C3: axiom_soap_builder_create (soap_builder.c:140) ==31384==by 0x4A5A82: cmg::axis::CreateSoapBuilder(boost::shared_ptraxutil_env const, boost::shared_ptraxiom_xml_reader const) (Axis.cpp:123) ==31384==by 0x56B0F7: cmg::transport::ConvMapperSoapInterface::decode(CMG_Message) (ConvMapperSoapInterface.cpp:65) ==31384==by 0x43954A: testNew1ASoapConvMapper() (CMG_Tests1ASoap.cpp:80) ==31384==by 0x439865: Test1ASoap() (CMG_Tests1ASoap.cpp:216) ==31384==by 0x437DA5: Interactive() (CMG_Tests.cpp:362) ==31384==by 0x43847F: main (CMG_Tests.cpp:643) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1261) When several fire and forget sends are done using svc client it segfaults
[ https://issues.apache.org/jira/browse/AXIS2C-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1261: - Fix Version/s: 1.6.0 When several fire and forget sends are done using svc client it segfaults - Key: AXIS2C-1261 URL: https://issues.apache.org/jira/browse/AXIS2C-1261 Project: Axis2-C Issue Type: Bug Components: core/clientapi Reporter: Damitha Kumarage Fix For: 1.6.0 $Subject happens because in operation client the sending is done using separate thread. Before the first request completes it could happen that the second request free the operation client that is used to send the first message. When operation client execute is called from services clients fire and forget function it set send blokcing to true. When I fixed this to false the above segfaut and the problem causing it dissapear. This is because no more thread are spawned and sends are done sequentially. Following the diff of my simple fix. If there is no objection I will commit the change Index: src/core/clientapi/svc_client.c === --- src/core/clientapi/svc_client.c (revision 693316) +++ src/core/clientapi/svc_client.c (working copy) @@ -663,7 +663,7 @@ } axis2_op_client_add_out_msg_ctx(svc_client-op_client, env, msg_ctx); -axis2_op_client_execute(svc_client-op_client, env, AXIS2_FALSE); +axis2_op_client_execute(svc_client-op_client, env, AXIS2_TRUE); axis2_svc_client_set_http_info(svc_client, env, msg_ctx); svc_client-auth_failed = axis2_msg_ctx_get_auth_failed(msg_ctx, env); svc_client-required_auth_is_http = -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1274) Savan/C seg faults when run with Apache2
[ https://issues.apache.org/jira/browse/AXIS2C-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1274: - Fix Version/s: 1.6.0 Savan/C seg faults when run with Apache2 Key: AXIS2C-1274 URL: https://issues.apache.org/jira/browse/AXIS2C-1274 Project: Axis2-C Issue Type: Bug Components: savan Reporter: Damitha Kumarage Fix For: 1.6.0 When running with Apache2 following seg fault occurs with following #0 0xb7f52410 in __kernel_vsyscall () #1 0xb7d18085 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7d19a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d50b7c in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7d5c61b in free () from /lib/tls/i686/cmov/libc.so.6 #5 0xb795d5d2 in savan_util_apply_filter (subscriber=0x82b2e20, env=0xe, payload=0x82a21f0) at savan_util.c:256 #6 0xb795aeb1 in savan_subscriber_publish (subscriber=0x82b2e20, env=0x82a1908, payload=0x82a21f0) at savan_subscriber.c:425 #7 0xb795a6ce in savan_publishing_client_publish (client=0x82a2188, env=0x82a1908, payload=0x82a21f0) at savan_publishing_client.c:178 #8 0xb7b0f03e in publisher_worker_func (thrd=0x82a18e0, data=0x82a18d8) at publisher_skeleton.c:258 #9 0xb7c431b6 in dummy_worker (opaque=0x82a18e0) at thread_unix.c:93 #10 0xb7e454fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb7dc3e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Valgrind shows Thread 2: ==13943== Invalid free() / delete / delete[] ==13943==at 0x402265C: free (vg_replace_malloc.c:323) ==13943==by 0x49CC5D1: savan_util_apply_filter (savan_util.c:256) ==13943==by 0x49C9EB0: savan_subscriber_publish (savan_subscriber.c:425) ==13943==by 0x49C96CD: savan_publishing_client_publish (savan_publishing_client.c:178) ==13943==by 0x486703D: publisher_worker_func (publisher_skeleton.c:258) ==13943==by 0x47481B5: dummy_worker (thread_unix.c:93) ==13943==by 0x41244FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so) ==13943==by 0x4211E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so) ==13943== Address 0x45d6668 is 17,464 bytes inside a block of size 20,480 alloc'd ==13943==at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==13943==by 0x40D05FD: allocator_alloc (apr_pools.c:323) ==13943==by 0x40D0A26: apr_palloc (apr_pools.c:653) ==13943==by 0x4692A08: axis2_module_malloc (mod_axis2.c:389) ==13943==by 0x4029204: guththila_buffer_init (guththila_buffer.c:37) ==13943==by 0x40317AD: guththila_create_xml_stream_writer_for_memory (guththila_xml_writer.c:185) ==13943==by 0x476BFB9: axiom_xml_writer_create_for_memory (guththila_xml_writer_wrapper.c:311) ==13943==by 0x4711C45: axiom_node_to_string (om_node.c:1200) ==13943==by 0x49CC4BF: savan_util_apply_filter (savan_util.c:210) ==13943==by 0x49C9EB0: savan_subscriber_publish (savan_subscriber.c:425) ==13943==by 0x49C96CD: savan_publishing_client_publish (savan_publishing_client.c:178) ==13943==by 0x486703D: publisher_worker_func (publisher_skeleton.c:258) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-661) There is no OM model in generated payloads. Thus failing C14N.
[ https://issues.apache.org/jira/browse/AXIS2C-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-661: Fix Version/s: 1.6.0 There is no OM model in generated payloads. Thus failing C14N. -- Key: AXIS2C-661 URL: https://issues.apache.org/jira/browse/AXIS2C-661 Project: Axis2-C Issue Type: New Feature Components: code generation Environment: UNIX, Win32 Reporter: Malinda Kaushalye Kapuruge Assignee: Milinda Lakmal Pathirage Fix For: 1.6.0 When the code generation tool is used, the AXIOM model fails to give the child nodes. This causes problems to the C14N algorithm in Rampart/C. The reason is that the payload is kept as a stream(for efficinecy). So there should be a way to specify the codegen tool to select between keeping the payload as a stream or as an infoset model. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1336) Windows build system for axiom xpath library needed.
Windows build system for axiom xpath library needed. - Key: AXIS2C-1336 URL: https://issues.apache.org/jira/browse/AXIS2C-1336 Project: Axis2-C Issue Type: Improvement Components: build system (Windows) Affects Versions: Current (Nightly) Environment: Windows Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: 1.6.0 xpath functionality does not include windows build system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1333) Wrong include file / type generated for axutil_array_list_t types
[ https://issues.apache.org/jira/browse/AXIS2C-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1333: - Fix Version/s: (was: 1.5.0) 1.6.0 Wrong include file / type generated for axutil_array_list_t types - Key: AXIS2C-1333 URL: https://issues.apache.org/jira/browse/AXIS2C-1333 Project: Axis2-C Issue Type: Bug Components: wsdl2c tool Affects Versions: 1.5.0 Environment: Scientific Linux 4 Reporter: Zsolt Molnar Fix For: 1.6.0 The generated code out of the WSDL copied at the end of the report generates wrong C code. The code contains definitely wrong lines like #include adb_axutil_array_list_t*.h and wants to use the adb_axutil_array_list_t* name as part of function names, etc. Suspicion is that the code wants to refer to the axutil_array_list_t type, and include the axutil_array_list.h file form the Axis/C header file set. The command used for code generation: WSDL2C.sh -uri fts-channel-management.wsdl -ss -u -o src The WSDL: - START ?xml version=1.0 encoding=UTF-8? wsdl:definitions name=transfer-cli targetNamespace=http://glite.org/wsdl/services/org.glite.data.transfer.channel; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:tns=http://glite.org/wsdl/services/org.glite.data.transfer.channel; wsdl:types xsd:schema targetNamespace=http://glite.org/wsdl/services/org.glite.data.transfer.channel; xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding/; schemaLocation=http://schemas.xmlsoap.org/soap/encoding/; / xsd:complexType name=ArrayOfString xsd:complexContent mixed=false xsd:restriction base=soapenc:Array xsd:attribute ref=soapenc:arrayType wsdl:arrayType=soapenc:string[] / /xsd:restriction /xsd:complexContent /xsd:complexType xsd:element name=listChannelsResponseElement xsd:complexType xsd:sequence xsd:element name=out type=tns:ArrayOfString / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=TransferExceptionType xsd:sequence xsd:element name=message nillable=true type=soapenc:string / /xsd:sequence /xsd:complexType xsd:element name=InternalExceptionElement xsd:complexType xsd:complexContent xsd:extension base=tns:TransferExceptionType xsd:sequence / /xsd:extension /xsd:complexContent /xsd:complexType /xsd:element xsd:element name=AuthorizationExceptionElement xsd:complexType xsd:complexContent xsd:extension base=tns:TransferExceptionType xsd:sequence / /xsd:extension /xsd:complexContent /xsd:complexType /xsd:element /xsd:schema /wsdl:types wsdl:message name=listChannelsRequest / wsdl:message name=listChannelsResponse wsdl:part name=listChannelsReturn element=tns:listChannelsResponseElement / /wsdl:message wsdl:message name=AuthorizationException wsdl:part name=fault element=tns:AuthorizationExceptionElement / /wsdl:message wsdl:message name=InternalException wsdl:part name=fault element=tns:InternalExceptionElement / /wsdl:message wsdl:portType name=ChannelManagement wsdl:operation
[jira] Resolved: (AXIS2C-1336) Windows build system for axiom xpath library needed.
[ https://issues.apache.org/jira/browse/AXIS2C-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1336. -- Resolution: Fixed Fixed in revision 738031. Windows build system for axiom xpath library needed. - Key: AXIS2C-1336 URL: https://issues.apache.org/jira/browse/AXIS2C-1336 Project: Axis2-C Issue Type: Improvement Components: build system (Windows) Affects Versions: Current (Nightly) Environment: Windows Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: 1.6.0 xpath functionality does not include windows build system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1342) When enable persistOperationContext parameter in axis2.xml, server crashes.
When enable persistOperationContext parameter in axis2.xml, server crashes. -- Key: AXIS2C-1342 URL: https://issues.apache.org/jira/browse/AXIS2C-1342 Project: Axis2-C Issue Type: Bug Components: core/description, core/engine Affects Versions: Current (Nightly) Environment: WinXP, possibly Linux as well Reporter: S.Uthaiyashankar Fix For: 1.6.0 When enable parameter name=persistOperationContext locked=falsetrue/parameter in axis2.xml and send large number of requests (1 in 10 concurrent requests) using ab, httpd crashes. (It seems, simple axis2 server does NOT crashes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1352) dynamic invocation fails
dynamic invocation fails Key: AXIS2C-1352 URL: https://issues.apache.org/jira/browse/AXIS2C-1352 Project: Axis2-C Issue Type: Bug Components: core/clientapi Affects Versions: 1.4.0 Environment: linux (RHEL5) Reporter: AEGLE axis2_svc_client_create_for_dynamic_invocation fails with a 0 error code. Looking at the code in svc_client.c (line 183), it appears that it fails after : svc_client-options = axis2_options_create(env); The test on line 184 fails because svc_client-svc is NULL if (svc_client-svc) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1369) VC++ 2005 complie problem
VC++ 2005 complie problem - Key: AXIS2C-1369 URL: https://issues.apache.org/jira/browse/AXIS2C-1369 Project: Axis2-C Issue Type: Task Components: samples Affects Versions: 1.5.0 Environment: Windows XP SP2 (Simples chinese) Visual Studio 2005 C++ Microsoft Platform SDK for Windows XP SP2 Reporter: Yue Fix For: 1.5.0 When I'm trying compile the sample Server code of 'echo'. The VC++ though out the errors : -- Build started: Project: echo_ser, Configuration: Debug Win32 -- Linking... Creating library D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.lib and object D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.exp MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at file://d:\My Documents\Visual Studio 2005\Projects\echo_ser\echo_ser\Debug\BuildLog.htm echo_ser - 2 error(s), 0 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == I have been try lots of way but still not working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AXIS2C-1369) VC++ 2005 complie problem
[ https://issues.apache.org/jira/browse/AXIS2C-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yue closed AXIS2C-1369. --- Resolution: Fixed VC++ 2005 complie problem - Key: AXIS2C-1369 URL: https://issues.apache.org/jira/browse/AXIS2C-1369 Project: Axis2-C Issue Type: Task Components: samples Affects Versions: 1.5.0 Environment: Windows XP SP2 (Simples chinese) Visual Studio 2005 C++ Microsoft Platform SDK for Windows XP SP2 Reporter: Yue Fix For: 1.5.0 When I'm trying compile the sample Server code of 'echo'. The VC++ though out the errors : -- Build started: Project: echo_ser, Configuration: Debug Win32 -- Linking... Creating library D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.lib and object D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.exp MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup D:\My Documents\Visual Studio 2005\Projects\echo_ser\Debug\echo_ser.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at file://d:\My Documents\Visual Studio 2005\Projects\echo_ser\echo_ser\Debug\BuildLog.htm echo_ser - 2 error(s), 0 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == I have been try lots of way but still not working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1244) Axis2/C HTTP transport sends SOAP calls twice when using BASIC auth
[ https://issues.apache.org/jira/browse/AXIS2C-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1244. -- Resolution: Fixed Patch applied in revision 778987. Thank you very much for the patch. Axis2/C HTTP transport sends SOAP calls twice when using BASIC auth --- Key: AXIS2C-1244 URL: https://issues.apache.org/jira/browse/AXIS2C-1244 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.4.0 Environment: Linux i686 Reporter: Chris Rose Assignee: S.Uthaiyashankar Priority: Blocker Fix For: Next Version Attachments: axis2c-1244.txt When I send a SOAP request using the built-in HTTP transport using HTTP-Basic authentication, the request ends up being sent two times. I've verified this with tcpmon, and I've stepped into the code to see that it's happening. The code that's doing this is in the 1.4.0 unix release tarball, in src/core/transport/http/sender/http_sender.c at line 973 (where force_http_auth is true due to an earlier call to axis2_options_set_http_auth_info with auth type = Basic) and then later in the false branch of the check on line 995, which starts on line 1054 of http_sender.c. The status code values from the initial calls don't seem to be checked, because they've plainly succeeded at this point. This is a dead-in-the-water blocker for us, with a release to a client coming up in four days. I don't have the time to upgrade to 1.5.0 on all of our tested platforms (because we're shipping this on Solaris as well, and that requires some patches to Axis2/C that we've got done for 1.4.0 and will be sending in one of these days). I realize it's a bit presumptuous, but could someone suggest a patch to this that would allow me to proceed? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
[ https://issues.apache.org/jira/browse/AXIS2C-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1375: - Fix Version/s: (was: 1.6.0) Next Version Assignee: S.Uthaiyashankar Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters Key: AXIS2C-1375 URL: https://issues.apache.org/jira/browse/AXIS2C-1375 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.6.0 Environment: windows XP Reporter: Frank Zhou Assignee: S.Uthaiyashankar Priority: Blocker Fix For: Next Version Attachments: testGuththilaBufferError.xml, testingCodeSnappet.cpp OK, since no one reply to my question, I have to debug the code and found out that guththila has a bug in managing buffer when seriazlize thea axiom tree (the soap structure) before actually send out the request, and I have a potential fix. This is really a critical bug I think, so I hope some developers can take a look at this problem. I am attaching the test input data and code snappet to reproduce the problem. Basically, the bug occurs in guththila_xml_writer.c. The guththila_xml_writer (I call it the soap serializer) maintains an array of buffers dynamically when it writes the soap structure into the buffers. The bug will occur in the following situation: Let's say I have an element ns1:doDeleteFirst12345/ns1:doDeleteFirst somewhere in the soap structure. Now before this element, there are lots of other elements, and when the guththila_xml_writer trys to process this element, the first buffer is ALMOST full, it does not have enough space to write the whole element name ns1:doDeleteFirst (the start tag) into the buffer, it has to create a new buffer, so it writes ns1: at the end of the first buffer (still a few more bytes left empty), and writes doDeleteFirst at the very beginning of the second buffer. The first buffer (Buffer length 16384): -- |**ns1:--| The second buffer (Buffer length 32768): --- |doDeleteFirst-| As the second buffer becomes the current buffer, when the writer trys to process the end tag (/ns1:doDeleteFirst), it uses an elem stack to track the namespace prefix and localname as in the following code: (starting from line 1396) elem-name = guththila_tok_list_get_token(wr-tok_list, env); elem-prefix = guththila_tok_list_get_token(wr-tok_list, env); elem-name-start = GUTHTHILA_BUF_POS(wr-buffer, elem_start); elem-name-size = elem_len; elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start); elem-prefix-size = pref_len; The macro GUTHTHILA_BUF_POS is defined as this: #ifndef GUTHTHILA_BUF_POS #define GUTHTHILA_BUF_POS(_buffer, _pos) ((_buffer).buff[(_buffer).cur_buff] + _pos - (_buffer).pre_tot_data) #endif The bug occurs when it calcuate elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start): The elem_pref_start has a value of 16375, the pre_tot_data has a value of 16379 (the first buffer length is 16384), they are calculated based on the first buffer data, but the current buffer is the second one, so elem-prefix-start points to gabage! I hope this makes sense to you. Use my test case you will see this quickly. When you run the same XML data I attached, first set a break point at line 392 in the file guththila_xml_writer_wrapper, and set the hit count as 514 in the break properties (the 514th element in ns1:doDeleteFirst), then debug step by step. The potential fix is to define GUTHTHILA_BUF_POS as the following: if ((_buffer)-pre_tot_data _pos) return ((_buffer)-buff[(_buffer)-cur_buff-1] + _pos); else return ((_buffer)-buff[(_buffer)-cur_buff] + _pos - (_buffer)-pre_tot_data); GUTHTHILA_BUF_POS is used everywhere, so I really hope some developer can take over this case and fix it! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1350) Adding hours/mins/secs etc to the duration does not add up correctly
[ https://issues.apache.org/jira/browse/AXIS2C-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1350: - Component/s: util Adding hours/mins/secs etc to the duration does not add up correctly Key: AXIS2C-1350 URL: https://issues.apache.org/jira/browse/AXIS2C-1350 Project: Axis2-C Issue Type: Bug Components: util Reporter: Damitha Kumarage axis2_char_t *duration_str = P19Y6M4DT12H30M5S; printf(input:%s\n, duration_str); axutil_duration_t *duration = NULL; axis2_char_t *result = NULL; duration = axutil_duration_create_from_string(env, duration_str); int hours = axutil_duration_get_hours(duration, env); axutil_duration_set_hours(duration, env, hours + 13); result = axutil_duration_serialize_duration(duration, env); printf(result:%s\n, result); The output of the above program should ideally be input:P19Y6M4DT12H30M5S result:P19Y6M5DT1H30M5.00S But it is actually is input:P19Y6M4DT12H30M5S result:P19Y6M4DT25H30M5.00S When hours exceed 24 it should be counted as 1 days and 1 hour instead of 25 hours. This problem is there for other time units as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1351) Added proper logging to annonymous service create method in svc_client
[ https://issues.apache.org/jira/browse/AXIS2C-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1351: - Component/s: core/clientapi Fix Version/s: Next Version Assignee: S.Uthaiyashankar Added proper logging to annonymous service create method in svc_client -- Key: AXIS2C-1351 URL: https://issues.apache.org/jira/browse/AXIS2C-1351 Project: Axis2-C Issue Type: Improvement Components: core/clientapi Environment: All Reporter: Rajika Kumarasiri Assignee: S.Uthaiyashankar Priority: Minor Fix For: Next Version Attachments: svc_client.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1362) Compile with -D_FORTIFY_SOURCE=2 results in warnings which fail build
[ https://issues.apache.org/jira/browse/AXIS2C-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1362: - Component/s: build system (Unix/Linux) Compile with -D_FORTIFY_SOURCE=2 results in warnings which fail build - Key: AXIS2C-1362 URL: https://issues.apache.org/jira/browse/AXIS2C-1362 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Environment: Configure command: CLASSPATH= CFLAGS=-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector CXXFLAGS=-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector CPPFLAGS= LDFLAGS=-g -O1 CC=gcc CXX=g++ ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info Reporter: Adam Chasen Priority: Minor There are warnings (which are treated as errors due to -Werror) which fail the build in: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector -D_LARGEFILE64_SOURCE -ansi -Wall -Werror -Wno-implicit-function-declaration -D_GNU_SOURCE -MT dir_handler.lo -MD -MP -MF .deps/dir_handler.Tpo -c -o dir_handler.lo dir_handler.c gcc -DHAVE_CONFIG_H -I. -I.. -I../include -O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector -D_LARGEFILE64_SOURCE -ansi -Wall -Werror -Wno-implicit-function-declaration -D_GNU_SOURCE -MT dir_handler.lo -MD -MP -MF .deps/dir_handler.Tpo -c dir_handler.c -fPIC -DPIC -o .libs/dir_handler.o cc1: warnings being treated as errors dir_handler.c: In function 'axutil_dir_handler_list_service_or_module_dirs': dir_handler.c:207: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result dir_handler.c:213: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result There may be other errors in util dir, I removed -Werror from configure in ./util to continue build make[3]: Entering directory `/tmp/rmake/builds/axis2c/axis2c-src-1.5.0/tools/tcpmon/src' gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include -I ../../../util/include -I ../../../axiom/include -I ../../../include -I ../include -D_LARGEFILE64_SOURCE -DAXIS2_GUTHTHILA_ENABLED -DAXIS2_SVR_MULTI_THREADED -O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector -D_LARGEFILE64_SOURCE -ansi -Wall -Werror -Wno-implicit-function-declaration -g -D_GNU_SOURCE -DAXIS2_GUTHTHILA_ENABLED -DAXIS2_SVR_MULTI_THREADED -MT tcpmon.o -MD -MP -MF .deps/tcpmon.Tpo -c -o tcpmon.o tcpmon.c cc1: warnings being treated as errors tcpmon.c: In function 'resend_request': tcpmon.c:658: warning: ignoring return value of 'fread', declared with attribute warn_unused_result There may be other errors , I removed -Werror from the configure in ./ to continue build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1385) Axis2/C Manual should include how to install CGI module
Axis2/C Manual should include how to install CGI module --- Key: AXIS2C-1385 URL: https://issues.apache.org/jira/browse/AXIS2C-1385 Project: Axis2-C Issue Type: Task Components: documentation Affects Versions: 1.6.0 Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: Next Version This information is available in the INSTALL file. We have to include it in Axis2/C Manual (html) as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1388) Memory leak AXIS2C
Memory leak AXIS2C -- Key: AXIS2C-1388 URL: https://issues.apache.org/jira/browse/AXIS2C-1388 Project: Axis2-C Issue Type: Bug Affects Versions: 1.6.0 Environment: AXIS2C - axis2c-1.6.0-5.i386 Generated code - Apache Axis2/Java version: 1.5 Built on : Apr 30, 2009 (06:07:24 EDT) Reporter: Kevin Priority: Critical I run a test that makes requests using the generated code and valgrind reports a large memory leak after afew minutes of running: ==23281== 15,782,780 (84,520 direct, 15,698,260 indirect) bytes in 324 blocks are definitely lost in loss record 32 of 33 ==23281==at 0x4028F3D: malloc (vg_replace_malloc.c:207) ==23281==by 0x43205CD: (within /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x4320C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42D3D5A: X509_LOOKUP_new (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42D40CD: X509_STORE_add_lookup (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42CC564: X509_STORE_load_locations (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x420D46D: SSL_CTX_load_verify_locations (in /usr/lib/libssl.so.0.9.8k) ==23281==by 0x41D6797: axis2_ssl_utils_initialize_ctx (ssl_utils.c:110) ==23281==by 0x41D61F0: axutil_stream_create_ssl (ssl_stream.c:96) ==23281==by 0x41D54D5: axis2_http_client_send (http_client.c:266) ==23281==by 0x41D29BC: axis2_http_sender_send (http_sender.c:1101) ==23281==by 0x41CDB8B: axis2_http_transport_sender_write_message (http_transport_sender.c:807) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1387) apache2_stream_read function ignores errors from ap_get_client_block is size_t is unsigned
[
https://issues.apache.org/jira/browse/AXIS2C-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar updated AXIS2C-1387:
-
Component/s: (was: build system (Unix/Linux))
httpd module
apache2_stream_read function ignores errors from ap_get_client_block is
size_t is unsigned
--
Key: AXIS2C-1387
URL: https://issues.apache.org/jira/browse/AXIS2C-1387
Project: Axis2-C
Issue Type: Bug
Components: httpd module
Affects Versions: 1.6.0
Environment: CentOS 5.3
httpd-2.2.3
rampartc-1.3.0
dell precision desktop
Reporter: Murph McCloy
Priority: Minor
Attachments: apache2_stream_read_input_filter.patch
Original Estimate: 1h
Remaining Estimate: 1h
This problem has only been noticed when attempting to decompress input
streams via apache.
The problem occurs when a decompression payload fails to decompress properly.
In my test case it was because the payload had some flags set in the gzip
headers and mod_deflate doesn't support flags. mod_deflate then returned an
APR_EGENERAL error message. This message then bubbled up and was returned as
a -1 to apache2_stream_read.
This is a problem because size_t, on my system, is unsigned. The checks in
apache2_stream_read fail to catch a negative value in this scenario and dont
respond appropriately.
while (count - len 0)
{
read = ap_get_client_block(stream_impl-request, (char *)buffer + len,
count - len);
if (read 0)
{
len += read;
}
else
{
break;
}
}
The else statement will never get reached while read is unsigned. Also, the
while loop might have troubles as well. I would suggest modifying read and
len to be ssize_t so they match the return value of ap_get_client_block.
If I get this modified and working, I will submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1390) When creating the build.sh script for C-language the flatten-file option is not properly used
[ https://issues.apache.org/jira/browse/AXIS2C-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1390: - Affects Version/s: 1.6.0 Fix Version/s: (was: 1.6.0) Next Version When creating the build.sh script for C-language the flatten-file option is not properly used - Key: AXIS2C-1390 URL: https://issues.apache.org/jira/browse/AXIS2C-1390 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: 1.6.0 Environment: Linux / 32-bit Reporter: Allan Schrum Priority: Minor Fix For: Next Version Attachments: CEmitter.java.diff Originally posted at https://issues.apache.org/jira/browse/AXIS2-4429 which is probably the wrong spot. When generating the build.sh script for a C-language output there are several options which affect the content of the build.sh script. For instance, the output directory name, the target source directory, and the flatten-files option. If the output directory is given then the current code ignores the flatten-file option when generating the script. Thus: wsdl2c.sh -uri something.wsdl -o here -f puts all the files in the subdirectory here but the build.sh script references the source files in src/*. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1388) Memory leak AXIS2C
[ https://issues.apache.org/jira/browse/AXIS2C-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1388: - Component/s: transport/http Memory leak AXIS2C -- Key: AXIS2C-1388 URL: https://issues.apache.org/jira/browse/AXIS2C-1388 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.6.0 Environment: AXIS2C - axis2c-1.6.0-5.i386 Generated code - Apache Axis2/Java version: 1.5 Built on : Apr 30, 2009 (06:07:24 EDT) Reporter: Kevin Priority: Critical I run a test that makes requests using the generated code and valgrind reports a large memory leak after afew minutes of running: ==23281== 15,782,780 (84,520 direct, 15,698,260 indirect) bytes in 324 blocks are definitely lost in loss record 32 of 33 ==23281==at 0x4028F3D: malloc (vg_replace_malloc.c:207) ==23281==by 0x43205CD: (within /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x4320C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42D3D5A: X509_LOOKUP_new (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42D40CD: X509_STORE_add_lookup (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x42CC564: X509_STORE_load_locations (in /usr/lib/libcrypto.so.0.9.8k) ==23281==by 0x420D46D: SSL_CTX_load_verify_locations (in /usr/lib/libssl.so.0.9.8k) ==23281==by 0x41D6797: axis2_ssl_utils_initialize_ctx (ssl_utils.c:110) ==23281==by 0x41D61F0: axutil_stream_create_ssl (ssl_stream.c:96) ==23281==by 0x41D54D5: axis2_http_client_send (http_client.c:266) ==23281==by 0x41D29BC: axis2_http_sender_send (http_sender.c:1101) ==23281==by 0x41CDB8B: axis2_http_transport_sender_write_message (http_transport_sender.c:807) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1384) axutil_date_time_get_date is misnamed, it should be axutil_date_time_get_day
[
https://issues.apache.org/jira/browse/AXIS2C-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar updated AXIS2C-1384:
-
Component/s: util
Fix Version/s: Next Version
axutil_date_time_get_date is misnamed, it should be axutil_date_time_get_day
Key: AXIS2C-1384
URL: https://issues.apache.org/jira/browse/AXIS2C-1384
Project: Axis2-C
Issue Type: Bug
Components: util
Affects Versions: 1.6.0
Environment: all
Reporter: Patrick Cosmo
Priority: Minor
Fix For: Next Version
Attachments: axutil_date_time.h, date_time.c, date_time_test.c, rand.c
when decoding a date, in axutil_date_time.h there is a method for extracting
year, month, etc, but not for day.
However, there is a method named: axutil_date_time_get_date( ... )
If you look at the implementation of this in date_time.c, it's actually
extracting the day:
AXIS2_EXTERN int AXIS2_CALL
axutil_date_time_get_date(
axutil_date_time_t *date_time,
const axutil_env_t *env)
{
return (date_time-day);
}
I think this function should be named axutil_date_time_get_day
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1367) sprintf format I32d not supported by Visual C++ 6.0
[ https://issues.apache.org/jira/browse/AXIS2C-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1367: - Component/s: (was: code generation) util sprintf format I32d not supported by Visual C++ 6.0 --- Key: AXIS2C-1367 URL: https://issues.apache.org/jira/browse/AXIS2C-1367 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: 1.4.0, 1.4.1, 1.5.0, 1.6.0 Environment: Microsoft Windows Visual C++ 6.0 Reporter: Eric Hsiung The following are defined in axutil_utils_defines.h: #if defined(WIN32) #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %I64d #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %I64u #define AXIS2_PRINTF_INT32_FORMAT_SPECIFIER %I32d #define AXIS2_PRINTF_UINT32_FORMAT_SPECIFIER %I32u #else #if __WORDSIZE == 64 #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %ld #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %lu #else #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %lld #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %llu #endif #define AXIS2_PRINTF_INT32_FORMAT_SPECIFIER %d #define AXIS2_PRINTF_UINT32_FORMAT_SPECIFIER %u #endif Microsoft Visual C++ 6.0 does not support I32 in the format string (though it does support I64). sprintf(szBuf, AXIS2_PRINTF_INT32_FORMAT_SPECIFIER, 123456) yields the string I32d. This of course leads to invalid SOAP messages and various errors. The fix is to use _MSC_VER to conditionally compile different format strings for VC++6 versus later versions of VC++ (which do support I32) like this: #if defined(WIN32) #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %I64d #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %I64u #if _MSC_VER 1200 #define AXIS2_PRINTF_INT32_FORMAT_SPECIFIER %I32d #define AXIS2_PRINTF_UINT32_FORMAT_SPECIFIER %I32u #else #define AXIS2_PRINTF_INT32_FORMAT_SPECIFIER %d #define AXIS2_PRINTF_UINT32_FORMAT_SPECIFIER %u #endif #else #if __WORDSIZE == 64 #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %ld #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %lu #else #define AXIS2_PRINTF_INT64_FORMAT_SPECIFIER %lld #define AXIS2_PRINTF_UINT64_FORMAT_SPECIFIER %llu #endif #define AXIS2_PRINTF_INT32_FORMAT_SPECIFIER %d #define AXIS2_PRINTF_UINT32_FORMAT_SPECIFIER %u #endif AXIS2C-1295 seems to be referring to this problem as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1354) new function axis2_svc_client_get_conf_ctx() needed.
[ https://issues.apache.org/jira/browse/AXIS2C-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1354: - Component/s: core/clientapi new function axis2_svc_client_get_conf_ctx() needed. Key: AXIS2C-1354 URL: https://issues.apache.org/jira/browse/AXIS2C-1354 Project: Axis2-C Issue Type: Bug Components: core/clientapi Reporter: Damitha Kumarage It is desired to have above function for the service client api to retrieve the configuration context. In some instances after first service client is created we should be able to retrieve the configuration context from that service client and create new service cients passing that configuraiton context using axis2_svc_client_create_with_conf_ctx_and_svc() function. This is very useful since creating configuration context is very expensive task since this reads all configuration files again and again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1356) Text longer than 128K silently discarded with guththila parser
[ https://issues.apache.org/jira/browse/AXIS2C-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1356: - Component/s: (was: xml/parser) guththila Text longer than 128K silently discarded with guththila parser -- Key: AXIS2C-1356 URL: https://issues.apache.org/jira/browse/AXIS2C-1356 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.5.0 Environment: Linux, Apache, Axis2 C service Reporter: Emanuele Benedetti I created a services in C/C++ under Linux using the Axis2/c framework. The service have one function which takes one string parameter. I run the service using the Apache axis module. The soap xml message is similar to the following (checked with tcpmon): s:Envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope/; s:Body xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; Receive xmlns=http://vww.obscuredforprivacy.xxx/axis2/services/Begin; updategramlong text string/updategram /Receive /s:Body /s:Envelope If the long text string in the updategram element is longer than 128K, in the call to the main serivice procedure (the one assigned to axis2_svc_skeleton_ops::invoke and called by the axis2 engine), the node parameter (third parameter of type axiom_node_t *) have the following structure: Receiveupdategram/updategram/Receive that is the updategram is empty. There is no error in any log. The updategram is discarded. This happen only if the axis2c framework is configured with the default options. That is, the guththila parser is used (it is on by default). If I configure axis2 with the --enable-libxml2, everything is working fine. So it seem to be a limit in the guththila parser. Grretings -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1348) Redundancy in Date/Time functions
[ https://issues.apache.org/jira/browse/AXIS2C-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1348: - Component/s: util Redundancy in Date/Time functions - Key: AXIS2C-1348 URL: https://issues.apache.org/jira/browse/AXIS2C-1348 Project: Axis2-C Issue Type: Bug Components: util Reporter: Damitha Kumarage In axis2 time handling functions there are lot of unneccessary redundancies which in my view complicate the life of developer unneccessarily. For example following five functions axutil_date_time_deserialize_date() axutil_date_time_deserialize_time() axutil_date_time_deserialize_date_time() axutil_date_time_deserialize_time_with_time_zone() axutil_date_time_deserialize_date_time_with_time_zone() could be reduced into one function called axutil_date_time_deserialize_date_time(). Within the function the date time string should be analized to see whether it is date time, date, time, date/time with time zone etc etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1353) Externally passed configuration context and service should not be freed within service client
[ https://issues.apache.org/jira/browse/AXIS2C-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1353: - Component/s: core/clientapi Externally passed configuration context and service should not be freed within service client - Key: AXIS2C-1353 URL: https://issues.apache.org/jira/browse/AXIS2C-1353 Project: Axis2-C Issue Type: Bug Components: core/clientapi Reporter: Damitha Kumarage We have axis2_svc_client_create_with_conf_ctx_and_svc function to create a service client using existing configuration context and service. Currently when service client is freed these are freed as well. However according to the memory handling conventions of Axis2/C these should be freed by the caller function, not by the service client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1329) There should be a stub creation api function that take axis2 configuration context as parameter
[ https://issues.apache.org/jira/browse/AXIS2C-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1329: - Component/s: core/clientapi code generation There should be a stub creation api function that take axis2 configuration context as parameter --- Key: AXIS2C-1329 URL: https://issues.apache.org/jira/browse/AXIS2C-1329 Project: Axis2-C Issue Type: Improvement Components: code generation, core/clientapi Reporter: Damitha Kumarage It is desired to have the above api function so that when creating a stub an existing configuration context could be used. axis2_stub_create_with_conf_ctx_and_endpoint_ref_and_client_home( const axutil_env_t * env, axis2_conf_ctx_t *con_ctx, axis2_endpoint_ref_t * endpoint_ref, const axis2_char_t * client_home)); which in turn call already available api function axis2_svc_client_create_with_conf_ctx_and_svc( const axutil_env_t * env, const axis2_char_t * client_home, axis2_conf_ctx_t * conf_ctx, axis2_svc_t * svc); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1024) Neethi does not support ExactlyOne to allow using OR when defining two tokens where only one or the other is desired
[ https://issues.apache.org/jira/browse/AXIS2C-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1024: - Component/s: neethi Neethi does not support ExactlyOne to allow using OR when defining two tokens where only one or the other is desired Key: AXIS2C-1024 URL: https://issues.apache.org/jira/browse/AXIS2C-1024 Project: Axis2-C Issue Type: New Feature Components: neethi, rampart Affects Versions: Current (Nightly) Environment: Windows XP. Reporter: Dave Meier The spec I'm looking at is http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf in section 4.1.1. The spec shows how to OR things together in the policy, but when I tried that it in rampart/c it didn't work. Here's what I tried (showing just the SignedSupportingTokens: sp:SignedSupportingTokens xmlns:sp=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy; wsp:Policy wsp:ExactlyOne sp:UsernameToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ sp:SamlToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ /wsp:ExactlyOne /wsp:Policy /sp:SignedSupportingTokens This should accept either UsernameToken or SamlToken. Also tried the following without success: sp:SignedSupportingTokens xmlns:sp=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy; wsp:Policy wsp:All wsp:ExactlyOne sp:UsernameToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ sp:SamlToken sp:IncludeToken=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient/ /wsp:ExactlyOne /wsp:All /wsp:Policy /sp:SignedSupportingTokens -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1210) Service Client does not Pick the Correct Transport Receiver
[ https://issues.apache.org/jira/browse/AXIS2C-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1210: - Component/s: core/clientapi Service Client does not Pick the Correct Transport Receiver --- Key: AXIS2C-1210 URL: https://issues.apache.org/jira/browse/AXIS2C-1210 Project: Axis2-C Issue Type: Bug Components: core/clientapi, core/transport Affects Versions: Current (Nightly) Reporter: Danushka Menikkumbura In dual-channel scenarios, the service client (the listener manager) picks the transport receiver based on the value of the service client option, transport_in_protocol. By default this has the value AXIS2_TRANSPORT_ENUM_HTTP and hence, the listener manager starts an HTTP receiver irrespective of the actual transport receiver unless we specify the transport_in_protocol explicitly using axis2_options_set_transport_in_protocol in the client implementation. But we should keep this setting transparent to the client programmer and ideally we can set this value inside the axis2_options_set_reply_to call because it is possible to infer the transport protocol by looking at the reply-to address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
[ https://issues.apache.org/jira/browse/AXIS2C-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12753445#action_12753445 ] S.Uthaiyashankar commented on AXIS2C-1375: -- Frank Zhou's macro is simple solution, but will not work for bigger messages because start element might be in a buffer lesser than (_buffer)-cur_buff-1. Ideally we have to search from buffer 0 until we find _pos. Hatim's solution is good, but I could not check all the cases. I felt Allan's solution was easy to understand and having less modification to the structures. So, I am committing that solution. Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters Key: AXIS2C-1375 URL: https://issues.apache.org/jira/browse/AXIS2C-1375 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.6.0 Environment: windows XP Reporter: Frank Zhou Assignee: S.Uthaiyashankar Priority: Blocker Fix For: Next Version Attachments: guththila.diff, guththila_xml_writer.c, guththila_xml_writer.c, testGuththilaBufferError.xml, testingCodeSnappet.cpp OK, since no one reply to my question, I have to debug the code and found out that guththila has a bug in managing buffer when seriazlize thea axiom tree (the soap structure) before actually send out the request, and I have a potential fix. This is really a critical bug I think, so I hope some developers can take a look at this problem. I am attaching the test input data and code snappet to reproduce the problem. Basically, the bug occurs in guththila_xml_writer.c. The guththila_xml_writer (I call it the soap serializer) maintains an array of buffers dynamically when it writes the soap structure into the buffers. The bug will occur in the following situation: Let's say I have an element ns1:doDeleteFirst12345/ns1:doDeleteFirst somewhere in the soap structure. Now before this element, there are lots of other elements, and when the guththila_xml_writer trys to process this element, the first buffer is ALMOST full, it does not have enough space to write the whole element name ns1:doDeleteFirst (the start tag) into the buffer, it has to create a new buffer, so it writes ns1: at the end of the first buffer (still a few more bytes left empty), and writes doDeleteFirst at the very beginning of the second buffer. The first buffer (Buffer length 16384): -- |**ns1:--| The second buffer (Buffer length 32768): --- |doDeleteFirst-| As the second buffer becomes the current buffer, when the writer trys to process the end tag (/ns1:doDeleteFirst), it uses an elem stack to track the namespace prefix and localname as in the following code: (starting from line 1396) elem-name = guththila_tok_list_get_token(wr-tok_list, env); elem-prefix = guththila_tok_list_get_token(wr-tok_list, env); elem-name-start = GUTHTHILA_BUF_POS(wr-buffer, elem_start); elem-name-size = elem_len; elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start); elem-prefix-size = pref_len; The macro GUTHTHILA_BUF_POS is defined as this: #ifndef GUTHTHILA_BUF_POS #define GUTHTHILA_BUF_POS(_buffer, _pos) ((_buffer).buff[(_buffer).cur_buff] + _pos - (_buffer).pre_tot_data) #endif The bug occurs when it calcuate elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start): The elem_pref_start has a value of 16375, the pre_tot_data has a value of 16379 (the first buffer length is 16384), they are calculated based on the first buffer data, but the current buffer is the second one, so elem-prefix-start points to gabage! I hope this makes sense to you. Use my test case you will see this quickly. When you run the same XML data I attached, first set a break point at line 392 in the file guththila_xml_writer_wrapper, and set the hit count as 514 in the break properties (the 514th element in ns1:doDeleteFirst), then debug step by step. The potential fix is to define GUTHTHILA_BUF_POS as the following: if ((_buffer)-pre_tot_data _pos) return ((_buffer)-buff[(_buffer)-cur_buff-1] + _pos); else return ((_buffer)-buff[(_buffer)-cur_buff] + _pos - (_buffer)-pre_tot_data
[jira] Resolved: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
[ https://issues.apache.org/jira/browse/AXIS2C-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1375. -- Resolution: Fixed Fixed in revision 813238. Thank you every one for contributing. Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters Key: AXIS2C-1375 URL: https://issues.apache.org/jira/browse/AXIS2C-1375 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.6.0 Environment: windows XP Reporter: Frank Zhou Assignee: S.Uthaiyashankar Priority: Blocker Fix For: Next Version Attachments: guththila.diff, guththila_xml_writer.c, guththila_xml_writer.c, testGuththilaBufferError.xml, testingCodeSnappet.cpp OK, since no one reply to my question, I have to debug the code and found out that guththila has a bug in managing buffer when seriazlize thea axiom tree (the soap structure) before actually send out the request, and I have a potential fix. This is really a critical bug I think, so I hope some developers can take a look at this problem. I am attaching the test input data and code snappet to reproduce the problem. Basically, the bug occurs in guththila_xml_writer.c. The guththila_xml_writer (I call it the soap serializer) maintains an array of buffers dynamically when it writes the soap structure into the buffers. The bug will occur in the following situation: Let's say I have an element ns1:doDeleteFirst12345/ns1:doDeleteFirst somewhere in the soap structure. Now before this element, there are lots of other elements, and when the guththila_xml_writer trys to process this element, the first buffer is ALMOST full, it does not have enough space to write the whole element name ns1:doDeleteFirst (the start tag) into the buffer, it has to create a new buffer, so it writes ns1: at the end of the first buffer (still a few more bytes left empty), and writes doDeleteFirst at the very beginning of the second buffer. The first buffer (Buffer length 16384): -- |**ns1:--| The second buffer (Buffer length 32768): --- |doDeleteFirst-| As the second buffer becomes the current buffer, when the writer trys to process the end tag (/ns1:doDeleteFirst), it uses an elem stack to track the namespace prefix and localname as in the following code: (starting from line 1396) elem-name = guththila_tok_list_get_token(wr-tok_list, env); elem-prefix = guththila_tok_list_get_token(wr-tok_list, env); elem-name-start = GUTHTHILA_BUF_POS(wr-buffer, elem_start); elem-name-size = elem_len; elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start); elem-prefix-size = pref_len; The macro GUTHTHILA_BUF_POS is defined as this: #ifndef GUTHTHILA_BUF_POS #define GUTHTHILA_BUF_POS(_buffer, _pos) ((_buffer).buff[(_buffer).cur_buff] + _pos - (_buffer).pre_tot_data) #endif The bug occurs when it calcuate elem-prefix-start = GUTHTHILA_BUF_POS(wr-buffer, elem_pref_start): The elem_pref_start has a value of 16375, the pre_tot_data has a value of 16379 (the first buffer length is 16384), they are calculated based on the first buffer data, but the current buffer is the second one, so elem-prefix-start points to gabage! I hope this makes sense to you. Use my test case you will see this quickly. When you run the same XML data I attached, first set a break point at line 392 in the file guththila_xml_writer_wrapper, and set the hit count as 514 in the break properties (the 514th element in ns1:doDeleteFirst), then debug step by step. The potential fix is to define GUTHTHILA_BUF_POS as the following: if ((_buffer)-pre_tot_data _pos) return ((_buffer)-buff[(_buffer)-cur_buff-1] + _pos); else return ((_buffer)-buff[(_buffer)-cur_buff] + _pos - (_buffer)-pre_tot_data); GUTHTHILA_BUF_POS is used everywhere, so I really hope some developer can take over this case and fix it! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2C-1356) Text longer than 128K silently discarded with guththila parser
[ https://issues.apache.org/jira/browse/AXIS2C-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar reassigned AXIS2C-1356: Assignee: S.Uthaiyashankar Text longer than 128K silently discarded with guththila parser -- Key: AXIS2C-1356 URL: https://issues.apache.org/jira/browse/AXIS2C-1356 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.5.0 Environment: Linux, Apache, Axis2 C service Reporter: Emanuele Benedetti Assignee: S.Uthaiyashankar Fix For: Next Version I created a services in C/C++ under Linux using the Axis2/c framework. The service have one function which takes one string parameter. I run the service using the Apache axis module. The soap xml message is similar to the following (checked with tcpmon): s:Envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope/; s:Body xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; Receive xmlns=http://vww.obscuredforprivacy.xxx/axis2/services/Begin; updategramlong text string/updategram /Receive /s:Body /s:Envelope If the long text string in the updategram element is longer than 128K, in the call to the main serivice procedure (the one assigned to axis2_svc_skeleton_ops::invoke and called by the axis2 engine), the node parameter (third parameter of type axiom_node_t *) have the following structure: Receiveupdategram/updategram/Receive that is the updategram is empty. There is no error in any log. The updategram is discarded. This happen only if the axis2c framework is configured with the default options. That is, the guththila parser is used (it is on by default). If I configure axis2 with the --enable-libxml2, everything is working fine. So it seem to be a limit in the guththila parser. Grretings -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1356) Text longer than 128K silently discarded with guththila parser
[ https://issues.apache.org/jira/browse/AXIS2C-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1356. -- Resolution: Fixed Fix Version/s: Next Version Fixed in revision 813383 Text longer than 128K silently discarded with guththila parser -- Key: AXIS2C-1356 URL: https://issues.apache.org/jira/browse/AXIS2C-1356 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.5.0 Environment: Linux, Apache, Axis2 C service Reporter: Emanuele Benedetti Assignee: S.Uthaiyashankar Fix For: Next Version I created a services in C/C++ under Linux using the Axis2/c framework. The service have one function which takes one string parameter. I run the service using the Apache axis module. The soap xml message is similar to the following (checked with tcpmon): s:Envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope/; s:Body xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; Receive xmlns=http://vww.obscuredforprivacy.xxx/axis2/services/Begin; updategramlong text string/updategram /Receive /s:Body /s:Envelope If the long text string in the updategram element is longer than 128K, in the call to the main serivice procedure (the one assigned to axis2_svc_skeleton_ops::invoke and called by the axis2 engine), the node parameter (third parameter of type axiom_node_t *) have the following structure: Receiveupdategram/updategram/Receive that is the updategram is empty. There is no error in any log. The updategram is discarded. This happen only if the axis2c framework is configured with the default options. That is, the guththila parser is used (it is on by default). If I configure axis2 with the --enable-libxml2, everything is working fine. So it seem to be a limit in the guththila parser. Grretings -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE by
setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However, after
setting error status, there are several generated codes doing AXIS2_PARAM_CHECK
and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar resolved AXIS2C-1402.
--
Resolution: Fixed
Fixed in revision 825395
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1403) Code generation having problem in Windows
Code generation having problem in Windows
-
Key: AXIS2C-1403
URL: https://issues.apache.org/jira/browse/AXIS2C-1403
Project: Axis2-C
Issue Type: Bug
Components: wsdl2c tool
Affects Versions: 1.6.0
Environment: Windows
Reporter: S.Uthaiyashankar
Fix For: Next Version
Error reported in mailing list by Pete Maclean:
http://www.mail-archive.com/axis-c-u...@ws.apache.org/msg05892.html
===
I am attempting to use Axis2/c 1.6.0 to generate C client stubs in Windows with
the -d adb option for use with the Microsoft C compiler and am facing three
problems.
First I had trouble actually generating the stubs using the WSDL2C.bat file
supplied in the package. I got past this obstacle by changing the line that
read:
java -classpath %AXIS2_CLASSPATH% org.apache.axis2.wsdl.WSDL2C %*
to:
java -classpath %AXIS2_CLASSPATH% org.apache.axis2.wsdl.WSDL2C %*
Since I can see no downside to it, may I suggest that this change be made to
the distribution package. It could save a bit of puzzlement and frustration.
The other problems cause the generated code to get compilation errors. The
second is that declarations are generated that are not at the top of their
blocks. I see code like this:
{
axiom_node_t *text_node = NULL;
text_node = axiom_node_get_first_child(parent, env);
axiom_text_t *text_element = NULL;
...
This is fine in C++ but not in plain C.
===
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar reopened AXIS2C-1402:
--
This fix break some of the functionality. Reverting the changes until all the
functionalities are fixed.
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1405) SavanC should create database inside $AXIS2C_HOME if savan_resource is not given in module.xml
SavanC should create database inside $AXIS2C_HOME if savan_resource is not given in module.xml Key: AXIS2C-1405 URL: https://issues.apache.org/jira/browse/AXIS2C-1405 Project: Axis2-C Issue Type: Bug Components: savan Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar currently it is creating in ./savan_db which depends on the working directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1406) SavanC - subscriber sample causes server to crash
SavanC - subscriber sample causes server to crash - Key: AXIS2C-1406 URL: https://issues.apache.org/jira/browse/AXIS2C-1406 Project: Axis2-C Issue Type: Bug Components: savan Environment: Windows Reporter: S.Uthaiyashankar Steps to recreate: run subscriber.exe select 1. subscribe select 4. unsubscribe select 3. get status this will cause the server to crash -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1405) SavanC should create database inside $AXIS2C_HOME if savan_resource is not given in module.xml
[ https://issues.apache.org/jira/browse/AXIS2C-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1405. -- Resolution: Fixed Fix Version/s: Next Version Fixed in revision 827997 SavanC should create database inside $AXIS2C_HOME if savan_resource is not given in module.xml Key: AXIS2C-1405 URL: https://issues.apache.org/jira/browse/AXIS2C-1405 Project: Axis2-C Issue Type: Bug Components: savan Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: Next Version currently it is creating in ./savan_db which depends on the working directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12768232#action_12768232 ] S.Uthaiyashankar commented on AXIS2C-1409: -- If you could track the problems, it will help us a lot. Please provide patch if you find the solutions to the problem. The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12768231#action_12768231 ] S.Uthaiyashankar commented on AXIS2C-1409: -- Yes, I am working on this issue. Ideally, we should not set status if param is OK. However, when that is removed, there are some functionality broken. I'll fix them and then remove setting the status. The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1410) Ability to get server certificate automatically
Ability to get server certificate automatically Key: AXIS2C-1410 URL: https://issues.apache.org/jira/browse/AXIS2C-1410 Project: Axis2-C Issue Type: New Feature Components: core/clientapi Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar When a client talks to a https endpoint, it should automatically get the server certificate. Now, we have to get the server certificate manually and configure it in axis2.xml. It should happen automatically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1416) type in svc_builder.c
[ https://issues.apache.org/jira/browse/AXIS2C-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1416: - Component/s: core/deployment Fix Version/s: Next Version type in svc_builder.c - Key: AXIS2C-1416 URL: https://issues.apache.org/jira/browse/AXIS2C-1416 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: 1.6.0 Environment: $ gcc --version gcc (GCC) 4.2.2 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ld --version GNU ld version 2.17.50.0.6-2.el5 20061020 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. $ uname -a Linux hostname 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Reporter: Russell Tempero Assignee: S.Uthaiyashankar Priority: Minor Fix For: Next Version Attachments: svc_builder.c.diff Original Estimate: 1h Remaining Estimate: 1h While tromping around the Axis code tree I noticed a typo for which I have attached a patch. I never actually noticed any problems associated with this typo, but I figured it might be good to fix it anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2C-1416) type in svc_builder.c
[ https://issues.apache.org/jira/browse/AXIS2C-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar reassigned AXIS2C-1416: Assignee: S.Uthaiyashankar type in svc_builder.c - Key: AXIS2C-1416 URL: https://issues.apache.org/jira/browse/AXIS2C-1416 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: 1.6.0 Environment: $ gcc --version gcc (GCC) 4.2.2 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ld --version GNU ld version 2.17.50.0.6-2.el5 20061020 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. $ uname -a Linux hostname 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Reporter: Russell Tempero Assignee: S.Uthaiyashankar Priority: Minor Fix For: Next Version Attachments: svc_builder.c.diff Original Estimate: 1h Remaining Estimate: 1h While tromping around the Axis code tree I noticed a typo for which I have attached a patch. I never actually noticed any problems associated with this typo, but I figured it might be good to fix it anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1235) Need a way to specify libcurl options
[ https://issues.apache.org/jira/browse/AXIS2C-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1235. -- Resolution: Fixed Fixed in revision 888696. Thank you very much for the patch Need a way to specify libcurl options - Key: AXIS2C-1235 URL: https://issues.apache.org/jira/browse/AXIS2C-1235 Project: Axis2-C Issue Type: New Feature Components: transport/http Affects Versions: Current (Nightly) Reporter: ttg Assignee: S.Uthaiyashankar Fix For: Next Version Attachments: axis2c-1235.txt I need some way to specify additional options for libcurl, but at the moment there is no way to access the CURL* handler. For example I want the client to connect via SOCKS5 proxy with authorization, increase connection timeouts and make it not complain about self-signed SSL certificates. Here is the list of libcurl options I would use: curl_easy_setopt(handler, CURLOPT_PROXY, proxy); curl_easy_setopt(handler, CURLOPT_PROXYPORT, port); curl_easy_setopt(handler, CURLOPT_PROXYTYPE, type); curl_easy_setopt(handler, CURLOPT_PROXYAUTH, CURLAUTH_ANY); curl_easy_setopt(handler, CURLOPT_PROXYUSERPWD, userpwd); curl_easy_setopt(handler, CURLOPT_TIMEOUT, timeout); curl_easy_setopt(handler, CURLOPT_CONNECTTIMEOUT, 10); curl_easy_setopt(handler, CURLOPT_SSL_VERIFYHOST, 0); curl_easy_setopt(handler, CURLOPT_SSL_VERIFYPEER, 0); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1372) Setting the content-length header for libcurl causes auth to fail
[ https://issues.apache.org/jira/browse/AXIS2C-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1372: - Fix Version/s: Next Version Assignee: S.Uthaiyashankar Setting the content-length header for libcurl causes auth to fail - Key: AXIS2C-1372 URL: https://issues.apache.org/jira/browse/AXIS2C-1372 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.6.0 Reporter: Incarnadine Assignee: S.Uthaiyashankar Priority: Blocker Fix For: Next Version Attachments: RemoveContentLengthHeader.diff Original Estimate: 0.08h Remaining Estimate: 0.08h Certain auth schemes, like NTLM, may result in an empty request (no body, content-length:0) being sent to the server first to trigger a 401 auth challenge so as not to waste bandwidth by posting the real message body twice when it knows the first request will result in an auth challenge. Libcurl currently has a bug where it will use the specified content-length on this first request instead of sending 0, which will cause subsequent requests to fail because the message body was never sent. Since libcurl automatically calculates the content-length based on the POST size, it's not necessary to specify it from Axis2/C. Removing this header allows libcurl to calculate the length and send the correct values during both requests. I recommend the content-length setting code be removed because: 1. It doesn't appear to be needed 2. Curl docs do not recommend specifying a content-length header 3. It's currently the only way to get NTLM authentication working (see AXIS2C-1370) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1371) Axis should log libcurl debug information
[ https://issues.apache.org/jira/browse/AXIS2C-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1371: - Fix Version/s: Next Version Assignee: S.Uthaiyashankar Axis should log libcurl debug information - Key: AXIS2C-1371 URL: https://issues.apache.org/jira/browse/AXIS2C-1371 Project: Axis2-C Issue Type: Improvement Components: transport/http Affects Versions: 1.6.0 Reporter: Incarnadine Assignee: S.Uthaiyashankar Priority: Minor Fix For: Next Version Attachments: EnableLibcurlLogging.diff Original Estimate: 2h Remaining Estimate: 2h It is difficult to debug the libcurl transport today because Axis2/C doesn't enable libcurl debug logging. I'll attach a patch which does this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1396) When outputting faults, sometimes, it is necessary to namespace qualify text values. Currently this is not suported in Axis2/C
[ https://issues.apache.org/jira/browse/AXIS2C-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1396: - Component/s: xml/om Affects Version/s: 1.6.0 Issue Type: Improvement (was: Bug) When outputting faults, sometimes, it is necessary to namespace qualify text values. Currently this is not suported in Axis2/C -- Key: AXIS2C-1396 URL: https://issues.apache.org/jira/browse/AXIS2C-1396 Project: Axis2-C Issue Type: Improvement Components: xml/om Affects Versions: 1.6.0 Environment: Any Reporter: Nandika Jayawardana When handling Soap faults, it is necessary to qualify the text data with a namespace prefix. Eg. env:Code env:Valueenv:Sender/env:Value env:Subcode env:Valuem:MessageTimeout/env:Value /env:Subcode /env:Code For this, it is necessary to have a method to axiom_text_t to set the namespce and that correct namespace prefix must be appended to the text value serialized -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar updated AXIS2C-1402:
-
Component/s: core/engine
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Components: core/engine
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
Attachments: axis2_param_check.patch
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1400) crash with arbitrary rest post data
[ https://issues.apache.org/jira/browse/AXIS2C-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1400: - Component/s: transport/http Fix Version/s: Next Version crash with arbitrary rest post data --- Key: AXIS2C-1400 URL: https://issues.apache.org/jira/browse/AXIS2C-1400 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.6.0 Environment: Windows XP, Fedora release 11 (Leonidas) Reporter: Tamas Martinec Priority: Critical Fix For: Next Version The echo sample crashes if the post data is empty, or content is not according to the text=sometext pattern. Here are the messages: SENDING DATA.. /* sending time = 23:57:14*/ /* message uuid = eb01af8d-4d6b-45a3-8bbf-2f80f43acbd2*/ - POST /axis2/services/echo/echoString HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Content-Length: 6 Host: LOCALHOST Content-Type: application/x-www-form-urlencoded text RETRIEVING DATA.. /* retrieving time = 23:57:14*/ /* time throughput = 0 sec(s)*/ - HTTP/1.0 500 Internal Server Error Date: Thu Sep 24 23:57:14 2009 GMT Server: Axis2C/1.6.0 (Simple Axis2 HTTP Server) Content-Type: text/html Content-Length: 210 htmlheadtitle500 Internal Server Error/title/headbodyh2Internal Server Error/h2pThe server encountered an unexpected condition which prevented it from fulfilling the request./p/body/html And the call stack for the crash: axis2_engine.dll!axis2_http_status_line_free(axis2_http_status_line * status_line=0x, const axutil_env * env=0x006dd498) Line 143 + 0x3 bytesC axis2_engine.dll!axis2_http_simple_response_free(axis2_http_simple_response * simple_response=0x006df500, const axutil_env * env=0x006dd498) Line 117C axis2_engine.dll!axis2_http_out_transport_info_impl_free(axis2_http_out_transport_info * http_out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 158C axis2_engine.dll!axis2_http_out_transport_info_free(axis2_http_out_transport_info * http_out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 206 + 0x12 bytesC axis2_engine.dll!axis2_out_transport_info_impl_free(axis2_out_transport_info * out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 61 C axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x006dfa38, const axutil_env * env=0x006dd498) Line 444 + 0x20 bytesC axis2_engine.dll!axis2_http_worker_process_request(axis2_http_worker * http_worker=0x006dc350, const axutil_env * env=0x006dd498, axis2_simple_http_svr_conn * svr_conn=0x006dd4e0, axis2_http_simple_request * simple_request=0x006e0b18) Line 2009C axis2_http_receiver.dll!axis2_svr_thread_worker_func(axutil_thread_t * thd=0x006df870, void * data=0x006dc608) Line 260 + 0x18 bytesC axutil.dll!dummy_worker(void * opaque=0x006df870) Line 88 + 0x15 bytes C kernel32.dll!7c80b729() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] Seems like axis2_http_status_line_free wants to free something already freed.. And this is the end of the log: [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\transport\http\common\http_worker.c(200) Client HTTP version HTTP/1.0 [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\rest_disp.c(114) Checking for service using target endpoint address : http://127.0.0.1:9090/axis2/services/echo/echoString [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\rest_disp.c(135) Service found using target endpoint address [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\util\core_utils.c(772) Checking for operation using REST HTTP Location fragment : /echoString [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\util\core_utils.c(834) Operation found using target endpoint uri fragment [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler request_uri_based_dispatcher within the phase Transport [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler AddressingInHandler within the phase Transport [Thu Sep 24 23:57:14 2009] [info] Starting addressing in handler [Thu Sep 24 23:57:14 2009] [info] c:\axis2c-repo\src\modules\mod_addr\addr_in_handler.c [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler addressing_based_dispatcher
[jira] Updated: (AXIS2C-1398) Add a method to the axis2_options to set mustunderstand attribute to WS-Addressing
[ https://issues.apache.org/jira/browse/AXIS2C-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1398: - Component/s: core/clientapi Issue Type: New Feature (was: Bug) Add a method to the axis2_options to set mustunderstand attribute to WS-Addressing -- Key: AXIS2C-1398 URL: https://issues.apache.org/jira/browse/AXIS2C-1398 Project: Axis2-C Issue Type: New Feature Components: core/clientapi Environment: Any Reporter: Nandika Jayawardana Currently there isnt a convenient way to set mustunderstand attribute for WS-Addressing headers from the client api -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1404) MTOM does not work with CGI installation of Axis
[ https://issues.apache.org/jira/browse/AXIS2C-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1404: - Component/s: mtom MTOM does not work with CGI installation of Axis Key: AXIS2C-1404 URL: https://issues.apache.org/jira/browse/AXIS2C-1404 Project: Axis2-C Issue Type: Bug Components: mtom Environment: $ uname -a Linux hostname 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.2.2 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ld --version GNU ld version 2.17.50.0.6-2.el5 20061020 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Reporter: Russell Tempero Attachments: axis2_cgi_main.c.diff Original Estimate: 48h Remaining Estimate: 48h When using the the CGI version of Axis, a web service is able to neither receive requests with MTOM attachments nor send responses with said attachments. The process crashes in either case. I have attached a fix that allows messages with MTOM attachments to be both sent and received from an Axis2 CGI process. Note that the attached fix works for our current setup and may not take other configurations into account. It is recommended that further investigation be made to ensure that the fix works for all cases. The first part of the attached patch allows for the receipt of chunked transfer-encoding HTTP messages. This is not a necessity for MTOM, but is very helpful. The rest of the patch allows MTOM messages to be sent back out. Let me know if there are any questions or concerns or I if I can further assist in any way. Thanks, Russell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1409: - Component/s: core/engine The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1412) Very simple unit test framework and tests corrections
[ https://issues.apache.org/jira/browse/AXIS2C-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1412: - Component/s: tests Very simple unit test framework and tests corrections - Key: AXIS2C-1412 URL: https://issues.apache.org/jira/browse/AXIS2C-1412 Project: Axis2-C Issue Type: Test Components: tests Reporter: Francois Mireaux Attachments: tests.patch, tests.patch Here is a proposition for a very simple unit test framework, used for rewrite some of tests (numerous errors found). Tests are also modified to be used under Windows (tested with the C compiler of Visual Studio 2008 Express Edition) with the help of a JScript program which computes a Makefile extension for tests (file makeTests) analysing files Makefile.am. After executing buid\win32\build.bat, one can use build\win32\buildtests.bat to build and execute all defined tests. An optionnal parameter ciould be used to build and execute one specific test defined by test_nn (see makeTests file). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1409. -- Resolution: Duplicate Same issue as AXIS2C-1402 The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux Assignee: S.Uthaiyashankar In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar reassigned AXIS2C-1409: Assignee: S.Uthaiyashankar The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux Assignee: S.Uthaiyashankar In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1414) Error in length computing in util/url.c
[ https://issues.apache.org/jira/browse/AXIS2C-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1414: - Component/s: util Error in length computing in util/url.c --- Key: AXIS2C-1414 URL: https://issues.apache.org/jira/browse/AXIS2C-1414 Project: Axis2-C Issue Type: Bug Components: util Reporter: Francois Mireaux A C string ends with 0 so length computing are erroneous in util/url.c for functions axutil_url_set_host and axutil_url_get_server : we need to allocate 1 more byte. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1418) HTTP_METHOD DELETE and REST does not work (server returns error 500)
[ https://issues.apache.org/jira/browse/AXIS2C-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1418: - Component/s: REST HTTP_METHOD DELETE and REST does not work (server returns error 500) Key: AXIS2C-1418 URL: https://issues.apache.org/jira/browse/AXIS2C-1418 Project: Axis2-C Issue Type: Bug Components: REST Affects Versions: 1.6.0 Environment: CentOS 5.1 64 bit Reporter: Ilia Gilderman When http_method set to DELETE and REST is used request fails with error 500 returned from server. The error happens either on echo_rest sample or simple curl request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1385) Axis2/C Manual should include how to install CGI module
[ https://issues.apache.org/jira/browse/AXIS2C-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1385. -- Resolution: Fixed Included instructions. Fixed in revision 890258 Axis2/C Manual should include how to install CGI module --- Key: AXIS2C-1385 URL: https://issues.apache.org/jira/browse/AXIS2C-1385 Project: Axis2-C Issue Type: Task Components: documentation Affects Versions: 1.6.0 Reporter: S.Uthaiyashankar Assignee: S.Uthaiyashankar Fix For: 1.7.0 This information is available in the INSTALL file. We have to include it in Axis2/C Manual (html) as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1325) _WIN32 should be used instead of WIN32
[ https://issues.apache.org/jira/browse/AXIS2C-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790098#action_12790098 ] S.Uthaiyashankar commented on AXIS2C-1325: -- Please refer: http://msdn.microsoft.com/en-us/library/aa489554.aspx We have to change all WIN32 to _WIN32. Have to compile with 64bit compiler and fix it. _WIN32 should be used instead of WIN32 -- Key: AXIS2C-1325 URL: https://issues.apache.org/jira/browse/AXIS2C-1325 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Affects Versions: 1.5.0 Environment: WIN64 Reporter: Patrick van Beem Assignee: S.Uthaiyashankar Priority: Minor Fix For: 1.7.0 Original Estimate: 1h Remaining Estimate: 1h In several places, the WIN32 macro is used to check if we're running on Windows or not. This macro is defined in the make file (and usually by VS in the any WIN32 project too). However, when users are using the library in a 64-bit windows environment, WIN32 is not defined, so the tests for the WIN32 macro in the axis include files in the distribution, fail (when they should not, because we are in a windows environment). We should either use _WIN32 instead (which is always defined by the MS compiler in both 32-bit and 64-bit) or use something like: #if defined(WIN32) || defined(WIN64) to check for windows. I prefer _WIN32, because that's implicit defined while WIN32 and WIN64 must be defined explicit. This change should be made at least in the public includes (since WIN32 is defined in the makefile, the change would have no effect internally). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1325) _WIN32 should be used instead of WIN32
[ https://issues.apache.org/jira/browse/AXIS2C-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791165#action_12791165 ] S.Uthaiyashankar commented on AXIS2C-1325: -- Changing WIN32 to _WIN32 in the public includes is enough. We don't need to change in .C files because WIN32 is defined in the make files. _WIN32 should be used instead of WIN32 -- Key: AXIS2C-1325 URL: https://issues.apache.org/jira/browse/AXIS2C-1325 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Affects Versions: 1.5.0 Environment: WIN64 Reporter: Patrick van Beem Assignee: S.Uthaiyashankar Priority: Minor Fix For: 1.7.0 Original Estimate: 1h Remaining Estimate: 1h In several places, the WIN32 macro is used to check if we're running on Windows or not. This macro is defined in the make file (and usually by VS in the any WIN32 project too). However, when users are using the library in a 64-bit windows environment, WIN32 is not defined, so the tests for the WIN32 macro in the axis include files in the distribution, fail (when they should not, because we are in a windows environment). We should either use _WIN32 instead (which is always defined by the MS compiler in both 32-bit and 64-bit) or use something like: #if defined(WIN32) || defined(WIN64) to check for windows. I prefer _WIN32, because that's implicit defined while WIN32 and WIN64 must be defined explicit. This change should be made at least in the public includes (since WIN32 is defined in the makefile, the change would have no effect internally). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1325) _WIN32 should be used instead of WIN32
[ https://issues.apache.org/jira/browse/AXIS2C-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1325. -- Resolution: Fixed Fixed in revision 891110. _WIN32 should be used instead of WIN32 -- Key: AXIS2C-1325 URL: https://issues.apache.org/jira/browse/AXIS2C-1325 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Affects Versions: 1.5.0 Environment: WIN64 Reporter: Patrick van Beem Assignee: S.Uthaiyashankar Priority: Minor Fix For: 1.7.0 Original Estimate: 1h Remaining Estimate: 1h In several places, the WIN32 macro is used to check if we're running on Windows or not. This macro is defined in the make file (and usually by VS in the any WIN32 project too). However, when users are using the library in a 64-bit windows environment, WIN32 is not defined, so the tests for the WIN32 macro in the axis include files in the distribution, fail (when they should not, because we are in a windows environment). We should either use _WIN32 instead (which is always defined by the MS compiler in both 32-bit and 64-bit) or use something like: #if defined(WIN32) || defined(WIN64) to check for windows. I prefer _WIN32, because that's implicit defined while WIN32 and WIN64 must be defined explicit. This change should be made at least in the public includes (since WIN32 is defined in the makefile, the change would have no effect internally). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1358) 500 Internal Server Error on GET request
[ https://issues.apache.org/jira/browse/AXIS2C-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1358: - Component/s: (was: core/transport) REST 500 Internal Server Error on GET request Key: AXIS2C-1358 URL: https://issues.apache.org/jira/browse/AXIS2C-1358 Project: Axis2-C Issue Type: Bug Components: REST Affects Versions: 1.5.0 Environment: independent Reporter: Edmund Lo axis2_msg_ctx_get_op returns null in axis2_http_transport_utils_handle_media_type_url_encoded which causes server error when processing a GET request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2C-1413) Windows version axutil_thread_once_init don't initialize control struct
[
https://issues.apache.org/jira/browse/AXIS2C-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar reassigned AXIS2C-1413:
Assignee: S.Uthaiyashankar
Windows version axutil_thread_once_init don't initialize control struct
---
Key: AXIS2C-1413
URL: https://issues.apache.org/jira/browse/AXIS2C-1413
Project: Axis2-C
Issue Type: Bug
Components: platforms/windows
Environment: Windows
Reporter: Francois Mireaux
Assignee: S.Uthaiyashankar
Priority: Critical
On Windows 'axutil_thread_once_init' don't initialize control struct so
value may have random value and 'axutil_thread_once' never calls parameter
function.
We must add :
if (control)
{
control-value = 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1413) Windows version axutil_thread_once_init don't initialize control struct
[
https://issues.apache.org/jira/browse/AXIS2C-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar resolved AXIS2C-1413.
--
Resolution: Fixed
Fix Version/s: 1.7.0
Fixed in revision 891114
Windows version axutil_thread_once_init don't initialize control struct
---
Key: AXIS2C-1413
URL: https://issues.apache.org/jira/browse/AXIS2C-1413
Project: Axis2-C
Issue Type: Bug
Components: platforms/windows
Environment: Windows
Reporter: Francois Mireaux
Assignee: S.Uthaiyashankar
Priority: Critical
Fix For: 1.7.0
On Windows 'axutil_thread_once_init' don't initialize control struct so
value may have random value and 'axutil_thread_once' never calls parameter
function.
We must add :
if (control)
{
control-value = 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1400) crash with arbitrary rest post data
[ https://issues.apache.org/jira/browse/AXIS2C-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1400: - Component/s: (was: transport/http) REST crash with arbitrary rest post data --- Key: AXIS2C-1400 URL: https://issues.apache.org/jira/browse/AXIS2C-1400 Project: Axis2-C Issue Type: Bug Components: REST Affects Versions: 1.6.0 Environment: Windows XP, Fedora release 11 (Leonidas) Reporter: Tamas Martinec Priority: Critical Fix For: 1.7.0 The echo sample crashes if the post data is empty, or content is not according to the text=sometext pattern. Here are the messages: SENDING DATA.. /* sending time = 23:57:14*/ /* message uuid = eb01af8d-4d6b-45a3-8bbf-2f80f43acbd2*/ - POST /axis2/services/echo/echoString HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Content-Length: 6 Host: LOCALHOST Content-Type: application/x-www-form-urlencoded text RETRIEVING DATA.. /* retrieving time = 23:57:14*/ /* time throughput = 0 sec(s)*/ - HTTP/1.0 500 Internal Server Error Date: Thu Sep 24 23:57:14 2009 GMT Server: Axis2C/1.6.0 (Simple Axis2 HTTP Server) Content-Type: text/html Content-Length: 210 htmlheadtitle500 Internal Server Error/title/headbodyh2Internal Server Error/h2pThe server encountered an unexpected condition which prevented it from fulfilling the request./p/body/html And the call stack for the crash: axis2_engine.dll!axis2_http_status_line_free(axis2_http_status_line * status_line=0x, const axutil_env * env=0x006dd498) Line 143 + 0x3 bytesC axis2_engine.dll!axis2_http_simple_response_free(axis2_http_simple_response * simple_response=0x006df500, const axutil_env * env=0x006dd498) Line 117C axis2_engine.dll!axis2_http_out_transport_info_impl_free(axis2_http_out_transport_info * http_out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 158C axis2_engine.dll!axis2_http_out_transport_info_free(axis2_http_out_transport_info * http_out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 206 + 0x12 bytesC axis2_engine.dll!axis2_out_transport_info_impl_free(axis2_out_transport_info * out_transport_info=0x006de700, const axutil_env * env=0x006dd498) Line 61 C axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x006dfa38, const axutil_env * env=0x006dd498) Line 444 + 0x20 bytesC axis2_engine.dll!axis2_http_worker_process_request(axis2_http_worker * http_worker=0x006dc350, const axutil_env * env=0x006dd498, axis2_simple_http_svr_conn * svr_conn=0x006dd4e0, axis2_http_simple_request * simple_request=0x006e0b18) Line 2009C axis2_http_receiver.dll!axis2_svr_thread_worker_func(axutil_thread_t * thd=0x006df870, void * data=0x006dc608) Line 260 + 0x18 bytesC axutil.dll!dummy_worker(void * opaque=0x006df870) Line 88 + 0x15 bytes C kernel32.dll!7c80b729() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] Seems like axis2_http_status_line_free wants to free something already freed.. And this is the end of the log: [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\transport\http\common\http_worker.c(200) Client HTTP version HTTP/1.0 [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\rest_disp.c(114) Checking for service using target endpoint address : http://127.0.0.1:9090/axis2/services/echo/echoString [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\rest_disp.c(135) Service found using target endpoint address [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\util\core_utils.c(772) Checking for operation using REST HTTP Location fragment : /echoString [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\util\core_utils.c(834) Operation found using target endpoint uri fragment [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler request_uri_based_dispatcher within the phase Transport [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler AddressingInHandler within the phase Transport [Thu Sep 24 23:57:14 2009] [info] Starting addressing in handler [Thu Sep 24 23:57:14 2009] [info] c:\axis2c-repo\src\modules\mod_addr\addr_in_handler.c [Thu Sep 24 23:57:14 2009] [debug] c:\axis2c-repo\src\core\engine\phase.c(210) Invoke the handler addressing_based_dispatcher within the phase
[jira] Commented: (AXIS2C-1180) SSL Communication and the CA certificate
[ https://issues.apache.org/jira/browse/AXIS2C-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791178#action_12791178 ] S.Uthaiyashankar commented on AXIS2C-1180: -- This feature is not implemented yet. Issue AXIS2C-1410 is for implementing. I am linking this issue to AXIS2C-1410, and resolving it. SSL Communication and the CA certificate Key: AXIS2C-1180 URL: https://issues.apache.org/jira/browse/AXIS2C-1180 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.3.0 Reporter: Frank Huebbers Assignee: S.Uthaiyashankar Fix For: 1.7.0 I'm trying to get SSL communication going with Axis2/C for our application. To this end, I have followed the instructions from the manual, i.e., http://ws.apache.org/axis2/c/docs/axis2c_manual.html#ssl_client So far, I have configured the axis2.xml file to add the transportReceiver and transportSender and I am using the server's certificate (as explained in the manual using openssl to get the certificate) to set the SERVER_CERT parameter in the axis2.xml file. With this setup, everything works fine for me. Now, I have to mention that I'm not interested in SSL client authentication. All I'm interested in is that the communication between the client and our servers is encrypted. So, what I have not been able to do is get rid of the step of setting the SERVER_CERT parameter as i receive an error in http_sender.c stating that status_code 0. I'm thus wondering whether it's possible to not set the SERVER_CERT parameter (and I believe that this should be possible) and, if so, how I could accomplish this task. Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
