[jira] Resolved: (AXIS2C-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
[ https://issues.apache.org/jira/browse/AXIS2C-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal resolved AXIS2C-925. Resolution: Fixed Fix Version/s: 1.2.1 Assignee: Dinesh Premalal patch applied ! Thanks Bill . > seg fault in axiom_soap_fault_get_text if SOAP 1.1 > -- > > Key: AXIS2C-925 > URL: https://issues.apache.org/jira/browse/AXIS2C-925 > Project: Axis2-C > Issue Type: Bug > Components: xml/soap >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml2, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal > Fix For: 1.2.1 > > Attachments: soapfault.diff > > > If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the > client calls axiom_soap_fault_get_text. At the time of the crash, using the > debugger the om_ele_node in the fault_value points to memory that has been > reused, probably as a result of being released. When axiom_element_get_text > is called, the data_element it is passed appears to be overwritten or reused, > so axiom_element_get_text sees om_element->text_value as nonzero, tries to > free it, and the C runtime diagnoses a memory management error on the free. > Stepping through with the debugger, the crux of the problem lies in > soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the > fault_value_node, converts its contents to text, issues the free_tree to free > the node and its children, but leaves the pointer as the > axiom_soap_fault_value_base_node. So the later call to > axiom_soap_fault_get_text believes there is still a node tree structure > present. The same oversight occurs when processing the fault_reason. The > axiom_soap_fault_text_base_node is detached, converted to a single text > string, the node tree is freed, but the pointer is left as the > axiom_soap_fault_base_node. -- 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-926) unit test program to test linked_list.c
[ https://issues.apache.org/jira/browse/AXIS2C-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563895#action_12563895 ] Dinesh Premalal commented on AXIS2C-926: Manoj, Could you provide a patch relevant to these changes please. It makes our life easier. > unit test program to test linked_list.c > --- > > Key: AXIS2C-926 > URL: https://issues.apache.org/jira/browse/AXIS2C-926 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: build.sh, link_list_test.c > > > I wrote a unit test program to test linked_list.c. Please review it and apply > the patch to axis2c/util/test location. To apply the patch you have to create > a folder call linked_list and put test_linked_list.c and build.sh file to > that. -- 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-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563902#action_12563902 ] Supun Kamburugamuva commented on AXIS2C-933: Please don't commit them. I will commit them as soon as I go through them. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- 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-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563909#action_12563909 ] Dinesh Premalal commented on AXIS2C-861: Hi Bill, I tried to commit this patch, but I couldn't. I think some line numbers are changed. If you could find some time please commit it. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl_diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- 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-938) axis2_http_transport_utils_is_doing_rest methods not used
[ https://issues.apache.org/jira/browse/AXIS2C-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-938. Resolution: Fixed Fixed > axis2_http_transport_utils_is_doing_rest methods not used > - > > Key: AXIS2C-938 > URL: https://issues.apache.org/jira/browse/AXIS2C-938 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http, util >Affects Versions: Current (Nightly) >Reporter: Senaka Fernando >Priority: Trivial > > axis2_http_transport_utils_is_doing_rest and > axis2_http_transport_utils_is_doing_rest_through_post is not used in our > code. There is no logic inside these methods and is not required for REST > implementations. Therefore, we can remove them. AXIS2C-935 resolves this > issue. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563906#action_12563906 ] Dinesh Premalal commented on AXIS2C-933: Ok, That would be fine. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- 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-935) Support for RESTful Services
[ https://issues.apache.org/jira/browse/AXIS2C-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-935. Resolution: Fixed Fixed > Support for RESTful Services > > > Key: AXIS2C-935 > URL: https://issues.apache.org/jira/browse/AXIS2C-935 > Project: Axis2-C > Issue Type: Improvement > Components: core/context, core/deployment, core/description, > core/engine, core/phaseresolver, core/transport, samples, transport/http, util >Affects Versions: Current (Nightly) >Reporter: Senaka Fernando > Attachments: diff_rest.txt > > > I have added Support for RESTful Services on Axis2/C. This includes support > for PUT, DELETE and REST-style invocations. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2C-845) samples configure command should be corrected.
[
https://issues.apache.org/jira/browse/AXIS2C-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Premalal reassigned AXIS2C-845:
--
Assignee: Dinesh Premalal
> samples configure command should be corrected.
> --
>
> Key: AXIS2C-845
> URL: https://issues.apache.org/jira/browse/AXIS2C-845
> Project: Axis2-C
> Issue Type: Bug
> Components: build system (Unix/Linux)
>Affects Versions: Current (Nightly)
> Environment: Ubuntu 7.10
>Reporter: Krishantha Samaraweera
>Assignee: Dinesh Premalal
>Priority: Minor
> Attachments: diff.txt
>
>
> samples configure command specified in installation guide has a typing
> mistake, one curly bracket is missing.
> existing command:
> ./configure --prefix=${AXIS2C_HOME}
> --with-axis2=$AXIS2C_HOME}/include/axis2-1.2
> this should be changed as
> ./configure --prefix=${AXIS2C_HOME}
> --with-axis2=${AXIS2C_HOME}/include/axis2-1.2
--
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-845) samples configure command should be corrected.
[
https://issues.apache.org/jira/browse/AXIS2C-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Premalal resolved AXIS2C-845.
Resolution: Fixed
Fix Version/s: 1.2.1
Senaka has fixed this issue.
> samples configure command should be corrected.
> --
>
> Key: AXIS2C-845
> URL: https://issues.apache.org/jira/browse/AXIS2C-845
> Project: Axis2-C
> Issue Type: Bug
> Components: build system (Unix/Linux)
>Affects Versions: Current (Nightly)
> Environment: Ubuntu 7.10
>Reporter: Krishantha Samaraweera
>Assignee: Dinesh Premalal
>Priority: Minor
> Fix For: 1.2.1
>
> Attachments: diff.txt
>
>
> samples configure command specified in installation guide has a typing
> mistake, one curly bracket is missing.
> existing command:
> ./configure --prefix=${AXIS2C_HOME}
> --with-axis2=$AXIS2C_HOME}/include/axis2-1.2
> this should be changed as
> ./configure --prefix=${AXIS2C_HOME}
> --with-axis2=${AXIS2C_HOME}/include/axis2-1.2
--
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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-857: -- Attachment: (was: diff.txt) > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-857: -- Attachment: diff.txt > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-857: -- Attachment: (was: diff.txt) > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-857: -- Attachment: diff.txt > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-856) axiom_element_get_children() code behavior does not match header description
[ https://issues.apache.org/jira/browse/AXIS2C-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-856: -- Attachment: diff.txt > axiom_element_get_children() code behavior does not match header description > > > Key: AXIS2C-856 > URL: https://issues.apache.org/jira/browse/AXIS2C-856 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: 1.1.0 > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt > > > The comments in axiom_element.h describing the behavior of > axiom_element_get_children indicate that the returned interator is owned by > the user and must be freed by the user. In fact, the code implements this > function like axiom_element_get_children_with_qname, where the iterator is > owned by the element and is freed when the om is freed. > Obviously if the user follows the instructions in the .h file and frees the > iterator, the memory may be reused before the om structure is freed, at which > time things go rapidly downhill. > Here are the current comments: > /** > * returns a list of children iterator > * iterators free function must be called by user > */ > AXIS2_EXTERN axiom_children_iterator_t *AXIS2_CALL > axiom_element_get_children( > axiom_element_t * om_element, > const axutil_env_t * env, > axiom_node_t * element_node); > I suggest this should read: > /** > * returns a list of children iterator > * returned iterator is freed when om element struct > * is freed > * iterators reset function must be called by user > */ > AXIS2_EXTERN axiom_children_iterator_t *AXIS2_CALL > axiom_element_get_children( > ... -- 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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal resolved AXIS2C-857. Resolution: Fixed Fix Version/s: 1.2.1 Assignee: Dinesh Premalal Patch applied ! Thanks Bill and Lahiru for the input. > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-618) Engine has a dependancy on HTTP transport.
[ https://issues.apache.org/jira/browse/AXIS2C-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-618: -- Assignee: Senaka Fernando > Engine has a dependancy on HTTP transport. > -- > > Key: AXIS2C-618 > URL: https://issues.apache.org/jira/browse/AXIS2C-618 > Project: Axis2-C > Issue Type: Bug > Components: core/engine, core/transport >Reporter: Dinesh Premalal >Assignee: Senaka Fernando > Attachments: axis2_out_transport_info.h, diff.txt > > > msg_ctx.c used a function axis2_msg_ctx_get_http_out_transport_info , which > is defined in axis2_http_out_transport_info.h which leads to have a > dependency on HTTP transport. > Since this dependency , I happen to link axis2_http_util and > axis2_http_common to build XMPP transport. it seems quite silly dependency :( -- 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-853) /INCREMENTAL linker option not required
[ https://issues.apache.org/jira/browse/AXIS2C-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-853: -- Assignee: Senaka Fernando > /INCREMENTAL linker option not required > --- > > Key: AXIS2C-853 > URL: https://issues.apache.org/jira/browse/AXIS2C-853 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Attachments: diff.txt > > > The /INCREMENTAL linker option needs an additional argument, YES or NO. With > /DEBUG, the default behaviour is /INCREMENTAL:YES, and if what we wanted was > incremental linking, we can simply remove that flag. But, if we were trying > to stop it, we need to change it (in the makefile) as /INCREMENTAL:NO. This > will reduce size of binaries, in a release version. But, since we are adding > that option in a debug build, where actually it is necessary to incrementally > link, we can simply remove that option. -- 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-868) Function axiom_element_create[Alastair FETTES]
[ https://issues.apache.org/jira/browse/AXIS2C-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-868: -- Assignee: Senaka Fernando > Function axiom_element_create[Alastair FETTES] > -- > > Key: AXIS2C-868 > URL: https://issues.apache.org/jira/browse/AXIS2C-868 > Project: Axis2-C > Issue Type: Bug >Affects Versions: Current (Nightly) > Environment: Ubuntu 7.04 >Reporter: Lahiru Gunathilake >Assignee: Senaka Fernando > Fix For: Current (Nightly) > > > AXIS2_EXTERN > axiom_element_t* axiom_element_create( > const axutil_env_t* env, > axiom_node_t* parent, > const axis2_char_t* localname, > axiom_namespace_t*ns, > axiom_node_t**node) > The axiom_node_t instance node has responsibility for the returned > axion_element_t*. Therefore, calls to axiom_node_free_tree will free this > returned element (in addition to all the child nodes of node). The memory > allocated for the return value should not be de-allocated using > axiom_element_free in this scenario, since it is internally tied to the node. -- 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-837) SOAPAction dispatching
[ https://issues.apache.org/jira/browse/AXIS2C-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-837. Resolution: Fixed > SOAPAction dispatching > -- > > Key: AXIS2C-837 > URL: https://issues.apache.org/jira/browse/AXIS2C-837 > Project: Axis2-C > Issue Type: Bug > Components: build system (Unix/Linux) > Environment: Suse Linux 9.1, gcc 3.3, Axis Java nightly build >Reporter: Michael Sutter >Assignee: Senaka Fernando >Priority: Minor > Fix For: Current (Nightly) > > Attachments: axis2.xml, diff.txt > > > By accessing a c webservice with no parameters with a Java client to > dispatching of the sent SOAP Action is not working. The Java client always > get a Operation Not Found exception. The SOAP requests looks like this: > POST /axis2/services/DAQStatus/getStatus HTTP/1.1 > Content-Type: application/soap+xml; charset=UTF-8; action="urn:getStatus" > User-Agent: Axis2 > Host: 192.168.12.100:9090 > Transfer-Encoding: chunked > 93 > xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";> /> > 0 > So the SOAP Action is sent. To fix this in the client simply add the method > to call to the request uri (shown above getStatus). -- 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-837) SOAPAction dispatching
[ https://issues.apache.org/jira/browse/AXIS2C-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-837: -- Assignee: Senaka Fernando > SOAPAction dispatching > -- > > Key: AXIS2C-837 > URL: https://issues.apache.org/jira/browse/AXIS2C-837 > Project: Axis2-C > Issue Type: Bug > Components: build system (Unix/Linux) > Environment: Suse Linux 9.1, gcc 3.3, Axis Java nightly build >Reporter: Michael Sutter >Assignee: Senaka Fernando >Priority: Minor > Fix For: Current (Nightly) > > Attachments: axis2.xml, diff.txt > > > By accessing a c webservice with no parameters with a Java client to > dispatching of the sent SOAP Action is not working. The Java client always > get a Operation Not Found exception. The SOAP requests looks like this: > POST /axis2/services/DAQStatus/getStatus HTTP/1.1 > Content-Type: application/soap+xml; charset=UTF-8; action="urn:getStatus" > User-Agent: Axis2 > Host: 192.168.12.100:9090 > Transfer-Encoding: chunked > 93 > xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";> /> > 0 > So the SOAP Action is sent. To fix this in the client simply add the method > to call to the request uri (shown above getStatus). -- 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-916) C++ style comments found in code.
[ https://issues.apache.org/jira/browse/AXIS2C-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-916: -- Assignee: Senaka Fernando > C++ style comments found in code. > - > > Key: AXIS2C-916 > URL: https://issues.apache.org/jira/browse/AXIS2C-916 > Project: Axis2-C > Issue Type: Bug >Affects Versions: Current (Nightly) >Reporter: Senaka Fernando >Assignee: Senaka Fernando >Priority: Minor > Attachments: diff.txt > > > C++ style comments found in code. Inspired by AXIS2C-911, I decided to remove > all such occurrences. Refer diff.txt. However, some of the patched files > contains ^M characters and trying to remove them either using dos2unix or > manually makes the diff invalid. Due to this reason I have left them the way > they were. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2C-881) Function axis2_svc_client_remove_all_headers [Alastair FETTES]
[ https://issues.apache.org/jira/browse/AXIS2C-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-881: -- Assignee: Senaka Fernando > Function axis2_svc_client_remove_all_headers [Alastair FETTES] > -- > > Key: AXIS2C-881 > URL: https://issues.apache.org/jira/browse/AXIS2C-881 > Project: Axis2-C > Issue Type: Bug > Components: core/clientapi >Affects Versions: Current (Nightly) > Environment: Ubuntu >Reporter: Lahiru Gunathilake >Assignee: Senaka Fernando > Fix For: Current (Nightly) > > > > AXIS2_EXTERN > axis2_status_t axis2_svc_client_remove_all_headers( > axis2_svc_client_t*svc_client, > const axutil_env_t*env) > > This function does not take responsibility for the memory allocated to the > pointers passed to it. In addition, the memory passed to the function > axis2_svc_client_add_header through the parameter header is not de-allocated > by this function (axis2_svc_client_remove_all_headers). This can create a > possible memory leak. When in used in conjunction with a call to > axis2_svc_client_send_receive_non_blocking, this is not a problem as this > function will clean up the headers itself (this is assumed, since when you > free the header nodes, an access violations occur when the SOAP message is > sent and the calling function tries to free the SOAP message data, i.e. the > header nodes). > Solution: Document memory ownership for parameters and return value. > Investigate potential memory leak. -- 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-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 reassigned AXIS2C-243:
--
Assignee: Senaka Fernando (was: Sanjaya Ratnaweera)
> utils have dependancies on axis2 core when it comes to class loading
>
>
> Key: AXIS2C-243
> URL: https://issues.apache.org/jira/browse/AXIS2C-243
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: Current (Nightly)
>Reporter: Damitha Kumarage
>Assignee: Senaka Fernando
> Attachments: axis2_core_dll_desc.h, diff.txt
>
>
> At the moment
> we have this in util/include/axis2_dll_desc.h.
>
> typedef enum axis2_dll_type
> {
> /** service dll */
> AXIS2_SVC_DLL = 0,
> /** handler dll */
> AXIS2_HANDLER_DLL,
> /** message receiver dll */
> AXIS2_MSG_RECV_DLL,
> /** module dll */
> AXIS2_MODULE_DLL,
> /** transport receiver dll */
> AXIS2_TRANSPORT_RECV_DLL,
> /** transport sender dll */
> AXIS2_TRANSPORT_SENDER_DLL
> }axis2_dll_type_t;
>
> This is a layering violation. The util layer
> should contain low-level stuff that doesn't depend on the core. This
> list of DLL types, although it is in util, conceptually is describing an
> aspect of core (the kinds of DLL that core can load). If you changed
> the structure of core or even some other module (for example dynamically
> loading
> security modules), then you would have to modify util.
> The right solution is just to make the dll type be a string.
> The util layer knows only hat it's a string, but doesn't know what the
> legal string values are. The core layer would then define constants for
> the kinds of DLLs it needs (eg "svc" for the AXIS2_SVC_DLL), and the
> security layer can do likewise.
--
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-937) axiom_util_get_child_text() is not implemented
[ https://issues.apache.org/jira/browse/AXIS2C-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Malinda Kaushalye Kapuruge resolved AXIS2C-937. --- Resolution: Fixed Implemented. Now it's posisble to get text value of a node having child text node as follows txt_val = axiom_util_get_child_text(node, env); MYTXT txt_val = MYTXT > axiom_util_get_child_text() is not implemented > -- > > Key: AXIS2C-937 > URL: https://issues.apache.org/jira/browse/AXIS2C-937 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) > Environment: N/A >Reporter: Malinda Kaushalye Kapuruge >Assignee: Malinda Kaushalye Kapuruge > Fix For: Current (Nightly) > > > axiom_util_get_child_text() function is specified in the header but not > implemented in the src. -- 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] Closed: (AXIS2C-937) axiom_util_get_child_text() is not implemented
[ https://issues.apache.org/jira/browse/AXIS2C-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Malinda Kaushalye Kapuruge closed AXIS2C-937. - > axiom_util_get_child_text() is not implemented > -- > > Key: AXIS2C-937 > URL: https://issues.apache.org/jira/browse/AXIS2C-937 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Affects Versions: Current (Nightly) > Environment: N/A >Reporter: Malinda Kaushalye Kapuruge >Assignee: Malinda Kaushalye Kapuruge > Fix For: Current (Nightly) > > > axiom_util_get_child_text() function is specified in the header but not > implemented in the src. -- 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-942) date time formate should change in duration test
date time formate should change in duration test Key: AXIS2C-942 URL: https://issues.apache.org/jira/browse/AXIS2C-942 Project: Axis2-C Issue Type: Bug Components: tests Reporter: Manoj Pushpakumara Priority: Minor The date time formate which we need to give for duration test should changed. please review the patch and apply it. -- 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-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-942: -- Attachment: duration.diff > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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-926) unit test program to test linked_list.c
[ https://issues.apache.org/jira/browse/AXIS2C-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564024#action_12564024 ] Manoj Pushpakumara commented on AXIS2C-926: --- Hi denesh ayya Thank you. I will provide a patch from next next changes. > unit test program to test linked_list.c > --- > > Key: AXIS2C-926 > URL: https://issues.apache.org/jira/browse/AXIS2C-926 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: build.sh, link_list_test.c > > > I wrote a unit test program to test linked_list.c. Please review it and apply > the patch to axis2c/util/test location. To apply the patch you have to create > a folder call linked_list and put test_linked_list.c and build.sh file to > that. -- 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-943) Modified unit test program to test linked_list.c
Modified unit test program to test linked_list.c Key: AXIS2C-943 URL: https://issues.apache.org/jira/browse/AXIS2C-943 Project: Axis2-C Issue Type: Improvement Components: tests Reporter: Manoj Pushpakumara Priority: Minor I modified the unit test program which I wrote to test linked_list.c and attached it. please review and apply this patch to axis2c/util/test location. -- 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-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-942: -- Attachment: (was: duration.diff) > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-942: -- Attachment: duration.diff > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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] Commented: (AXIS2C-861) Enable client session management through http cookies in libcurl
I have updated changes that merge in the new support of HTTP headers in axis2_libcurl.c. But before checking anything in, I wanted to research the convention for revision comments, and what to do to make sure I don't mess up the file by inserting DOS carriage return characters. It appears to me from SVN documentation that the DOS end-of-line sequences inserted by Visual Studio should be cleaned up automatically, provided svn:eol-style is set to native. And the Apache recommendations seem to encourage this to be setup correctly when the files are first created. But, at least on the first file I checked, I couldn't see that the eol-style property was set. So, what is the convention here? Do we not worry about this? Or should we run dos2unix to clean up files before checking them in from Windows? Thanks, Bill Mitchell -Original Message- From: Dinesh Premalal (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 3:08 AM To: [EMAIL PROTECTED] Subject: [jira] Commented: (AXIS2C-861) Enable client session management through http cookies in libcurl [ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563909#action_12563909 ] Dinesh Premalal commented on AXIS2C-861: Hi Bill, I tried to commit this patch, but I couldn't. I think some line numbers are changed. If you could find some time please commit it. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl_diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- 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] Commented: (AXIS2C-861) Enable client session management through http cookies in libcurl
Hi Bill, > So, what is the convention here? Do we not worry about this? Or should > we run dos2unix to clean up files before checking them in from Windows? AFAIK, we are happy to see them without DOS carriage return characters. I think Senaka is cleaning some of them. I think it is good to run dos2unix before commit. Just my 2 cents. thanks, Dinesh -- http://nethu.org/
[jira] Assigned: (AXIS2C-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando reassigned AXIS2C-942: -- Assignee: Senaka Fernando > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Senaka Fernando >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564128#action_12564128 ] Senaka Fernando commented on AXIS2C-942: Hi Manoj, I think you have to remove 'stock' from the Makefile/configure.ac and redo a diff. Also, I believe the string should be of the form "P%dY%dM%dDT%dH%dM%fS" because, we serialize it in that way. An optional "-" can be prefixed. I am saying so because, axutil_duration_create_from_string calls the axutil_duration_deserialize_duration method. And, if the serialized string can't be de-serialized it is obviously a bug. Regards, Senaka > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Senaka Fernando >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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-853) /INCREMENTAL linker option not required
[ https://issues.apache.org/jira/browse/AXIS2C-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-853. Resolution: Fixed Resolved. The basis of the fix can be found at [1]. [1] http://msdn2.microsoft.com/en-us/library/4khtbfyf.aspx Regards, Senaka > /INCREMENTAL linker option not required > --- > > Key: AXIS2C-853 > URL: https://issues.apache.org/jira/browse/AXIS2C-853 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Attachments: diff.txt > > > The /INCREMENTAL linker option needs an additional argument, YES or NO. With > /DEBUG, the default behaviour is /INCREMENTAL:YES, and if what we wanted was > incremental linking, we can simply remove that flag. But, if we were trying > to stop it, we need to change it (in the makefile) as /INCREMENTAL:NO. This > will reduce size of binaries, in a release version. But, since we are adding > that option in a debug build, where actually it is necessary to incrementally > link, we can simply remove that option. -- 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-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
[ https://issues.apache.org/jira/browse/AXIS2C-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564151#action_12564151 ] Bill Mitchell commented on AXIS2C-925: -- I updated to newer sources, retested, recreated the SOAP 1.1 fault situation and verified that it is handled correctly. Thanks, Dinesh. > seg fault in axiom_soap_fault_get_text if SOAP 1.1 > -- > > Key: AXIS2C-925 > URL: https://issues.apache.org/jira/browse/AXIS2C-925 > Project: Axis2-C > Issue Type: Bug > Components: xml/soap >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml2, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal > Fix For: 1.2.1 > > Attachments: soapfault.diff > > > If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the > client calls axiom_soap_fault_get_text. At the time of the crash, using the > debugger the om_ele_node in the fault_value points to memory that has been > reused, probably as a result of being released. When axiom_element_get_text > is called, the data_element it is passed appears to be overwritten or reused, > so axiom_element_get_text sees om_element->text_value as nonzero, tries to > free it, and the C runtime diagnoses a memory management error on the free. > Stepping through with the debugger, the crux of the problem lies in > soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the > fault_value_node, converts its contents to text, issues the free_tree to free > the node and its children, but leaves the pointer as the > axiom_soap_fault_value_base_node. So the later call to > axiom_soap_fault_get_text believes there is still a node tree structure > present. The same oversight occurs when processing the fault_reason. The > axiom_soap_fault_text_base_node is detached, converted to a single text > string, the node tree is freed, but the pointer is left as the > axiom_soap_fault_base_node. -- 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-881) Function axis2_svc_client_remove_all_headers [Alastair FETTES]
[ https://issues.apache.org/jira/browse/AXIS2C-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-881. Resolution: Fixed Issue Fixed. Thanks Lahiru and Alastair for the input. > Function axis2_svc_client_remove_all_headers [Alastair FETTES] > -- > > Key: AXIS2C-881 > URL: https://issues.apache.org/jira/browse/AXIS2C-881 > Project: Axis2-C > Issue Type: Bug > Components: core/clientapi >Affects Versions: Current (Nightly) > Environment: Ubuntu >Reporter: Lahiru Gunathilake >Assignee: Senaka Fernando > Fix For: Current (Nightly) > > > > AXIS2_EXTERN > axis2_status_t axis2_svc_client_remove_all_headers( > axis2_svc_client_t*svc_client, > const axutil_env_t*env) > > This function does not take responsibility for the memory allocated to the > pointers passed to it. In addition, the memory passed to the function > axis2_svc_client_add_header through the parameter header is not de-allocated > by this function (axis2_svc_client_remove_all_headers). This can create a > possible memory leak. When in used in conjunction with a call to > axis2_svc_client_send_receive_non_blocking, this is not a problem as this > function will clean up the headers itself (this is assumed, since when you > free the header nodes, an access violations occur when the SOAP message is > sent and the calling function tries to free the SOAP message data, i.e. the > header nodes). > Solution: Document memory ownership for parameters and return value. > Investigate potential memory leak. -- 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-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: libcurl.diff I am attaching a new libcurl.diff patch that merges all the changes for this issue and AXIS2C-830 with the changes already made to add http header support in AXIS2C-828. This involved separating the release of read headers, which needs to happen on every request, from the release of the axis2_libcurl structure, that now persists throughout the session. If there are no objections, I will go ahead and commit these as soon as I finish resolving my svn setup/infrastructure issues. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl.diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- 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-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: (was: libcurl_diff) > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl.diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- 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: Axis2C support for dynamic operations
Hi Senaka, This is great news, thank you. I have two questions: 1. How do I specify the alias in services.xml? 2. How do I get the original alias that was used? For example, if I map "Update*Item" to the "UpdateItem" operation, and the actual operation that comes in is "UpdateFooItem", can I get the "UpdateFooItem" or the "Foo" string from inside my server code? -Dave. -Original Message- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 11:17 PM To: Apache AXIS C Developers List Subject: RE: Axis2C support for dynamic operations Hi Dave, I did some modifications to the action-mapping and operation name resolution in the soap_action_based_dispatcher on Axis2/C. The patch is currently being moderated by the developers. Once it has been done, you may go ahead with providing any alias you desire for your operation. I will add onto this the ability to accept the '*' character, for alias mapping scenarios. You may refer issue, AXIS2C-854, at [1] for more information. This will be made available during the next week. [1] https://issues.apache.org/jira/browse/AXIS2C-854 Regards, Senaka > Hi Samisa, > > Is there any way to do the equivalent of "any" for a service? Kind of > like an "any" element in a schema, except for an operation. All I > need is to have the engine call my invoke method and at that point I > can write all the code that knows how to handle the operation. > > If this is not possible, maybe I could alter the axis2 code where it > looks up the operation and map it to an existing operation, but store > the original operation name in the context. So for example, if I have > a known operation called "Update" and a request comes in called > "UpdateFoo" I would map this operation to "Update" and store "UpdateFoo" > somewhere in the context. So I would have something like the > following in my services.xml: > > name="wsamapping">\"\" > > > Then on the response, I would need to make sure it used the original > "UpdateFoo" name. > > I don't mind going off and modifying the axis2 code for my purposes to > make this work. Can you point me to where this would be done? > > Thanks, > > -Dave. > > -Original Message- > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 6:06 PM > To: Apache AXIS C Developers List > Subject: Re: Axis2C support for dynamic operations > > This cannot be done with WSDLs because we do not have a WSDL model > associated with the description hierarchy. > > However, you can add support for new operations, dynamically to the > description hierarchy, in runtime, by accessing configuration. > However, this may have threading issues. Other problem with dynamic > operations, is how to map the operation to a function. For current > operations this happens at the server startup time. We can achieve > dynamic operation to function mapping using a custom message receiver, > which will load the functions mapped to the operation on the run. > > In short, this can be done. However, that needs lots of engineering. > > Thanks, > Samisa... > > Dave Meier wrote: >> Hi All, >> >> I have a requirement to support dynamically generated wsdls. Each >> wsdl will contain a core set of operations, but will then have >> additional operations defined. I want to use the wsdl with the core >> set of operations as my service in Axis2C, but then write code in my >> invoke method that will know about the additional new operations as >> they will follow a standard pattern. >> >> My question is, how can I get Axis2C to forward the request to my >> invoke method, for operations that are not in the services.xml file? >> >> In services.xml could I somehow use wildcards? Like this: >> >> >> \"\" >> >> >> So then a custom wsdl file would be given to a client and it could >> have operations like "UpdateFoo" and "UpdateBar", which are not in >> the > >> services.xml, but the "Update*" could match them. Then in my invoke >> method I could analyze the operation name and know what to do with it >> (e.g. "UpdateFoo" would tell me to use "Foo" logic and I would know >> how to handle that). >> >> The purpose for this is ease of use to the client. We have many >> operations that are generalized, but if I can generate new wsdl to do >> specifically what the user is trying to do, they can use these custom >> operation names directly. This will result in greatly increased >> usability. >> >> I think most of the work is on the service in my code, but I need a >> way to tell Axis2C to forward along the request even if it is not in >> the known set. Is there a way to do this, or is there a way to >> modify > >> the code to support this? >> >> Thank you much, >> >> -Dave. >> >> >> * >> * >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >
[jira] Commented: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
[
https://issues.apache.org/jira/browse/AXIS2C-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564188#action_12564188
]
Bill Mitchell commented on AXIS2C-927:
--
Although the source fix is obvious, I did verify it against a testcase. After
downloading the updated sources, I regenerated my testcase for this by
modifying one of the generated stubs and verified that it works correctly as
applied, at least in the presence of a fix for AXIS2C-834 for guththila.
> axiom_element_declare_default_namespace fails when no namespace already
> declared
>
>
> Key: AXIS2C-927
> URL: https://issues.apache.org/jira/browse/AXIS2C-927
> Project: Axis2-C
> Issue Type: Bug
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
>Reporter: Bill Mitchell
>Assignee: Dinesh Premalal
> Fix For: 1.2.1
>
> Attachments: om_element_diff
>
>
> If axiom_element_declare_default_namespace() is called before any named
> namespace is declared, it fails to perform the axutil_hash_make and as a
> result axutil_hash_set crashes on the empty namespace pointer.
> The code fragment:
> if (om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
> should read:
> if (!om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
--
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-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564199#action_12564199 ] Bill Mitchell commented on AXIS2C-859: -- Lahira, after yesterday I researched again the XML spec and I find that it says that replacement of XML characters and entity references happens on the URI to generate the normalized value. So it seems we have to do this character replacement logic on the attribute value string before we process it as a possible namespace declaration. Just another extra wrinkle. My "second" item above alluded to a different solution, built into guththila_next() instead of guththila_token_close(). One could imagine, in the "right" loops in guththila_next where we are looking at the characters one at a time anyway, we could detect the leading ampersand, check the next 4 or 5 characters against the XML character reference values, and replace the character there, again as above sliding the leading part of the token to abut the smaller single character. This would avoid a second pass over the token characters looking for the ampersands, but I suspect it would make guththila_next() much harder to understand than it already is. So my second point above was just to say that I think you have chosen the better approach, to handle this issue of XML character entities in guthtila_token_close() well separate from the token parsing in guththila_next(). > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- 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] Reopened: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-857: -- Probably thanks to Lahira and I cooperating to work on the patch, we ended up with a version in diff.txt that introduced the logic to create an xml: namespace declaration twice in guththila_init(). Obviously one of the two identical blocks of following code needs to be removed. Starting with temp_name = guththila_token_create(GUTHTHILA_XML_NAME,0,strlen(GUTHTHILA_XML_NAME), 1,0,0,env); temp_tok = guththila_token_create(GUTHTHILA_XML_URI,0,strlen(GUTHTHILA_XML_URI), 1,0,0,env); through the end of the new code at: e_namesp = NULL; } return GUTHTHILA_FAILURE; } > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both incoming
messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size -
1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that my
understanding is incorrect. But I looked at guththila_stack.c and indeed for
index 0 it returns the outermost/first element pushed, so there is no tricky
logic there to get the stack in the other order. Of course, one could indeed
fix this problem by changing guththila_stack_get_by_index() to return the
elements from the innermost/most recently pushed back out to the outermost.
This would be the easiest fix to make, and the safest in that it would not
change the logic in any of the existing loops, although it would seem less
clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index < stack->top ? stack->data[index] : NULL;
}
could be changed to read:
{
return index < stack->top ? stack->data[stack->top - index - 1] : NULL;
}
--
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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-857: -- Attachment: diff_mod.txt There's small mistake with the patch file.Same block of code repeated again in the patch. Thanks Lahiru > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt, diff_mod.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-943) Modified unit test program to test linked_list.c
[ https://issues.apache.org/jira/browse/AXIS2C-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-943: -- Attachment: link_list.diff > Modified unit test program to test linked_list.c > > > Key: AXIS2C-943 > URL: https://issues.apache.org/jira/browse/AXIS2C-943 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: link_list.diff > > > I modified the unit test program which I wrote to test linked_list.c and > attached it. please review and apply this patch to axis2c/util/test location. -- 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-945) unit test program to test om_util.c
unit test program to test om_util.c --- Key: AXIS2C-945 URL: https://issues.apache.org/jira/browse/AXIS2C-945 Project: Axis2-C Issue Type: Improvement Components: tests Reporter: Manoj Pushpakumara Priority: Minor I wrote a unit test program to test om_util.c and attached it. please review and apply this patch to axis2c/util/test location. -- 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-945) unit test program to test om_util.c
[ https://issues.apache.org/jira/browse/AXIS2C-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-945: -- Attachment: axiom_util.diff > unit test program to test om_util.c > --- > > Key: AXIS2C-945 > URL: https://issues.apache.org/jira/browse/AXIS2C-945 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: axiom_util.diff > > > I wrote a unit test program to test om_util.c and attached it. please review > and apply this patch to axis2c/util/test location. -- 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-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal resolved AXIS2C-857. Resolution: Fixed Lahiru, Applied new patch ! Thanks. > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt, diff_mod.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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-943) Modified unit test program to test linked_list.c
[ https://issues.apache.org/jira/browse/AXIS2C-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dushshantha Chandradasa reassigned AXIS2C-943: -- Assignee: Dushshantha Chandradasa > Modified unit test program to test linked_list.c > > > Key: AXIS2C-943 > URL: https://issues.apache.org/jira/browse/AXIS2C-943 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Dushshantha Chandradasa >Priority: Minor > Attachments: link_list.diff > > > I modified the unit test program which I wrote to test linked_list.c and > attached it. please review and apply this patch to axis2c/util/test location. -- 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-946) some changes of build.sh files in util/test
some changes of build.sh files in util/test --- Key: AXIS2C-946 URL: https://issues.apache.org/jira/browse/AXIS2C-946 Project: Axis2-C Issue Type: Bug Components: tests Reporter: Manoj Pushpakumara Priority: Minor I made some changes of build.sh files in util/test. please review the patch and apply it to util/test location. -- 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-946) some changes of build.sh files in util/test
[ https://issues.apache.org/jira/browse/AXIS2C-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-946: -- Attachment: change.diff > some changes of build.sh files in util/test > --- > > Key: AXIS2C-946 > URL: https://issues.apache.org/jira/browse/AXIS2C-946 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: change.diff > > > I made some changes of build.sh files in util/test. please review the patch > and apply it to util/test location. -- 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-946) some changes of build.sh files in util/test
[ https://issues.apache.org/jira/browse/AXIS2C-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dushshantha Chandradasa reassigned AXIS2C-946: -- Assignee: Dushshantha Chandradasa > some changes of build.sh files in util/test > --- > > Key: AXIS2C-946 > URL: https://issues.apache.org/jira/browse/AXIS2C-946 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Dushshantha Chandradasa >Priority: Minor > Attachments: change.diff > > > I made some changes of build.sh files in util/test. please review the patch > and apply it to util/test location. -- 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-943) Modified unit test program to test linked_list.c
[ https://issues.apache.org/jira/browse/AXIS2C-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dushshantha Chandradasa resolved AXIS2C-943. Resolution: Fixed applied the patch > Modified unit test program to test linked_list.c > > > Key: AXIS2C-943 > URL: https://issues.apache.org/jira/browse/AXIS2C-943 > Project: Axis2-C > Issue Type: Improvement > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Dushshantha Chandradasa >Priority: Minor > Attachments: link_list.diff > > > I modified the unit test program which I wrote to test linked_list.c and > attached it. please review and apply this patch to axis2c/util/test location. -- 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-946) some changes of build.sh files in util/test
[ https://issues.apache.org/jira/browse/AXIS2C-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dushshantha Chandradasa resolved AXIS2C-946. Resolution: Fixed applied the patch > some changes of build.sh files in util/test > --- > > Key: AXIS2C-946 > URL: https://issues.apache.org/jira/browse/AXIS2C-946 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Dushshantha Chandradasa >Priority: Minor > Attachments: change.diff > > > I made some changes of build.sh files in util/test. please review the patch > and apply it to util/test location. -- 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]
1.2.1 release
Hi Dinesh, Why are we releasing 1.2.1 with all the features added after 1.2 release? Shouldn't it rather be in 1.3? I guess it will be more sensible if we released 1.2.1 with patches for issues identified with 1.2 release and do a 1.3 release with the other features at a different time. Though it will not be an issue in this particular case, IMHO, doing a patch release using the trunk adds more chances of introducing incompatibilities as well as issues with stability of the release. My point is that a patch release should be done using the branch of the related minor release; 1.2 in this particular case. jm2c. thanks, Dumindu. On Jan 31, 2008 12:08 PM, <[EMAIL PROTECTED]> wrote: > Author: dinesh > Date: Wed Jan 30 22:38:39 2008 > New Revision: 617017 > > URL: http://svn.apache.org/viewvc?rev=617017&view=rev > Log: > document updated for axis2c 1.2.1 > > Modified: > webservices/axis2/trunk/c/ChangeLog > webservices/axis2/trunk/c/INSTALL > webservices/axis2/trunk/c/NEWS > webservices/axis2/trunk/c/xdocs/index.html > > Modified: webservices/axis2/trunk/c/ChangeLog > URL: > http://svn.apache.org/viewvc/webservices/axis2/trunk/c/ChangeLog?rev=617017&r1=617016&r2=617017&view=diff > == > --- webservices/axis2/trunk/c/ChangeLog (original) > +++ webservices/axis2/trunk/c/ChangeLog Wed Jan 30 22:38:39 2008 > @@ -1,3 +1,18 @@ > +Axis2/C (1.2.1) > + * Fixed a bug on version numbering > + * List Axis2/C dependencies licensing in LICENSE file > + * Add relevant copyright notices to NOTICE file > + * Digest Authentication Support > + * Proxy Authentication Support > + * Enhanced REST support > + * MTOM support with libcurl > + * Improvements to TCPMon Tool > + * Improvements to Test Coverage > + * Improvements to API docs > + * Improvements to CA certificate validation mechanisms on SSL Transport > + * Improvements to Neethi > + > +-- Axis2/C team Mon, 31 January 2008 > Axis2/C (1.2.0) > * Improvements to Java tool, WSDL2C, that generates C code > * Improvment to Apache2 module so that it > @@ -10,7 +25,7 @@ > * Memory leak fixes > * Many bug fixes > > --- Axis2/C team Mon, 24 September 2007 > +-- Axis2/C team Mon, 17 January 2008 > Axis2/C (1.1.0) > * WS-Policy implementation > * TCP Transport > > Modified: webservices/axis2/trunk/c/INSTALL > URL: > http://svn.apache.org/viewvc/webservices/axis2/trunk/c/INSTALL?rev=617017&r1=617016&r2=617017&view=diff > == > --- webservices/axis2/trunk/c/INSTALL (original) > +++ webservices/axis2/trunk/c/INSTALL Wed Jan 30 22:38:39 2008 > @@ -1,4 +1,4 @@ > -vThe release comes in two forms, source and binary. > +The release comes in two forms, source and binary. > > To get both the binary and source distributions working, you need Libxml2 > from > http://xmlsoft.org/downloads.html > > Modified: webservices/axis2/trunk/c/NEWS > URL: > http://svn.apache.org/viewvc/webservices/axis2/trunk/c/NEWS?rev=617017&r1=617016&r2=617017&view=diff > == > --- webservices/axis2/trunk/c/NEWS (original) > +++ webservices/axis2/trunk/c/NEWS Wed Jan 30 22:38:39 2008 > @@ -1,59 +1,84 @@ > Apache Axis2/C Team is pleased to announce the release of Apache Axis2/C > version 1.2.0 > You can download this release from > + > http://ws.apache.org/axis2/c/download.cgi > > Key Features > > - 1. Support for one-way messaging (In-Only) and request response > - messaging (In-Out) > - 2. Client APIs: Easy to use service client API and more advanced operation > - client API > + 1. Support for one-way messaging (In-Only) and request response messaging > (In-Out) > + 2. Client APIs: Easy to use service client API and more advanced > operation client API > 3. Transports supported: HTTP >* Inbuilt HTTP server called simple axis server >* Apache2 httpd module called mod_axis2 for server side >* IIS module for server side >* Client transport with ability to enable SSL support >* Basic HTTP Authentication > + * Digest HTTP Authentication >* libcurl based client transport > - 4. Module architecture, mechanism to extend the SOAP processing model > - 5. WS-Addressing support, both the submission (2004/08) and final > (2005/08) > - versions, implemented as a module > - 6. MTOM/XOP support > - 7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This > has > - complete XML infoset support > - 8. XML parser abstraction > + > + 4. Transports supported: HTTPS > + * HTTPS Transport implementation using OpenSSL > + > + 5. Transports supported: TCP > + * for both client and server side > + > + 6. Transport proxy support (HTTP) > + * Proxy Authentication (Basic/D
[jira] Updated: (AXIS2C-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-942: -- Attachment: (was: duration.diff) > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Senaka Fernando >Priority: Minor > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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-942) date time formate should change in duration test
[ https://issues.apache.org/jira/browse/AXIS2C-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-942: -- Attachment: duration.diff > date time formate should change in duration test > > > Key: AXIS2C-942 > URL: https://issues.apache.org/jira/browse/AXIS2C-942 > Project: Axis2-C > Issue Type: Bug > Components: tests >Reporter: Manoj Pushpakumara >Assignee: Senaka Fernando >Priority: Minor > Attachments: duration.diff > > > The date time formate which we need to give for duration test should changed. > please review the patch and apply it. -- 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]
