[jira] Updated: (AXIS2C-980) Same code block repeat in guththila_free method

[ https://issues.apache.org/jira/browse/AXIS2C-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-980: -- Attachment: diff.txt Remove the code block and this fix a leak. Regards lahiru Same

[jira] Commented: (AXIS2C-980) Same code block repeat in guththila_free method

[ https://issues.apache.org/jira/browse/AXIS2C-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568002#action_12568002 ] Lahiru Gunathilake commented on AXIS2C-980: --- sorry! this doesn't reduce a memory

Re: [AXIS2C] HTTP Basic Authentication question

Dave Meier wrote: Hi Kauhsalye, I have looked at the manual, but it seemed like what's described there is not what I'm talking about below. It may be my not understanding it. So I'll ask a couple questions: In the manual it talks about adding to the axis2.xml file but it has a user id and

[jira] Created: (AXIS2C-980) Same code block repeat in guththila_free method

Same code block repeat in guththila_free method --- Key: AXIS2C-980 URL: https://issues.apache.org/jira/browse/AXIS2C-980 Project: Axis2-C Issue Type: Bug Components: guththila

[jira] Created: (AXIS2C-981) Service has so access to transport headers

Service has so access to transport headers -- Key: AXIS2C-981 URL: https://issues.apache.org/jira/browse/AXIS2C-981 Project: Axis2-C Issue Type: Bug Components: core/context, core/transport

[jira] Updated: (AXIS2C-981) Service has no access to transport headers

[ https://issues.apache.org/jira/browse/AXIS2C-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando updated AXIS2C-981: --- Description: Service has no access to transport headers, which can be of certain importance

[jira] Resolved: (AXIS2C-981) Service has no access to transport headers

[ https://issues.apache.org/jira/browse/AXIS2C-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-981. Resolution: Fixed Fixed Issue Service has no access to transport headers

[jira] Created: (AXIS2C-982) Mtom does not work properly when chunked transfer encoding is enabled

Mtom does not work properly when chunked transfer encoding is enabled - Key: AXIS2C-982 URL: https://issues.apache.org/jira/browse/AXIS2C-982 Project: Axis2-C Issue Type:

RE: [AXIS2C] HTTP Basic Authentication question

Hi Dave, Please take a look at the attached sample, which makes use of the message context. Read through the axis2_http_transport.h for more possibilities in terms of constants you can use. We use these constants to add info to the hash and therefore, you'll have to use them too. Regards, Senaka

Re: Exposing Transport Headers to a Service

Hi Senaka, The basic authentication is always recommended to use with a cryptographically secured connection. If not, it's not a difficult task to crack the username and password pair, which is in the form of base64 encoded text. So if the client/server must agreed upon the kind of transport

[jira] Closed: (AXIS2C-983) Following wsdl's are not working with wsdl2java tool and wsdl2c tool

[ https://issues.apache.org/jira/browse/AXIS2C-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake closed AXIS2C-983. - Resolution: Fixed This jira is not related to axis2c and raised in axis2java.

[jira] Updated: (AXIS2C-983) Following wsdl's are not working with wsdl2java tool and wsdl2c tool

[ https://issues.apache.org/jira/browse/AXIS2C-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-983: -- Attachment: nillableComplexType.wsdl FaultMapping.wsdl

[jira] Created: (AXIS2C-983) Following wsdl's are not working with wsdl2java tool and wsdl2c tool

Following wsdl's are not working with wsdl2java tool and wsdl2c tool - Key: AXIS2C-983 URL: https://issues.apache.org/jira/browse/AXIS2C-983 Project: Axis2-C Issue Type:

Re: Exposing Transport Headers to a Service

On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge [EMAIL PROTECTED] wrote: Senaka Fernando wrote: Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)... :) Yes. But still I do not accept exposing the password even for REST users.

HTTPS support -- different implementation from AXIS-J

Hi All, I was looking at AXIS2/c manuals and reading through the mailing list regarding HTTPS support, I noticed that the HTTPS support in AXIS2/c is different from AXIS-J. I was using AXIS-J for a while in the past, and I remember that in order to support HTTPS in the Client side, I will

[jira] Commented: (AXIS2C-983) Following wsdl's are not working with wsdl2java tool and wsdl2c tool

[ https://issues.apache.org/jira/browse/AXIS2C-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568426#action_12568426 ] Lahiru Gunathilake commented on AXIS2C-983: --- This jira should go in to Axis2java

[jira] Updated: (AXIS2C-983) Following wsdl's are not working with wsdl2java tool and wsdl2c tool

[ https://issues.apache.org/jira/browse/AXIS2C-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-983: -- Attachment: inquire_v2.wsdl nillableComplexType.xsd Following wsdl's

Re: Sending large attachments with Axis2/C with httpd

Hi devs, While implementing an array of buffer solution for the $subject I tried with another alternative. Please see the comment on https://issues.apache.org/jira/browse/AXIS2C-862 I also attached the modified mime_parser.c file. I don't think with the array of buffer approach we can't achieve

[AXIS2C] Rest - namespace on the response question

Hi All, I am now using REST successfully for both GET and POST calls! Thanks for all the help getting this going. I have a question about the response. The nodes all have a prefix of n but no namespace is defined for n. Shouldn't it set a valid namespace for n that matches my services

[jira] Resolved: (AXIS2C-243) utils have dependancies on axis2 core when it comes to class loading

[ https://issues.apache.org/jira/browse/AXIS2C-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-243. Resolution: Fixed Resolved issue after applying patch provided. utils have dependancies

[jira] Commented: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.

[ https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568414#action_12568414 ] Bill Mitchell commented on AXIS2C-791: -- Senaka, following your suggestion, I restored

Re: HTTPS support -- different implementation from AXIS-J

Hi Vivian, Hi All, I was looking at AXIS2/c manuals and reading through the mailing list regarding HTTPS support, I noticed that the HTTPS support in AXIS2/c is different from AXIS-J. I was using AXIS-J for a while in the past, and I remember that in order to support HTTPS in the Client

Re: Issue in using 'detach' for cloning

Hi Kasun, Kasun Indrasiri [EMAIL PROTECTED] writes: For e.g. If we try to axiom_node_to_string - it prints 'null' . But we can get any other attribute (local name or text) from the detached node. - And also for cloning nodes, we should have a better approach than 'detach'. Because, detach

[jira] Assigned: (AXIS2C-977) Service and client segfaults with the following wsdl

[ https://issues.apache.org/jira/browse/AXIS2C-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake reassigned AXIS2C-977: - Assignee: Lahiru Gunathilake Service and client segfaults with the following

Issue in using 'detach' for cloning

Hi, -There is an issue in axiom_node_detach function which is related to namespaces. Once we detach a child node from a root node and then free the allocated memory for root node, the associated namespace for the detached node is also freed. For e.g. If we try to axiom_node_to_string - it

[jira] Assigned: (AXIS2C-978) Wrong logic in codegeneration with the XSD_NOTATION.wsdl

[ https://issues.apache.org/jira/browse/AXIS2C-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake reassigned AXIS2C-978: - Assignee: Lahiru Gunathilake Wrong logic in codegeneration with the

Re: Exposing Transport Headers to a Service

On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge [EMAIL PROTECTED] wrote: Senaka Fernando wrote: Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)... :) Yes. But still I do not accept exposing the password even for REST

Re: Exposing Transport Headers to a Service

Senaka Fernando wrote: On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge [EMAIL PROTECTED] wrote: Senaka Fernando wrote: Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)... :) Yes. But still I do not accept

Re: Exposing Transport Headers to a Service

Hi Kaushalye, Even the Basic Authentication scheme works with a Challenge response mechanism. And, therefore, if the client is sending authentication information without verifying whether it is required, would be considered as intentional. And, in such a situation, if the service managed to

[jira] Resolved: (AXIS2C-980) Same code block repeat in guththila_free method

[ https://issues.apache.org/jira/browse/AXIS2C-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-980. Resolution: Fixed Assignee: Senaka Fernando Fixed Issue. Thanks Lahiru for the

[jira] Commented: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.

[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568131#action_12568131 ] Senaka Fernando commented on AXIS2C-963: Hi Bill, Your latest fix, as I see in [1]

[jira] Commented: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.

[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568079#action_12568079 ] Bill Mitchell commented on AXIS2C-963: -- Senaka, it's a good question whether a better

Re: Exposing Transport Headers to a Service

Senaka Fernando wrote: Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)... :) Yes. But still I do not accept exposing the password even for REST users. I mean this is transport level authentication. The call come to the

Re: Exposing Transport Headers to a Service

Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)... Therefore, if you have a SOAP-only service you are advised to use the SOAP Header. But, if you use REST, you may read the HTTP headers. Regards, Senaka Hi Kaushalye, Yes I

Re: Exposing Transport Headers to a Service

Hi Kaushalye, Yes I believe what you say is true. It is a violation of concern. However, what if someone needs the header itself? We can do that. However, as you say, it is not advised to use this approach. But, we can always have it. May be this could go into a #ifdef block, so that it can be

Exposing Transport Headers to a Service

Hi all, Based on Dave's request, I have added the ability for a service to observe incoming Transport Headers. I think this is a valid requirement of a Service Author. Also, this creates some concern about security of a client-request. However, I believe that we can answer these issues in this

[jira] Resolved: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.

[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-963. Resolution: Fixed Hi Bill, Seems that your fix imposes no threats on the existing

RE: Exposing Transport Headers to a Service

Hi Kaushalye and Senaka, For our web services we allow the http basic auth but we tell our customers to use it only within a secure environment, so they are using it within a secure network or they use SSL in addition. It is used for convenience in situations where the user is not worried about

Re: Exposing Transport Headers to a Service

Hi Kaushalye, I think you are correct. I'm currently investigating the way we could read a param from the axis2.xml inside core_utils.c. Regards, Senaka Senaka Fernando wrote: On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge [EMAIL PROTECTED] wrote: Senaka Fernando wrote: Hi again, Also

Re: [AXIS2C] Rest - namespace on the response question

Hi Dave, Jolly good question. I think this may be a bug. Also, I would like to see the response you got for your SOAP call, if it is possible. Regards, Senaka Hi All, I am now using REST successfully for both GET and POST calls! Thanks for all the help getting this going. I have a

Re: Issue in using 'detach' for cloning

Dinesh Premalal wrote: Hi Kasun, Kasun Indrasiri [EMAIL PROTECTED] writes: For e.g. If we try to axiom_node_to_string - it prints 'null' . But we can get any other attribute (local name or text) from the detached node. - And also for cloning nodes, we should have a better approach than