[jira] Assigned: (AXIS2C-1204) memory leak for In-Only message with no parameter

[Supun Kamburugamuva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Supun Kamburugamuva reassigned AXIS2C-1204:
---

Assignee: Supun Kamburugamuva

> 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
>
> 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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1204) memory leak for In-Only message with no parameter

[Supun Kamburugamuva (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608670#action_12608670
 ] 

Supun Kamburugamuva commented on AXIS2C-1204:
-

Hi Fredric,

It is not clear to me what you said by "no parameter". Can you please elaborate 
on this and how can I reproduce this?

Supun..

> 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
>
> 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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1151) memory leak in code generated by WSDL2C, soap_act not freed

[Milinda Lakmal Pathirage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Milinda Lakmal Pathirage resolved AXIS2C-1151.
--

   Resolution: Fixed
Fix Version/s: Current (Nightly)

Fix apply to current SVN Head.

> memory leak in code generated by WSDL2C, soap_act  not freed
> 
>
> Key: AXIS2C-1151
> URL: https://issues.apache.org/jira/browse/AXIS2C-1151
> Project: Axis2-C
>  Issue Type: Bug
>  Components: code generation
>Affects Versions: 1.4.0
> Environment: linuc fc5
>Reporter: Frederic Heem
>Assignee: Milinda Lakmal Pathirage
> Fix For: Current (Nightly)
>
>
> In the client code generated, here is a piece of code which allocates a 
> string  but doesn't free it:
> if (NULL == soap_action)
> {
>   is_soap_act_set = AXIS2_FALSE;
>   soap_action = "GetDeviceList";
>   
>   soap_act = axutil_string_create(env, "GetDeviceList"); 
> <<<   axis2_options_set_soap_action(options, env, soap_act);
>   
>   axis2_options_set_action( options, env, soap_action );
> }
> The string soap_act is not freed, thus resulting in a memory leak each time 
> the the client code invokes the operation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Supun Kamburugamuva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Supun Kamburugamuva updated AXIS2C-1154:


Attachment: send_robust.patch

Here is a fix for handling incorrect message patterns configurations by users 
for send robust case. If we don't handle this it leads to invalid memory reads. 
I would like some one with more experience in this area to have a look before I 
apply the patch.

> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c, send_robust.patch
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a298 is 48 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
> ==13318==by 0x4055877: axis2_svc_client_set_http_info (svc_client.c:1756)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a2f0 is 136 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
> ==13318==by 0x40563E4: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:572)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a360 is 248 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048147: axis2_msg_ctx_get_required_auth_is_http 
> (msg_ctx.c:2725)
> ==13318==by 0x40563F6: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:573)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zi

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608663#action_12608663
 ] 

Damitha Kumarage commented on AXIS2C-723:
-

I am thinking whether there is possiblity for someone to have just a transport 
sender or reciever, but not both  defined for a perticular transport protocol 
in axis2.xml. If that is the case taking the
name from sender or reciever become tricky. But anyway we can do a check for 
both sender
and receiver  and take the transport name from one of them as appropriate.
Yes we store the transport senders and receivers in the axis2 configuration.

> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Test suite for transports [was: Re: Test suite for HTTP transport]

[Samisa Abeysinghe]

Supun Kamburugamuva wrote:
Do you think this is the correct discussion for refactoring the 
transport? Or I'm I missing something?


OK, I fixed the subject :)

I think, in addition to what you have mentioned, the testing should also 
verify:


1. Content received and content sent
2. Transport specific stuff such as content length, chunk verification etc.
3. Handling of REST cases vs. SOAP cases (right now we have these 
associated with transports, logically speaking, that is not right, 
because REST and SOAP should be at a higher level. Still since the 
current code have them, we have to have tests for those. After 
refactoring, we should ideally have those REST and SOAP chunks of logic 
on top of transports. In fact, REST is tightly bound to HTTP, but that 
does not mean that we cannot do POX like transactions using other 
transports as well)
4. There should also be tests that cover the interface between transport 
and other layers that use the transport


Thanks,
Samisa...



Supun..

On Fri, Jun 27, 2008 at 10:09 AM, Supun Kamburugamuva 
<[EMAIL PROTECTED] > wrote:


Hi list,

These are the key areas that comes to my mind that we should focus
on for testing.

1. It should work for all sorts of HTTP scenarios. Headers and
data are the key things. We can focus on different combinations.
2. Should not leak memory
3. Should have good performance characteristics

Thoughts?

Supun.. 






No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.101 / Virus Database: 270.4.1/1521 - Release Date: 6/26/2008 11:20 AM
  



--
Samisa Abeysinghe 
Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring the transport

[Rajika Kumarasiri]

On Fri, Jun 27, 2008 at 10:37 AM, Damitha Kumarage <[EMAIL PROTECTED]>
wrote:

> Hi,
> I don't think we need to design new test suites at this time. What we need
> to do is adding comprehensive number of tests into the existing test suite
> sufficient for testing the focused code of refactoring. As I remember we
> worked on two test suites

Can you point where the test sources are available now ?

-Rajika

> in the past but did not proceed adding more tests to them.
>
> thanks,
> Damitha
>
> Rajika Kumarasiri wrote:
>
>>
>>
>> On Fri, Jun 27, 2008 at 9:29 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Supun Kamburugamuva wrote:
>>
>>Hi all,
>>
>>+1 for refactoring the HTTP transport sections and +1 for
>>having a good set of test cases.
>>
>>Since we are agreeing to doing this, I suggest we should have
>>a good design before going on. I think we have enough
>>knowledge and experience to get this right at this point. So
>>I'm looking forward to see a very good discussion in the
>>mailing lists for making this right at this time.
>>
>>
>>But testing and test suite has to be priority even beyond design
>>discussion. That is one of the key areas that we lag. So I would
>>like for us to discuss testing first.
>>
>> Adding a well formed test suite is important, because this will helps a
>> developer to locate a bug easily, May be we can add  test suite based on
>> Deja GNU.
>>
>> -Rajika
>>Then to discuss design.
>>
>>So how best can we test the transport code that we have?
>>
>>Thanks,
>>Samisa...
>>
>>
>>Regards,
>>Supun..
>>On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe
>><[EMAIL PROTECTED] 
>>>> wrote:
>>
>>   Manjula Peiris wrote:
>>
>>   Hi devs,
>>
>>   Most of the code in Axis2/C transport is not organized
>>   properly. This
>>   makes it very difficult to do some changes or adding new
>>   functionality
>>   to the code. One main reason for this is REST handling and
>>   SOAP handling
>>   are mixed in the cod,e in a very ugly manner.
>>Axis2/JAVA has a
>>   separate
>>   section called MessageBuilder which happened before the
>>   Transport stuff
>>   in order to separate out REST Invocations, SOAP invocations
>>   and other
>>   different messaging mechanisms. I propose we do
>>something like
>>   that or
>>   at least separate out REST handling inside HTTP
>>transport.(I
>>   mean at
>>   least separate REST code to different functions or .c
>>files. )
>>   This can
>>   be a post 1.5 fix.
>>
>>   I am always +1 for refactoring and improvements. Mind you,
>>one of
>>   the key pre-requisites of refactoring is testing, to
>>guarantee pre
>>   and post refactoring code bases have the same behavior.
>>   Do we have a good enough test for this, if not, IMHO, we should
>>   build a good set of tests before we endeavor on this
>>re-factoring
>>   mission. Else would we have tough time fixing
>>post-refactoring bugs.
>>
>>   Thanks,
>>   Samisa...
>>
>>   Thanks,
>>   -Manjula.
>> -
>>   To unsubscribe, e-mail:
>>[EMAIL PROTECTED]
>>
>>   >>
>>
>>   For additional commands, e-mail:
>>[EMAIL PROTECTED]
>>
>>   >>
>>
>>
>>  
>>
>>
>>   No virus found in this incoming message.
>>   Checked by AVG. Version: 8.0.101 / Virus Database:
>>   270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
>>
>>
>>   --Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>>
>>   http://www.wso2.com/ - "The Open Source SOA Company"
>>
>>
>>
>>
>> -
>>   To unsubscribe, e-mail:
>>[EMAIL PROTECTED]
>>
>>   >>
>>
>>   For additional commands, e-mail:
>>[EMAIL PROTECTED]
>>
>>   >>
>>
>>
>>
>>
>>  -

Re: Test suite for HTTP transport

[Milinda Pathirage]

Hi Supun,

Actually what you have mentioned about HTTP transport is correct. But we
have to consider other transports as well. I think you forgot them somehow
;-). I think what we have to test is the functionality of Axis2/C engine
when it uses different transports. We have to make sure that Axis2/C engine
behave as in the way that Web Services engine must behave even though it's
run on different different transports. We must design some test cases that
help us to identify abnormal behaviors in basic functionality(if there are
any :)) when we use each of the transports we currently support. We can
design test cases that check each transport related things separately and
web services engine related things separately.
Please feel free to comment on this.

thank
milinda...

On Fri, Jun 27, 2008 at 10:20 AM, Supun Kamburugamuva <[EMAIL PROTECTED]>
wrote:

> Do you think this is the correct discussion for refactoring the transport?
> Or I'm I missing something?
>
> Supun..
>
>
> On Fri, Jun 27, 2008 at 10:09 AM, Supun Kamburugamuva <[EMAIL PROTECTED]>
> wrote:
>
>> Hi list,
>>
>> These are the key areas that comes to my mind that we should focus on for
>> testing.
>>
>> 1. It should work for all sorts of HTTP scenarios. Headers and data are
>> the key things. We can focus on different combinations.
>> 2. Should not leak memory
>> 3. Should have good performance characteristics
>>
>> Thoughts?
>>
>> Supun..
>
>
>


-- 
http://mpathirage.com
http://wso2.org "Oxygen for Web Service Developers"
http://wsaxc.blogspot.com "Web Services With Axis2/C"

Re: Refactoring the transport

[Damitha Kumarage]

Hi,
I don't think we need to design new test suites at this time. What we 
need to do is adding comprehensive number of tests into the existing 
test suite sufficient for testing the focused code of refactoring. As I 
remember we worked on two test suites in the past but did not proceed 
adding more tests to them.


thanks,
Damitha

Rajika Kumarasiri wrote:



On Fri, Jun 27, 2008 at 9:29 AM, Samisa Abeysinghe <[EMAIL PROTECTED] 
> wrote:


Supun Kamburugamuva wrote:

Hi all,

+1 for refactoring the HTTP transport sections and +1 for
having a good set of test cases.

Since we are agreeing to doing this, I suggest we should have
a good design before going on. I think we have enough
knowledge and experience to get this right at this point. So
I'm looking forward to see a very good discussion in the
mailing lists for making this right at this time.


But testing and test suite has to be priority even beyond design
discussion. That is one of the key areas that we lag. So I would
like for us to discuss testing first.

Adding a well formed test suite is important, because this will helps 
a developer to locate a bug easily, May be we can add  test suite 
based on Deja GNU.


-Rajika  


Then to discuss design.

So how best can we test the transport code that we have?

Thanks,
Samisa...


Regards,
Supun..
On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe
<[EMAIL PROTECTED] 
>> wrote:

   Manjula Peiris wrote:

   Hi devs,

   Most of the code in Axis2/C transport is not organized
   properly. This
   makes it very difficult to do some changes or adding new
   functionality
   to the code. One main reason for this is REST handling and
   SOAP handling
   are mixed in the cod,e in a very ugly manner.
Axis2/JAVA has a
   separate
   section called MessageBuilder which happened before the
   Transport stuff
   in order to separate out REST Invocations, SOAP invocations
   and other
   different messaging mechanisms. I propose we do
something like
   that or
   at least separate out REST handling inside HTTP
transport.(I
   mean at
   least separate REST code to different functions or .c
files. )
   This can
   be a post 1.5 fix.
   


   I am always +1 for refactoring and improvements. Mind you,
one of
   the key pre-requisites of refactoring is testing, to
guarantee pre
   and post refactoring code bases have the same behavior.
   Do we have a good enough test for this, if not, IMHO, we should
   build a good set of tests before we endeavor on this
re-factoring
   mission. Else would we have tough time fixing
post-refactoring bugs.

   Thanks,
   Samisa...

   Thanks,
   -Manjula.  
 
 -

   To unsubscribe, e-mail:
[EMAIL PROTECTED]

   >

   For additional commands, e-mail:
[EMAIL PROTECTED]

   >

   




   No virus found in this incoming message.
   Checked by AVG. Version: 8.0.101 / Virus Database:
   270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
   



   --Samisa Abeysinghe Director, Engineering; WSO2 Inc.

   http://www.wso2.com/ - "The Open Source SOA Company"



 
 -

   To unsubscribe, e-mail:
[EMAIL PROTECTED]

   >

   For additional commands, e-mail:
[EMAIL PROTECTED]

   >






No virus found in this incoming message.
Checked by AVG. Version: 8.0.101 / Virus Database:
270.4.1/1521 - Release Date: 6/26/2008 11:20 AM
 




-- 
Samisa Abeysinghe Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"


 

Re: Refactoring the transport

[Milinda Pathirage]

+1 for implementing tests first.

Thanks
Milinda...

On Fri, Jun 27, 2008 at 9:58 AM, Rajika Kumarasiri <[EMAIL PROTECTED]>
wrote:

>
>
> On Fri, Jun 27, 2008 at 9:29 AM, Samisa Abeysinghe <[EMAIL PROTECTED]>
> wrote:
>
>> Supun Kamburugamuva wrote:
>>
>>> Hi all,
>>>
>>> +1 for refactoring the HTTP transport sections and +1 for having a good
>>> set of test cases.
>>>
>>> Since we are agreeing to doing this, I suggest we should have a good
>>> design before going on. I think we have enough knowledge and experience to
>>> get this right at this point. So I'm looking forward to see a very good
>>> discussion in the mailing lists for making this right at this time.
>>>
>>
>> But testing and test suite has to be priority even beyond design
>> discussion. That is one of the key areas that we lag. So I would like for us
>> to discuss testing first.
>
> Adding a well formed test suite is important, because this will helps a
> developer to locate a bug easily, May be we can add  test suite based on
> Deja GNU.
>
> -Rajika
>
>> Then to discuss design.
>>
>> So how best can we test the transport code that we have?
>>
>> Thanks,
>> Samisa...
>>
>>
>>> Regards,
>>> Supun..
>>> On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe <[EMAIL 
>>> PROTECTED]>> [EMAIL PROTECTED]>> wrote:
>>>
>>>Manjula Peiris wrote:
>>>
>>>Hi devs,
>>>
>>>Most of the code in Axis2/C transport is not organized
>>>properly. This
>>>makes it very difficult to do some changes or adding new
>>>functionality
>>>to the code. One main reason for this is REST handling and
>>>SOAP handling
>>>are mixed in the cod,e in a very ugly manner. Axis2/JAVA has a
>>>separate
>>>section called MessageBuilder which happened before the
>>>Transport stuff
>>>in order to separate out REST Invocations, SOAP invocations
>>>and other
>>>different messaging mechanisms. I propose we do something like
>>>that or
>>>at least separate out REST handling inside HTTP transport.(I
>>>mean at
>>>least separate REST code to different functions or .c files. )
>>>This can
>>>be a post 1.5 fix.
>>>
>>>
>>>I am always +1 for refactoring and improvements. Mind you, one of
>>>the key pre-requisites of refactoring is testing, to guarantee pre
>>>and post refactoring code bases have the same behavior.
>>>Do we have a good enough test for this, if not, IMHO, we should
>>>build a good set of tests before we endeavor on this re-factoring
>>>mission. Else would we have tough time fixing post-refactoring bugs.
>>>
>>>Thanks,
>>>Samisa...
>>>
>>>Thanks,
>>>-Manjula.
>>>
>>>  -
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>> 
>>>
>>>
>>>No virus found in this incoming message.
>>>Checked by AVG. Version: 8.0.101 / Virus Database:
>>>270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
>>>
>>>
>>>
>>>--Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>>>
>>>http://www.wso2.com/ - "The Open Source SOA Company"
>>>
>>>
>>>
>>>-
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>> 
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1521 - Release
>>> Date: 6/26/2008 11:20 AM
>>>
>>>
>>
>>
>> --
>> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>>
>> http://www.wso2.com/ - "The Open Source SOA Company"
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> comp.lang.c - http://groups.google.com/group/comp.lang.c/topics




-- 
http://mpathirage.com
http://wso2.org "Oxygen for Web Service Developers"
http://wsaxc.blogspot.com "Web Services With Axis2/C"

Re: Test suite for HTTP transport

[Supun Kamburugamuva]

Do you think this is the correct discussion for refactoring the transport?
Or I'm I missing something?

Supun..

On Fri, Jun 27, 2008 at 10:09 AM, Supun Kamburugamuva <[EMAIL PROTECTED]>
wrote:

> Hi list,
>
> These are the key areas that comes to my mind that we should focus on for
> testing.
>
> 1. It should work for all sorts of HTTP scenarios. Headers and data are the
> key things. We can focus on different combinations.
> 2. Should not leak memory
> 3. Should have good performance characteristics
>
> Thoughts?
>
> Supun..

Re: Test suite for HTTP transport

[Supun Kamburugamuva]

Sorry I guess this is not the correct discussion for refactoring the
transport.

Supun..

On Fri, Jun 27, 2008 at 10:09 AM, Supun KamSoburugamuva <[EMAIL PROTECTED]>
wrote:

> Hi list,
>
> These are the key areas that comes to my mind that we should focus on for
> testing.
>
> 1. It should work for all sorts of HTTP scenarios. Headers and data are the
> key things. We can focus on different combinations.
> 2. Should not leak memory
> 3. Should have good performance characteristics
>
> Thoughts?
>
> Supun..

Test suite for HTTP transport

[Supun Kamburugamuva]

Hi list,

These are the key areas that comes to my mind that we should focus on for
testing.

1. It should work for all sorts of HTTP scenarios. Headers and data are the
key things. We can focus on different combinations.
2. Should not leak memory
3. Should have good performance characteristics

Thoughts?

Supun..

Re: Refactoring the transport

[Rajika Kumarasiri]

On Fri, Jun 27, 2008 at 9:29 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:

> Supun Kamburugamuva wrote:
>
>> Hi all,
>>
>> +1 for refactoring the HTTP transport sections and +1 for having a good
>> set of test cases.
>>
>> Since we are agreeing to doing this, I suggest we should have a good
>> design before going on. I think we have enough knowledge and experience to
>> get this right at this point. So I'm looking forward to see a very good
>> discussion in the mailing lists for making this right at this time.
>>
>
> But testing and test suite has to be priority even beyond design
> discussion. That is one of the key areas that we lag. So I would like for us
> to discuss testing first.

Adding a well formed test suite is important, because this will helps a
developer to locate a bug easily, May be we can add  test suite based on
Deja GNU.

-Rajika

> Then to discuss design.
>
> So how best can we test the transport code that we have?
>
> Thanks,
> Samisa...
>
>
>> Regards,
>> Supun..
>> On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Manjula Peiris wrote:
>>
>>Hi devs,
>>
>>Most of the code in Axis2/C transport is not organized
>>properly. This
>>makes it very difficult to do some changes or adding new
>>functionality
>>to the code. One main reason for this is REST handling and
>>SOAP handling
>>are mixed in the cod,e in a very ugly manner. Axis2/JAVA has a
>>separate
>>section called MessageBuilder which happened before the
>>Transport stuff
>>in order to separate out REST Invocations, SOAP invocations
>>and other
>>different messaging mechanisms. I propose we do something like
>>that or
>>at least separate out REST handling inside HTTP transport.(I
>>mean at
>>least separate REST code to different functions or .c files. )
>>This can
>>be a post 1.5 fix.
>>
>>
>>I am always +1 for refactoring and improvements. Mind you, one of
>>the key pre-requisites of refactoring is testing, to guarantee pre
>>and post refactoring code bases have the same behavior.
>>Do we have a good enough test for this, if not, IMHO, we should
>>build a good set of tests before we endeavor on this re-factoring
>>mission. Else would we have tough time fixing post-refactoring bugs.
>>
>>Thanks,
>>Samisa...
>>
>>Thanks,
>>-Manjula.
>>
>>  -
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> 
>>
>>
>>No virus found in this incoming message.
>>Checked by AVG. Version: 8.0.101 / Virus Database:
>>270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
>>
>>
>>
>>--Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>>
>>http://www.wso2.com/ - "The Open Source SOA Company"
>>
>>
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> 
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1521 - Release
>> Date: 6/26/2008 11:20 AM
>>
>>
>
>
> --
> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>
> http://www.wso2.com/ - "The Open Source SOA Company"
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
comp.lang.c - http://groups.google.com/group/comp.lang.c/topics

[jira] Commented: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Supun Kamburugamuva (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608649#action_12608649
 ] 

Supun Kamburugamuva commented on AXIS2C-1154:
-

Hi Fredric,

I think you have a small mistake in your client code and that alters normal 
behavior of Axis2/C and causes the invalid reads, The mistake is you are making 
the message exchange pattern AXIS2_MEP_URI_IN_ONLY. This is for the server 
side. In client side you should specify AXIS2_MEP_URI_OUT_ONLY for one way 
messages. Because in client side what you are doing is sending but not 
expecting a result.

Anyway we should not have those invalid read if a user done a wrong 
configuration as well. I will correct the code ASAP. 

Supun..

> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a298 is 48 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
> ==13318==by 0x4055877: axis2_svc_client_set_http_info (svc_client.c:1756)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a2f0 is 136 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
> ==13318==by 0x40563E4: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:572)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a360 is 248 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==133

Re: Refactoring the transport

[Samisa Abeysinghe]

Supun Kamburugamuva wrote:

Hi all,

+1 for refactoring the HTTP transport sections and +1 for having a 
good set of test cases.


Since we are agreeing to doing this, I suggest we should have a good 
design before going on. I think we have enough knowledge and 
experience to get this right at this point. So I'm looking forward to 
see a very good discussion in the mailing lists for making this right 
at this time.


But testing and test suite has to be priority even beyond design 
discussion. That is one of the key areas that we lag. So I would like 
for us to discuss testing first. Then to discuss design.


So how best can we test the transport code that we have?

Thanks,
Samisa...



Regards,
Supun.. 

On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe <[EMAIL PROTECTED] 
> wrote:


Manjula Peiris wrote:

Hi devs,

Most of the code in Axis2/C transport is not organized
properly. This
makes it very difficult to do some changes or adding new
functionality
to the code. One main reason for this is REST handling and
SOAP handling
are mixed in the cod,e in a very ugly manner. Axis2/JAVA has a
separate
section called MessageBuilder which happened before the
Transport stuff
in order to separate out REST Invocations, SOAP invocations
and other
different messaging mechanisms. I propose we do something like
that or
at least separate out REST handling inside HTTP transport.(I
mean at
least separate REST code to different functions or .c files. )
This can
be a post 1.5 fix.
 



I am always +1 for refactoring and improvements. Mind you, one of
the key pre-requisites of refactoring is testing, to guarantee pre
and post refactoring code bases have the same behavior.
Do we have a good enough test for this, if not, IMHO, we should
build a good set of tests before we endeavor on this re-factoring
mission. Else would we have tough time fixing post-refactoring bugs.

Thanks,
Samisa...

Thanks,
-Manjula.  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]

For additional commands, e-mail: [EMAIL PROTECTED]

 



No virus found in this incoming message.
Checked by AVG. Version: 8.0.101 / Virus Database:
270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
 




-- 
Samisa Abeysinghe Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"



-
To unsubscribe, e-mail: [EMAIL PROTECTED]

For additional commands, e-mail: [EMAIL PROTECTED]






No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.101 / Virus Database: 270.4.1/1521 - Release Date: 6/26/2008 11:20 AM
  



--
Samisa Abeysinghe 
Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring the transport

[Supun Kamburugamuva]

Hi all,

+1 for refactoring the HTTP transport sections and +1 for having a good set
of test cases.

Since we are agreeing to doing this, I suggest we should have a good design
before going on. I think we have enough knowledge and experience to get this
right at this point. So I'm looking forward to see a very good discussion in
the mailing lists for making this right at this time.

Regards,
Supun..

On Fri, Jun 27, 2008 at 9:04 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:

> Manjula Peiris wrote:
>
>> Hi devs,
>>
>> Most of the code in Axis2/C transport is not organized properly. This
>> makes it very difficult to do some changes or adding new functionality
>> to the code. One main reason for this is REST handling and SOAP handling
>> are mixed in the cod,e in a very ugly manner. Axis2/JAVA has a separate
>> section called MessageBuilder which happened before the Transport stuff
>> in order to separate out REST Invocations, SOAP invocations and other
>> different messaging mechanisms. I propose we do something like that or
>> at least separate out REST handling inside HTTP transport.(I mean at
>> least separate REST code to different functions or .c files. ) This can
>> be a post 1.5 fix.
>>
>>
>
> I am always +1 for refactoring and improvements. Mind you, one of the key
> pre-requisites of refactoring is testing, to guarantee pre and post
> refactoring code bases have the same behavior.
> Do we have a good enough test for this, if not, IMHO, we should build a
> good set of tests before we endeavor on this re-factoring mission. Else
> would we have tough time fixing post-refactoring bugs.
>
> Thanks,
> Samisa...
>
>  Thanks,
>> -Manjula.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>  
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release
>> Date: 6/25/2008 4:13 PM
>>
>>
>
>
> --
> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>
> http://www.wso2.com/ - "The Open Source SOA Company"
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Refactoring the transport

[Samisa Abeysinghe]

Manjula Peiris wrote:

Hi devs,

Most of the code in Axis2/C transport is not organized properly. This
makes it very difficult to do some changes or adding new functionality
to the code. One main reason for this is REST handling and SOAP handling
are mixed in the code in a very ugly manner. Axis2/JAVA has a separate
section called MessageBuilder which happened before the Transport stuff
in order to separate out REST Invocations, SOAP invocations and other
different messaging mechanisms. I propose we do something like that or
at least separate out REST handling inside HTTP transport.(I mean at
least separate REST code to different functions or .c files. ) This can
be a post 1.5 fix.
  


I am always +1 for refactoring and improvements. Mind you, one of the 
key pre-requisites of refactoring is testing, to guarantee pre and post 
refactoring code bases have the same behavior.
Do we have a good enough test for this, if not, IMHO, we should build a 
good set of tests before we endeavor on this re-factoring mission. Else 
would we have tough time fixing post-refactoring bugs.


Thanks,
Samisa...


Thanks,
-Manjula.   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  




No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
  



--
Samisa Abeysinghe 
Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Danushka Menikkumbura (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608645#action_12608645
 ] 

Danushka Menikkumbura commented on AXIS2C-723:
--

Hi Damitha,

We already have this information in the axis2.xml. Each transportSender, 
transportReceiver node has an attribute called "name". The thing I am not sure 
about is if it is possible to get the list of senders or receivers from the 
conf context.

Danushka





> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring the transport

[Manjula Peiris]

On Thu, 2008-06-26 at 23:57 +0530, Damitha Kumarage wrote:
> Hi Manjula,
> Manjula Peiris wrote:
> > Hi devs,
> >
> > Most of the code in Axis2/C transport is not organized properly. This
> > makes it very difficult to do some changes or adding new functionality
> > to the code. One main reason for this is REST handling and SOAP handling
> > are mixed in the code in a very ugly manner. Axis2/JAVA has a separate
> > section called MessageBuilder which happened before the Transport stuff
> > in order to separate out REST Invocations, SOAP invocations and other
> > different messaging mechanisms. I propose we do something like that or
> > at least separate out REST handling inside HTTP transport.(I mean at
> > least separate REST code to different functions or .c files. ) This can
> > be a post 1.5 fix.
> >   
> Even before the rest stuff added the transport code seemed very complex. 
> One reason
> for it is that because it is working we did not bothered to do any 
> changes or refactoring.
> Even if we were aware of this we did not venture to work on this issue 
> because code is
> highly duplicated among many transports. But sooner or later we need to 
> refactor it.
> So +1 for doing it as post 1.5 fix. Adding comprehensive code comments 
> at the same time
> would be a + point.
> 
> Is MessageBuilder a mechanism to build execution chains?. In Axis2/C we 
> build execution
> chains/flows statically at deployment time using phase info and phase 
> resolver.

No, in the case of HTTP we can differentiate a REST call and SOAP call
from the content-type. So after differentiating this their corresponding
MessageBuilders are invoked prior to engine. 

> 
> thanks,
> Damitha
> > Thanks,
> > -Manjula.   
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >   
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring the transport

[Damitha Kumarage]

Hi Manjula,
Manjula Peiris wrote:

Hi devs,

Most of the code in Axis2/C transport is not organized properly. This
makes it very difficult to do some changes or adding new functionality
to the code. One main reason for this is REST handling and SOAP handling
are mixed in the code in a very ugly manner. Axis2/JAVA has a separate
section called MessageBuilder which happened before the Transport stuff
in order to separate out REST Invocations, SOAP invocations and other
different messaging mechanisms. I propose we do something like that or
at least separate out REST handling inside HTTP transport.(I mean at
least separate REST code to different functions or .c files. ) This can
be a post 1.5 fix.
  
Even before the rest stuff added the transport code seemed very complex. 
One reason
for it is that because it is working we did not bothered to do any 
changes or refactoring.
Even if we were aware of this we did not venture to work on this issue 
because code is
highly duplicated among many transports. But sooner or later we need to 
refactor it.
So +1 for doing it as post 1.5 fix. Adding comprehensive code comments 
at the same time

would be a + point.

Is MessageBuilder a mechanism to build execution chains?. In Axis2/C we 
build execution
chains/flows statically at deployment time using phase info and phase 
resolver.


thanks,
Damitha

Thanks,
-Manjula.   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXISCPP-900) Attributes not settable for webservice incvocation

[nadir amra (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXISCPP-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608490#action_12608490
 ] 

nadir amra commented on AXISCPP-900:


This will be fixed soon.  Now that I understand wrapped vs. unwrapped.  
Currently, we always do wrapped - flattening out the parameters on the We 
service operation, and mistakenly, we also include attributes as parameters.  
We shouild not be flattening out the parameters on an operation of elements 
contain attributes. 

This is related to AXISCPP-458.

> Attributes not settable for webservice incvocation
> --
>
> Key: AXISCPP-900
> URL: https://issues.apache.org/jira/browse/AXISCPP-900
> Project: Axis-C++
>  Issue Type: Bug
>  Components: Client - Stub
>Affects Versions: 1.6 Alpha
> Environment: WIN2KSP4 MSVC6SP6 JDK1.5.0_06
>Reporter: Franz Fehringer
> Attachments: PegsPortType.cpp, PegsPortType.hpp, vakanz.wsdl, 
> vakanz.xsd
>
>
> For the invocation of my web services i need to send soap requests containing 
> attributes e.g.
> 
> ...
>   Lux
> ...
> 
> Interestingly wsdl2ws generates input parameters for attributes in the 
> function/method prototypes (see SearchRooms method in the attached sources) 
> but does not use/reference them in the function/method body.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Refactoring the transport

[Manjula Peiris]

Hi devs,

Most of the code in Axis2/C transport is not organized properly. This
makes it very difficult to do some changes or adding new functionality
to the code. One main reason for this is REST handling and SOAP handling
are mixed in the code in a very ugly manner. Axis2/JAVA has a separate
section called MessageBuilder which happened before the Transport stuff
in order to separate out REST Invocations, SOAP invocations and other
different messaging mechanisms. I propose we do something like that or
at least separate out REST handling inside HTTP transport.(I mean at
least separate REST code to different functions or .c files. ) This can
be a post 1.5 fix.

Thanks,
-Manjula.   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXISCPP-458) Unwrapped not supported.

[nadir amra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXISCPP-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nadir amra updated AXISCPP-458:
---

  Component/s: (was: WSDL processing - RPC)
Fix Version/s: (was: 1.6 Alpha)
   current (nightly)

> Unwrapped not supported.
> 
>
> Key: AXISCPP-458
> URL: https://issues.apache.org/jira/browse/AXISCPP-458
> Project: Axis-C++
>  Issue Type: Bug
>  Components: WSDL processing - Doc
>Reporter: John Hawkins
>Assignee: nadir amra
> Fix For: current (nightly)
>
>
> Unwrapped WSDl style is not supported. This should be removed from WSDL2Ws.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608470#action_12608470
 ] 

Senaka Fernando commented on AXIS2C-723:


Hi Damitha,

If you can avoid hardcoding these ++1. Please do check on the possibility. I 
was under the assumption that hardcoding is unavoidable. Hardcoding is done in 
axis2_const.h

Regards,
Senaka

> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608467#action_12608467
 ] 

Damitha Kumarage commented on AXIS2C-723:
-

As I can see where existing transport like xmpp and amqp supported in the code 
the place where these are hard coded can be avoided. Can you please so me where 
you think it is not possible.
Your suggestion of using custom transports seems to me ugly and somewhat not 
clear. Having predefined slots is again kind of hard coded. May be I am 
completely dumb here.

> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1206) xsd:unsignedByte is tranlated to a char, which is signed

[Frederic Heem (JIRA)]

xsd:unsignedByte is tranlated to a char, which is signed


 Key: AXIS2C-1206
 URL: https://issues.apache.org/jira/browse/AXIS2C-1206
 Project: Axis2-C
  Issue Type: Bug
  Components: code generation
Affects Versions: 1.4.0
 Environment: linux fc6
Reporter: Frederic Heem


xsd:unsignedByte is tranlated by WSDL2C to axis2_byte_t (char), which is 
signed. It should be translated  to unsigned char.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Sanjaya Ratnaweera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjaya Ratnaweera reassigned AXIS2C-1116:
--

Assignee: Sanjaya Ratnaweera  (was: Senaka Fernando)

> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows
> 
>
> Key: AXIS2C-1116
> URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Windows)
>Affects Versions: 1.4.0
> Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
>Reporter: Senaka Fernando
>Assignee: Sanjaya Ratnaweera
>Priority: Critical
> Fix For: Current (Nightly)
>
>
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows. These must be removed by the scripts 
> used for making distributions, which AFAIU is not happening.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Sanjaya Ratnaweera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjaya Ratnaweera resolved AXIS2C-1116.


Resolution: Fixed

> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows
> 
>
> Key: AXIS2C-1116
> URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Windows)
>Affects Versions: 1.4.0
> Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
>Reporter: Senaka Fernando
>Assignee: Sanjaya Ratnaweera
>Priority: Critical
> Fix For: Current (Nightly)
>
>
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows. These must be removed by the scripts 
> used for making distributions, which AFAIU is not happening.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1205) Redundant adding of handlers into execution chains.

[Damitha Kumarage (JIRA)]

Redundant adding of handlers into execution chains.
---

 Key: AXIS2C-1205
 URL: https://issues.apache.org/jira/browse/AXIS2C-1205
 Project: Axis2-C
  Issue Type: Bug
 Environment: all
Reporter: Damitha Kumarage


When adding a new serivce to the configuration I can see that it is calling
axis2_phase_resolver_build_execution_chains_for_svc() function in the following
order

conf_add_svc->svc_grp_add_svd->build_execution_chains_for_svc

What build_execution_chains_for_svc() function doing is for each service 
operation
retrieve modules from configration and service and add module handlers into 
operation
phases. But it should be noted that by this time these handlers are already 
added into
operation phases by call to axis2_phase_resolver_engage_module_globally() 
function in
the following order

axis2_dep_engine_engage_modules->axis2_conf_engage_module->engage_module_globally

At the same time it is important to note that build_execution_chains_for_svc() 
function is used
to build execution chains for services added to conf programmatically. This is 
used for this
purpose from scripting language implementations using Axis2/C.

Keeping this in mind my fix for this problem is attached in the attached patch 
file


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1160) axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when the server returns "HTTP/1.1 500 Internal Server Error"

[Frederic Heem (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608426#action_12608426
 ] 

Frederic Heem commented on AXIS2C-1160:
---

The modified  notify_client.c has been used to reproduce the problem (the 
original may exhibit the issue as well). Simply delete from the server services 
the notify directory and invoke the client, it returns:  "notify client invoke 
SUCCESSFUL!"
Best Regards,

> axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when 
> the server returns "HTTP/1.1 500 Internal Server Error"
> 
>
> Key: AXIS2C-1160
> URL: https://issues.apache.org/jira/browse/AXIS2C-1160
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/clientapi
> Environment: linux fc5
>Reporter: Frederic Heem
>Assignee: Damitha Kumarage
>Priority: Minor
> Fix For: 1.4.0
>
>
> When sending an "In-Only" message, the function 
> axis2_svc_client_send_robust_with_op_qname() doesn't return AXIS2_FAILURE 
> when the server returns "HTTP/1.1 500 Internal Server Error". Is this the 
> intended behaviour ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Issue Comment Edited: (AXIS2C-1190) Non blocking samples could be improved by the use of axis2_callback_get_complete function.

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608424#action_12608424
 ] 

senakafdo edited comment on AXIS2C-1190 at 6/26/08 6:37 AM:
--

Hi Damitha,

This is something related to the echo non-blocking sample isn't it? Thus, 
shouldn't the method start with "echo_" rather than "axis2_".

If it is for Axis2/C itself (so that it can be used by any sample), AFAIK it is 
not what is intended. Because,
1. There already is a defined on-complete handle
2. The get_complete function will introduce a blocking nature to the 
non-blocking code paths. I say so because I believe that a non-blocking 
execution should be based on response events rather than response states.

Regards,
Senaka

  was (Author: senakafdo):
Hi Damitha,

This is something related to the echo non-blocking sample isn't it? If it is 
for Axis2/C itself, AFAIK it is not what is intended. Because,
1. There already is a defined on-complete handle
2. The get_complete function will introduce a blocking nature to the 
non-blocking code paths. I say so because I believe that a non-blocking 
execution should be based on response events rather than response states.

Regards,
Senaka
  
> Non blocking samples could be improved by the use of 
> axis2_callback_get_complete function.
> --
>
> Key: AXIS2C-1190
> URL: https://issues.apache.org/jira/browse/AXIS2C-1190
> Project: Axis2-C
>  Issue Type: Bug
> Environment: all
>Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
>
> I can see that in non blocking samples it keep variable isComplete which is 
> updated from within the on_complte callback function to notify the 
> application client that response has arrived. Meanwhile client is in a while 
> loop which look for the change in onComplete variable for loop break.
> I think it is more advisable simpler  to use following in the client code 
> which use axis2_callback_get_complete function.
> while(!axis2_callback_get_comlete(callback, env))
> {
> AXIS2_SLLEP(1);
> if(count < 30)
> {
> count++; 
> }
> else
> {
> printf("\necho client invoke failed. Counter timed out. \n"); 
> }
> }
> echo_process_result_node(callback, env);
> Note that echo_process_result_node(callback, env) function
> has the same content as the echo_callback_on_complete() function. Only the 
> name
> is changed for appropriateness.
> Also significant change is not passing a callback function with the callback. 
> This is not needed.
> Once response come back the callback has the response envelope set. Calling 
> echo_process_result_node
> we can process this result appropriatley.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1190) Non blocking samples could be improved by the use of axis2_callback_get_complete function.

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608424#action_12608424
 ] 

Senaka Fernando commented on AXIS2C-1190:
-

Hi Damitha,

This is something related to the echo non-blocking sample isn't it? If it is 
for Axis2/C itself, AFAIK it is not what is intended. Because,
1. There already is a defined on-complete handle
2. The get_complete function will introduce a blocking nature to the 
non-blocking code paths. I say so because I believe that a non-blocking 
execution should be based on response events rather than response states.

Regards,
Senaka

> Non blocking samples could be improved by the use of 
> axis2_callback_get_complete function.
> --
>
> Key: AXIS2C-1190
> URL: https://issues.apache.org/jira/browse/AXIS2C-1190
> Project: Axis2-C
>  Issue Type: Bug
> Environment: all
>Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
>
> I can see that in non blocking samples it keep variable isComplete which is 
> updated from within the on_complte callback function to notify the 
> application client that response has arrived. Meanwhile client is in a while 
> loop which look for the change in onComplete variable for loop break.
> I think it is more advisable simpler  to use following in the client code 
> which use axis2_callback_get_complete function.
> while(!axis2_callback_get_comlete(callback, env))
> {
> AXIS2_SLLEP(1);
> if(count < 30)
> {
> count++; 
> }
> else
> {
> printf("\necho client invoke failed. Counter timed out. \n"); 
> }
> }
> echo_process_result_node(callback, env);
> Note that echo_process_result_node(callback, env) function
> has the same content as the echo_callback_on_complete() function. Only the 
> name
> is changed for appropriateness.
> Also significant change is not passing a callback function with the callback. 
> This is not needed.
> Once response come back the callback has the response envelope set. Calling 
> echo_process_result_node
> we can process this result appropriatley.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1160) axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when the server returns "HTTP/1.1 500 Internal Server Error"

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608422#action_12608422
 ] 

Senaka Fernando commented on AXIS2C-1160:
-

Hi Frederic,

Can you provide us with instructions on how to reproduce this issue.

Regards,
Senaka

> axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when 
> the server returns "HTTP/1.1 500 Internal Server Error"
> 
>
> Key: AXIS2C-1160
> URL: https://issues.apache.org/jira/browse/AXIS2C-1160
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/clientapi
> Environment: linux fc5
>Reporter: Frederic Heem
>Assignee: Damitha Kumarage
>Priority: Minor
> Fix For: 1.4.0
>
>
> When sending an "In-Only" message, the function 
> axis2_svc_client_send_robust_with_op_qname() doesn't return AXIS2_FAILURE 
> when the server returns "HTTP/1.1 500 Internal Server Error". Is this the 
> intended behaviour ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1040) AXIS2/C Static Build Required

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando updated AXIS2C-1040:


Environment: MS Windows

> AXIS2/C Static Build Required
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
> Environment: MS Windows
>Reporter: Frank Huebbers
>Assignee: Senaka Fernando
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1040) AXIS2/C Static Build Required

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608420#action_12608420
 ] 

Senaka Fernando commented on AXIS2C-1040:
-

Hi Dushshantha,

Thanks for the confirmation. I'm assigning this issue to myself. I don't see a 
clear-cut solution for this issue that can be done in few days. Thus, will hold 
on until a solid fix is found. Also, this issue is now partially fixed, and the 
remaining part is not a buggy behaviour but an improvement to the existing 
implementation.

Hi Bill, Frank,

The two of you have been doing a lot of work in related areas. Can you please 
let me know whether you have succeeded in having an appealing solution to this 
issue. I'm not quite in a position of starting to work on this from ground-up 
right now onwards.

Regards,
Senaka

> AXIS2/C Static Build Required
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Reporter: Frank Huebbers
>Assignee: Senaka Fernando
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1040) AXIS2/C Static Build Required

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando reassigned AXIS2C-1040:
---

Assignee: Senaka Fernando  (was: Dushshantha Chandradasa)

> AXIS2/C Static Build Required
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Reporter: Frank Huebbers
>Assignee: Senaka Fernando
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608418#action_12608418
 ] 

Senaka Fernando commented on AXIS2C-723:


Hi Damitha,

This is the point. Say the user (who is a developer) comes up with an all new 
transport, say JMS (just as an example). Adding JMS on axis2.xml wont solve 
this issue. He will also have to then edit the places where it is defined in 
the C source code and add this name. The request made here can be solved by 
simply defining custom transports such as "user1", "user2", "user3" in the C 
source code. Then say if a user comes up with JMS he can use the user1 slot and 
add his implementation. If he comes up with one more say JSON, it can be added 
using user2. And, likewise he can add up to 3 such transports.

Axis2/C users are not just end users but developers who are making small 
applications that are useful to end users as well. This should better serve 
Atsushi's requirement.

Regards,
Senaka

> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AddIing new transport in Axis2/C

[Damitha Kumarage]

Hi,
Please see proposed solution for jira AXIS2C-723. If every body ok with 
this I can implement this within few hours.


thanks
Damitha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-723) add new transport in Axis2/C

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608416#action_12608416
 ] 

Damitha Kumarage commented on AXIS2C-723:
-

We can solve this problem as following.

In axis2.xml we define transports as following











Then in configuration builder we parse this list and add these transport names 
into a array_list caled transport_list. Then in places of using transport enums 
we can use these transport names. What do you think?



> add new transport in Axis2/C
> 
>
> Key: AXIS2C-723
> URL: https://issues.apache.org/jira/browse/AXIS2C-723
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/transport
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>Assignee: Damitha Kumarage
>
> I have a desire for new trasnport in Axis2/C.
> I found a hard cording the transports in axis2_const.h like this.
> #define AXIS2_TRANSPORT_HTTP "http"
> #define AXIS2_TRANSPORT_SMTP "smtp"
> #define AXIS2_TRANSPORT_TCP "tcp"
> #define AXIS2_TRANSPORT_XMPP "xmpp"
> #define AXIS2_TRANSPORT_HTTPS "https"
> typedef enum
> {
> AXIS2_TRANSPORT_ENUM_HTTP = 0,
> AXIS2_TRANSPORT_ENUM_SMTP,
> AXIS2_TRANSPORT_ENUM_TCP,
> AXIS2_TRANSPORT_ENUM_XMPP,
> AXIS2_TRANSPORT_ENUM_HTTPS,
> AXIS2_TRANSPORT_ENUM_MAX
> } AXIS2_TRANSPORT_ENUMS;
> And using like this.
> /**
>  * Adds a transport in description.
>  * @param conf pointer to conf struct
>  * @param env pointer to environment struct
>  * @param transport  pointer to transport in description. conf assumes
>  * ownership of the struct
>  * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE
>  */
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_conf_add_transport_in(axis2_conf_t *conf,
> const axutil_env_t *env,
> axis2_transport_in_desc_t *transport,
> const AXIS2_TRANSPORT_ENUMS trans_enum);
> If we want to add a new transport, we must defin a transport in axis2_const.h 
> and re-build Axis2/C modules.
> In Axis2 (Java), we don't need to re-build Axis2 modules, if we think so.
> We can only provid a class implemented TransportProvider I/F and add a entry 
> at axis2.xml file.
> Axis2 said in key features, engine is completely transport-independent at 
> "Transport Fremework".
> I think the realization like Axis2 is advisable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1040) AXIS2/C Static Build Required

[Dushshantha Chandradasa (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608390#action_12608390
 ] 

Dushshantha Chandradasa commented on AXIS2C-1040:
-

I tested the svn head with the changes Senaka done according to his first 
comment. Everything works fine. 

> AXIS2/C Static Build Required
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Reporter: Frank Huebbers
>Assignee: Dushshantha Chandradasa
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1204) memory leak for In-Only message with no parameter

[Frederic Heem (JIRA)]

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


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Frederic Heem (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608377#action_12608377
 ] 

Frederic Heem commented on AXIS2C-1154:
---

In the given trace, axutil_allocator_free_impl is called .. .and I don't know 
why. Anyay, here is the valgrind trace with notify_client.c:
==15367== Invalid read of size 4
==15367==at 0x404AB67: axis2_msg_ctx_get_transport_in_desc (msg_ctx.c:1075)
==15367==by 0x405624E: axis2_svc_client_set_http_info (svc_client.c:1703)
==15367==by 0x4056E8E: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:571)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==  Address 0x4228f70 is 48 bytes inside a block of size 264 free'd
==15367==at 0x40053FC: free (vg_replace_malloc.c:323)
==15367==by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540)
==15367==by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226)
==15367==by 0x4054FAA: axis2_op_client_execute (op_client.c:522)
==15367==by 0x4056E7F: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:570)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==
==15367== Invalid read of size 4
==15367==at 0x4049077: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
==15367==by 0x4056347: axis2_svc_client_set_http_info (svc_client.c:1756)
==15367==by 0x4056E8E: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:571)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==  Address 0x4228fc8 is 136 bytes inside a block of size 264 free'd
==15367==at 0x40053FC: free (vg_replace_malloc.c:323)
==15367==by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540)
==15367==by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226)
==15367==by 0x4054FAA: axis2_op_client_execute (op_client.c:522)
==15367==by 0x4056E7F: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:570)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==
==15367== Invalid read of size 4
==15367==at 0x4048F77: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
==15367==by 0x4056E9A: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:572)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==  Address 0x4229038 is 248 bytes inside a block of size 264 free'd
==15367==at 0x40053FC: free (vg_replace_malloc.c:323)
==15367==by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540)
==15367==by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226)
==15367==by 0x4054FAA: axis2_op_client_execute (op_client.c:522)
==15367==by 0x4056E7F: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:570)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==
==15367== Invalid read of size 4
==15367==at 0x4048D77: axis2_msg_ctx_get_required_auth_is_http 
(msg_ctx.c:2725)
==15367==by 0x4056EAC: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:573)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==  Address 0x422903c is 252 bytes inside a block of size 264 free'd
==15367==at 0x40053FC: free (vg_replace_malloc.c:323)
==15367==by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540)
==15367==by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226)
==15367==by 0x4054FAA: axis2_op_client_execute (op_client.c:522)
==15367==by 0x4056E7F: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:570)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==
==15367== Invalid read of size 4
==15367==at 0x4048B87: axis2_msg_ctx_get_auth_type (msg_ctx.c:2761)
==15367==by 0x8049081: main (notify_client.c:134)
==15367==  Address 0x4229040 is 256 bytes inside a block of size 264 free'd
==15367==at 0x40053FC: free (vg_replace_malloc.c:323)
==15367==by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540)
==15367==by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226)
==15367==by 0x4054FAA: axis2_op_client_execute (op_client.c:522)
==15367==by 0x4056E7F: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:570)
==15367==by 0x8049081: main (notify_client.c:134)

> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> 

[jira] Commented: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Supun Kamburugamuva (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608366#action_12608366
 ] 

Supun Kamburugamuva commented on AXIS2C-1154:
-

But I can see that function is getting called in your trace. I checked your 
sample with Purify under Windows XP. But I didn't get the invalid read. Need to 
check on Linux.



> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a298 is 48 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
> ==13318==by 0x4055877: axis2_svc_client_set_http_info (svc_client.c:1756)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a2f0 is 136 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
> ==13318==by 0x40563E4: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:572)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a360 is 248 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048147: axis2_msg_ctx_get_required_auth_is_http 
> (msg_ctx.c:2725)
> ==13318==by 0x40563F6: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:573)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> 

[jira] Reopened: (AXIS2C-1160) axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when the server returns "HTTP/1.1 500 Internal Server Error"

[Frederic Heem (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frederic Heem reopened AXIS2C-1160:
---


The problem has been checked again, and still exists. Please use the 
notify_client.c which contains a call to 
axis2_svc_client_send_robust_with_op_qname.

> axis2_svc_client_send_robust_with_op_qname doesn't return AXIS2_FAILURE when 
> the server returns "HTTP/1.1 500 Internal Server Error"
> 
>
> Key: AXIS2C-1160
> URL: https://issues.apache.org/jira/browse/AXIS2C-1160
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/clientapi
> Environment: linux fc5
>Reporter: Frederic Heem
>Assignee: Damitha Kumarage
>Priority: Minor
> Fix For: 1.4.0
>
>
> When sending an "In-Only" message, the function 
> axis2_svc_client_send_robust_with_op_qname() doesn't return AXIS2_FAILURE 
> when the server returns "HTTP/1.1 500 Internal Server Error". Is this the 
> intended behaviour ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Frederic Heem (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608356#action_12608356
 ] 

Frederic Heem commented on AXIS2C-1154:
---

Indeed, MALLOC and FREE needs to be modified and mapped directly to malloc() 
and free(). In that case, axutil_allocator_free_impl is not called. 

> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a298 is 48 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
> ==13318==by 0x4055877: axis2_svc_client_set_http_info (svc_client.c:1756)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a2f0 is 136 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
> ==13318==by 0x40563E4: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:572)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a360 is 248 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048147: axis2_msg_ctx_get_required_auth_is_http 
> (msg_ctx.c:2725)
> ==13318==by 0x40563F6: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:573)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_c

[jira] Commented: (AXIS2C-1154) multiple Invalid read of size 4 for client In-Only message

[Supun Kamburugamuva (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608349#action_12608349
 ] 

Supun Kamburugamuva commented on AXIS2C-1154:
-

Hi Frederic,

I assume the trace you have produced is using modified MALLOC and FREE 
functions. In that case how axutil_allocator_free_impl this function get called?

Supun.. 

> multiple Invalid read of size 4 for client In-Only message
> --
>
> Key: AXIS2C-1154
> URL: https://issues.apache.org/jira/browse/AXIS2C-1154
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
> Attachments: notify_client.c
>
>
> When sending an "In-Only" message, valgrind complains about multiple invalid 
> read :
> ==13318== Invalid read of size 4
> ==13318==at 0x4049F37: axis2_msg_ctx_get_transport_in_desc 
> (msg_ctx.c:1075)
> ==13318==by 0x405577E: axis2_svc_client_set_http_info (svc_client.c:1703)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a298 is 48 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662)
> ==13318==by 0x4055877: axis2_svc_client_set_http_info (svc_client.c:1756)
> ==13318==by 0x40563D8: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:571)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a2f0 is 136 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683)
> ==13318==by 0x40563E4: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:572)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==  Address 0x423a360 is 248 bytes inside a block of size 264 free'd
> ==13318==at 0x40053CC: free (vg_replace_malloc.c:323)
> ==13318==by 0x411289C: axutil_allocator_free_impl (allocator.c:91)
> ==13318==by 0x404CBE9: axis2_msg_ctx_free (msg_ctx.c:540)
> ==13318==by 0x4053E3C: axis2_op_client_add_msg_ctx (op_client.c:226)
> ==13318==by 0x40544E4: axis2_op_client_execute (op_client.c:522)
> ==13318==by 0x40563C9: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:570)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
> ==13318==by 0x804A523: main (zigbee_client.c:132)
> ==13318==
> ==13318== Invalid read of size 4
> ==13318==at 0x4048147: axis2_msg_ctx_get_required_auth_is_http 
> (msg_ctx.c:2725)
> ==13318==by 0x40563F6: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:573)
> ==13318==by 0x804B477: axis2_stub_op_zigbee_PermitJoining 
> (axis2_stub_zigbee.c:1248)
> ==13318==by 0x804A362: PermitJoining (zigbee_client.c:221)
>

[jira] Updated: (AXIS2C-1040) AXIS2/C Static Build Required

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando updated AXIS2C-1040:


Issue Type: Improvement  (was: Bug)
   Summary: AXIS2/C Static Build Required  (was: Use of AXIS2_EXPORT 
instead of AXIS2_EXTERN in a few places causes errors in static build)

Hi all,

The required changes to axutil_utils_defines.h are committed in. I'm renaming 
the issue so that it better reflects the discussed $subject.

Regards,
Senaka

> AXIS2/C Static Build Required
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Reporter: Frank Huebbers
>Assignee: Dushshantha Chandradasa
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1151) memory leak in code generated by WSDL2C, soap_act not freed

[Milinda Lakmal Pathirage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Milinda Lakmal Pathirage reassigned AXIS2C-1151:


Assignee: Milinda Lakmal Pathirage

> memory leak in code generated by WSDL2C, soap_act  not freed
> 
>
> Key: AXIS2C-1151
> URL: https://issues.apache.org/jira/browse/AXIS2C-1151
> Project: Axis2-C
>  Issue Type: Bug
>  Components: code generation
>Affects Versions: 1.4.0
> Environment: linuc fc5
>Reporter: Frederic Heem
>Assignee: Milinda Lakmal Pathirage
>
> In the client code generated, here is a piece of code which allocates a 
> string  but doesn't free it:
> if (NULL == soap_action)
> {
>   is_soap_act_set = AXIS2_FALSE;
>   soap_action = "GetDeviceList";
>   
>   soap_act = axutil_string_create(env, "GetDeviceList"); 
> <<<   axis2_options_set_soap_action(options, env, soap_act);
>   
>   axis2_options_set_action( options, env, soap_action );
> }
> The string soap_act is not freed, thus resulting in a memory leak each time 
> the the client code invokes the operation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1192) axis2c dual sample clients give a memory corruption in consecutive execution

[S.Uthaiyashankar (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608333#action_12608333
 ] 

S.Uthaiyashankar commented on AXIS2C-1192:
--

Here, echo_blocking_dual.exe crashes. Even without libcurl, it is crashing.( I 
haven't check with libcurl. )

> axis2c dual sample clients give a memory corruption in consecutive execution
> 
>
> Key: AXIS2C-1192
> URL: https://issues.apache.org/jira/browse/AXIS2C-1192
> Project: Axis2-C
>  Issue Type: Bug
>  Components: samples
>Affects Versions: Current (Nightly)
> Environment: Windows XP, guththila
>Reporter: S.Uthaiyashankar
>
> axis2c dual sample clients give a memory corruption in consecutive execution.
> To recreate the issue, try running echo_blocking_dual.exe several times 
> consecutively. The corruption occurs randomly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Issue Comment Edited: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Supun Kamburugamuva]

Hi Senaka,

We still creates a win32 bin/src.

Supun.

On Thu, Jun 26, 2008 at 1:38 PM, Senaka Fernando (JIRA) <[EMAIL PROTECTED]>
wrote:

>
>[
> https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608328#action_12608328]
>
> senakafdo edited comment on AXIS2C-1116 at 6/26/08 1:08 AM:
> --
>
> Hi Supun,
>
> This will not require a 64-bit machine to fix, but will need a 64-bit
> machine to reproduce. What should be happening is that when we create the
> distribution artifacts, we should make sure to remove the /WX flags in the
> win32 build scripts. It is a matter of applying SED.
>
> Also, do we official have 64-bit support? or will still create the 32-bit
> src/bin releases?
>
> Regards,
> Senaka
>
>  was (Author: senakafdo):
>Hi Supun,
>
> This will not require a 64-bit machine to fix, but will need a 64-bit
> machine to reproduce. What should be happening is that when we create the
> distribution artifacts, we should make sure to remove the /WX flags in the
> win32 build scripts. It is a matter of applying SED.
>
> Regards,
> Senaka
>
> > /WX (warn-to-error) flags in windows makefiles found in source
> distributions leads to build breaks on 64-bit windows
> >
> 
> >
> > Key: AXIS2C-1116
> > URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> > Project: Axis2-C
> >  Issue Type: Bug
> >  Components: build system (Windows)
> >Affects Versions: 1.4.0
> > Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
> >Reporter: Senaka Fernando
> >Assignee: Senaka Fernando
> >Priority: Critical
> > Fix For: Current (Nightly)
> >
> >
> > /WX (warn-to-error) flags in windows makefiles found in source
> distributions leads to build breaks on 64-bit windows. These must be removed
> by the scripts used for making distributions, which AFAIU is not happening.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Issue Comment Edited: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608328#action_12608328
 ] 

senakafdo edited comment on AXIS2C-1116 at 6/26/08 1:08 AM:
--

Hi Supun,

This will not require a 64-bit machine to fix, but will need a 64-bit machine 
to reproduce. What should be happening is that when we create the distribution 
artifacts, we should make sure to remove the /WX flags in the win32 build 
scripts. It is a matter of applying SED.

Also, do we official have 64-bit support? or will still create the 32-bit 
src/bin releases?

Regards,
Senaka

  was (Author: senakafdo):
Hi Supun,

This will not require a 64-bit machine to fix, but will need a 64-bit machine 
to reproduce. What should be happening is that when we create the distribution 
artifacts, we should make sure to remove the /WX flags in the win32 build 
scripts. It is a matter of applying SED.

Regards,
Senaka
  
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows
> 
>
> Key: AXIS2C-1116
> URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Windows)
>Affects Versions: 1.4.0
> Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
>Reporter: Senaka Fernando
>Assignee: Senaka Fernando
>Priority: Critical
> Fix For: Current (Nightly)
>
>
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows. These must be removed by the scripts 
> used for making distributions, which AFAIU is not happening.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608328#action_12608328
 ] 

Senaka Fernando commented on AXIS2C-1116:
-

Hi Supun,

This will not require a 64-bit machine to fix, but will need a 64-bit machine 
to reproduce. What should be happening is that when we create the distribution 
artifacts, we should make sure to remove the /WX flags in the win32 build 
scripts. It is a matter of applying SED.

Regards,
Senaka

> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows
> 
>
> Key: AXIS2C-1116
> URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Windows)
>Affects Versions: 1.4.0
> Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
>Reporter: Senaka Fernando
>Assignee: Senaka Fernando
>Priority: Critical
> Fix For: Current (Nightly)
>
>
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows. These must be removed by the scripts 
> used for making distributions, which AFAIU is not happening.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1203) More readable LOG Macros.

[Ruwan Janapriya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ruwan Janapriya updated AXIS2C-1203:


Attachment: readable_macro_correction.patch

That is true, readable_macro_correction.patch would do the job. This is the 
patch for the current svn. 

> More readable LOG Macros.
> -
>
> Key: AXIS2C-1203
> URL: https://issues.apache.org/jira/browse/AXIS2C-1203
> Project: Axis2-C
>  Issue Type: Improvement
> Environment: Any
>Reporter: Ruwan Janapriya
>Assignee: Supun Kamburugamuva
> Attachments: readable_macro.patch, readable_macro_correction.patch
>
>
> Current Macros to log are considerably long, so more readable log macros are 
> suggested. Also the suggested approach will have project/module name in one 
> place and each "LOG" call would print that before the message.
> e.g. 
> #define AXIS2_LOG_DEBUG_MSG(log, msg) AXIS2_LOG_DEBUG (log, AXIS2_LOG_SI, "%s 
> %s", AXIS2_LOG_PROJECT_PREFIX, msg)
> in the user project header,
> #ifdef AXIS2_LOG_PROJECT_PREFIX
>   #undef AXIS2_LOG_PROJECT_PREFIX
> #endif
> #define AXIS2_LOG_PROJECT_PREFIX "[Project XYZ]"
> in the user project source,
> AXIS2_LOG_DEBUG_MSG(env->log, "Debug Message Tik Tak Too");
> the expected output would be,
> [Mon Apr 28 23:22:08 2008] [debug] ..\..\src\tiktak.c(246) [Project XYZ] 
> Debug Message Tik Tak Too

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1116) /WX (warn-to-error) flags in windows makefiles found in source distributions leads to build breaks on 64-bit windows

[Supun Kamburugamuva (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608321#action_12608321
 ] 

Supun Kamburugamuva commented on AXIS2C-1116:
-

Hi Everyone,

This issue is marked critical. I don't have access to a 64 bit machine right 
now. So can anybody with access to a 64 bit machine have a look at this please?

Supun..  

> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows
> 
>
> Key: AXIS2C-1116
> URL: https://issues.apache.org/jira/browse/AXIS2C-1116
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Windows)
>Affects Versions: 1.4.0
> Environment: Windows-64bit, Axis2/C 1.3.1 source distributions
>Reporter: Senaka Fernando
>Assignee: Senaka Fernando
>Priority: Critical
> Fix For: Current (Nightly)
>
>
> /WX (warn-to-error) flags in windows makefiles found in source distributions 
> leads to build breaks on 64-bit windows. These must be removed by the scripts 
> used for making distributions, which AFAIU is not happening.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1201) When same operation is defined in Service level as well as module level, service level operation should be used.

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608322#action_12608322
 ] 

Damitha Kumarage commented on AXIS2C-1201:
--

Module is a way of extention to the Axis2/C core functionality. Service writer 
utilize functionlity provdided by Axis2/C core + mdules. So it is natural for 
him to expect the ability to override the functionlity provided by 
core+modules. So +1 from me.

> When same operation is defined in Service level as well as module level, 
> service level operation should be used.
> 
>
> Key: AXIS2C-1201
> URL: https://issues.apache.org/jira/browse/AXIS2C-1201
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: core/deployment
>Affects Versions: Current (Nightly)
>Reporter: S.Uthaiyashankar
>Assignee: S.Uthaiyashankar
> Fix For: 1.4.1
>
>
> Module operations will be added to the services for which the module is 
> engaged. Since module operations are global for all the services engaging it, 
> it is natural to overwrite operation settings in service.xml. For example, if 
> security policy is given in module level operation and if a particular 
> service wants to give a different policy to that operation, we should be able 
> to define same operation in service.xml with different security policy. In 
> such cases, policy defined in service.xml should be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1180) SSL Communication and the CA certificate

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando reassigned AXIS2C-1180:
---

Assignee: Senaka Fernando

> 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
>
> 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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1179) Axis2-C Unicode Support

[Supun Kamburugamuva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Supun Kamburugamuva resolved AXIS2C-1179.
-

Resolution: Won't Fix

Moving to Axis2/C 2.0.

> Axis2-C Unicode Support
> ---
>
> Key: AXIS2C-1179
> URL: https://issues.apache.org/jira/browse/AXIS2C-1179
> Project: Axis2-C
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.2.0
> Environment: Windows XP SP2
>Reporter: Dayakar Reddy
> Fix For: 1.2.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Hi, 
> I would like know, whether Axis2\C 1.2.0 supports UNICODE ? 
> I am using Axis2\C for just accessing the Web Services from the server. i.e I 
> am creating Axis2\C client. 
> If there is no UNICODE support, then is there any way to make unicode 
> complant Axis2\C client ? 
> Thanks. 
> Dayakar

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1192) axis2c dual sample clients give a memory corruption in consecutive execution

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608318#action_12608318
 ] 

Senaka Fernando commented on AXIS2C-1192:
-

Hi Shankar,

Could this issue be related to AXIS2C-1005 and AXIS2C-1115 as well?

Regards,
Senaka

> axis2c dual sample clients give a memory corruption in consecutive execution
> 
>
> Key: AXIS2C-1192
> URL: https://issues.apache.org/jira/browse/AXIS2C-1192
> Project: Axis2-C
>  Issue Type: Bug
>  Components: samples
>Affects Versions: Current (Nightly)
> Environment: Windows XP, guththila
>Reporter: S.Uthaiyashankar
>
> axis2c dual sample clients give a memory corruption in consecutive execution.
> To recreate the issue, try running echo_blocking_dual.exe several times 
> consecutively. The corruption occurs randomly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1180) SSL Communication and the CA certificate

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608316#action_12608316
 ] 

Senaka Fernando commented on AXIS2C-1180:
-

Hi Frank,

The certificate from the server side is used to verify your authenticity. Do 
you want to do something like in a web browser? Which means automatic download 
of CA cert and go ahead.

Regards,
Senaka

> 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
>
> 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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608312#action_12608312
 ] 

Senaka Fernando commented on AXIS2C-1040:
-

Hi Dushshantha,

Well there was an instance where a developer wanted to add this capability to 
Axis2/C, sometime back (around 1  - 2 years back). Please do consider those 
discussions as well. The static build is not an easily achievable task. As Bill 
states, the approach I suggested was an alternate to what Frank spoke of. We 
might have to adopt it since we need to make sure that both modes of operation 
can co-exist. Also, please do check into the code to whether the issue has been 
partially fixed.

Regards,
Senaka

> Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in 
> static build
> -
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
>  Issue Type: Bug
>  Components: util
>Reporter: Frank Huebbers
>Assignee: Dushshantha Chandradasa
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of 
> AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608311#action_12608311
 ] 

Senaka Fernando commented on AXIS2C-1001:
-

Hi Frank,

Yes, I think the timeout interval will not solve your issue. I'm sorry for 
misinterpreting the cause sometime back. Milinda is working on this issue.

Regards,
Senaka

> Axis2/C Stress tests fail
> -
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> Project: Axis2-C
>  Issue Type: Bug
> Environment: Using an Axis2/C snapshot from 7/2/2008 compiled with 
> Guththila enabled (due to problems with libxml)
>Reporter: Frank Huebbers
>Assignee: Milinda Lakmal Pathirage
>
> I am using Axis2/C in an application which uses asynchronous web service 
> calls heavily. In this application, it can happen that several web service 
> calls are issued one after another. In my tests, however, I have noticed that 
> this almost always causes problems with Axis.
> I was able to narrow down the problem to the following test cases:
> 1. Fire several non-blocking web service calls right after each other 
> (without waiting for a response). 
>==> Always causes failure on the second call
> 2. Fire 100 web service calls one after the other (i.e., fire one, wait for 
> response, fire next)
>   ==> Causes failure randomly
> Now, it's important to note that I am reusing the axis environment and stub 
> for these calls.
> In my next series of tests, I repeated the two set-ups above. Instead of 
> reusing the stub for each call, however, I created a new stub for each call. 
> In my test, this allowed me to pass the two tests above. However, in this set 
> of tests I did not clean up the stubs,  which, of course, creates an 
> unacceptable memory leak.
> So, the next series of tests included cleaning up the stub right at the end 
> of the on_complete/on_failure callbacks. This, however,  caused crashes in 
> the axutil library. Specifically, the line of code which caused the crash was 
> (in op_client.c):
> axis2_async_result_free(args_list->op_client->async_result, th_env);
> With further investigation I was able to figure out that this caused an error 
> because in the deletion of the stub (which in my test above would happen 
> before the async_result_free above would execute) the op_client variable was 
> freed.
> So, in my final set of tests, I created a stub resource manager which, 
> essentially, frees the stubs in a time delayed fashion. This would allow the 
> thread to complete the on_complete/on_failure callback and clean up after 
> itself and then do a freeing of the stub. This seems to work very reliable 
> for me, but, as I understand it, is not the most efficient way of doing 
> things as I am required to create a new stub for every web service call.
> So, I was wondering if these scenarios are tested in the Axis2/C regression 
> tests and/or if I can do something else to get my test cases working.
> Frank

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1058) Most recent fixes to Simple Axis2 HTTP Server and mod_axis2 have not reflected in the IIS Module

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608308#action_12608308
 ] 

Senaka Fernando commented on AXIS2C-1058:
-

Hi Supun,

Thanks for the Fix. There was a small concern on the way resources (actually 
streams) was used/freed in apache_worker and iis_worker which was one stopping 
factor in creating a common method that caters for both. Please do check 
whether there aren't any memory leaks as well.

Regards,
Senaka

> Most recent fixes to Simple Axis2 HTTP Server and mod_axis2 have not 
> reflected in the IIS Module
> 
>
> Key: AXIS2C-1058
> URL: https://issues.apache.org/jira/browse/AXIS2C-1058
> Project: Axis2-C
>  Issue Type: Improvement
>Affects Versions: Current (Nightly)
>Reporter: Senaka Fernando
>Assignee: Supun Kamburugamuva
> Fix For: Current (Nightly)
>
>
> Most recent fixes to Simple Axis2 HTTP Server and mod_axis2 have not 
> reflected in the IIS Module

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1203) More readable LOG Macros.

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608309#action_12608309
 ] 

Damitha Kumarage commented on AXIS2C-1203:
--

It seems to me that the patch has a small bug in
#define AXIS2_LOG_INFO_MSG(log, msg) AXIS2_LOG_INFO (log, AXIS2_LOG_SI, "%s 
%s", AXIS2_LOG_PROJECT_PREFIX, msg)

AFAIK log info does not print file name and line number.

> More readable LOG Macros.
> -
>
> Key: AXIS2C-1203
> URL: https://issues.apache.org/jira/browse/AXIS2C-1203
> Project: Axis2-C
>  Issue Type: Improvement
> Environment: Any
>Reporter: Ruwan Janapriya
>Assignee: Supun Kamburugamuva
> Attachments: readable_macro.patch
>
>
> Current Macros to log are considerably long, so more readable log macros are 
> suggested. Also the suggested approach will have project/module name in one 
> place and each "LOG" call would print that before the message.
> e.g. 
> #define AXIS2_LOG_DEBUG_MSG(log, msg) AXIS2_LOG_DEBUG (log, AXIS2_LOG_SI, "%s 
> %s", AXIS2_LOG_PROJECT_PREFIX, msg)
> in the user project header,
> #ifdef AXIS2_LOG_PROJECT_PREFIX
>   #undef AXIS2_LOG_PROJECT_PREFIX
> #endif
> #define AXIS2_LOG_PROJECT_PREFIX "[Project XYZ]"
> in the user project source,
> AXIS2_LOG_DEBUG_MSG(env->log, "Debug Message Tik Tak Too");
> the expected output would be,
> [Mon Apr 28 23:22:08 2008] [debug] ..\..\src\tiktak.c(246) [Project XYZ] 
> Debug Message Tik Tak Too

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-721) Requesting step-by-step guides

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608307#action_12608307
 ] 

Senaka Fernando commented on AXIS2C-721:


Hi Supun,

Yep this can be considered resolved. But, the true intention will perhaps be 
solved if someone decides to write a book on Axis2/C perhaps... :D...

Regards,
Senaka

> Requesting step-by-step guides
> --
>
> Key: AXIS2C-721
> URL: https://issues.apache.org/jira/browse/AXIS2C-721
> Project: Axis2-C
>  Issue Type: Wish
>  Components: documentation
>Reporter: Senaka Fernando
>Assignee: Dushshantha Chandradasa
>
> It would be great if someone could create a step-by-step guide in creating a 
> service and a client, instead of just adding an example in the manual. What I 
> mean is an example which is gradually built from the most basic step into a 
> really advanced implimentation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-976) base64 encode length returns size of encoded string + 1.

[Senaka Fernando (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608306#action_12608306
 ] 

Senaka Fernando commented on AXIS2C-976:


Well this is not a question about backward compatibility. We have done this 
wrong. Anyway, we will need to see where it is being used, and if it has any 
potential use beyond the scope of axis2c or its subprojects we will have to fix 
this at a 2.0 perhaps. It does not suffice to create an alternate to this. 
That's a hack according to my belief.

Please also check into the way the base64 decode length is returned. So if the 
encode/decode length is specified in a similar manner we need not perhaps 
correct this at all.

Regards,
Senaka

> base64 encode length returns size of encoded string + 1.
> 
>
> Key: AXIS2C-976
> URL: https://issues.apache.org/jira/browse/AXIS2C-976
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Senaka Fernando
>Assignee: S.Uthaiyashankar
>
> base64 encode length returns size of encoded string + 1, which is incorrect. 
> This is because we assume that someone expects the length + 1 to accommodate 
> '\0' that we add. But, if we gave the same string to a strlen() it returns 
> size of encoded string. This would confuse a potential user.
> axutil_base64_encode (encoded, "senaka", 6) = 9, and strlen(encoded) = 8. 
> Also, axutil_base64_encode_len(6) = 9.
> Therefore, I think it is better to stick to the strlen() way, especially 
> because popular libraries and resources adopt that strategy. Refer [1] for 
> more information.
> [1] http://www.obviex.com/Articles/CiphertextSize.aspx
> Regards,
> Senaka

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]