[jira] Resolved: (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:all-tabpanel
]
Dinesh Premalal resolved AXIS2C-927.
Resolution: Fixed
Fix Version/s: 1.2.1
Assignee: Dinesh Premalal
patch applied ! Thanks Bill for the patch.
> 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] Resolved: (AXIS2C-932) IIS module fails with service that has the name "services" in it
[
https://issues.apache.org/jira/browse/AXIS2C-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Premalal resolved AXIS2C-932.
Resolution: Fixed
Fix Version/s: 1.2.1
Assignee: Dinesh Premalal
patch applied ! Thanks Dave for the patch.
> IIS module fails with service that has the name "services" in it
>
>
> Key: AXIS2C-932
> URL: https://issues.apache.org/jira/browse/AXIS2C-932
> Project: Axis2-C
> Issue Type: Bug
> Components: transport/http
>Affects Versions: Current (Nightly)
> Environment: Windows XP.
>Reporter: Dave Meier
>Assignee: Dinesh Premalal
>Priority: Critical
> Fix For: 1.2.1
>
> Attachments: utils_c_diff.txt
>
>
> When I use the IIS module and try to call my service it fails to find the
> service. The name of my service is "aewebservices70", so the URL is
> "http://localhost:80/axis2/services/aewebservices70";. The service is not
> found.
> I found that there is a loop in axutil_parse_request_url_for_svc_and_op(...)
> where it keeps looking for "services" so it end up returning "70" as the
> service name.
> I modified the code to break out of the loop after the first "services" is
> found and that fixed it. I'm not sure if the loop is there for a reason:
> while (1)
> {
> tmp = strstr(tmp, axis2_request_url_prefix);
> if (!tmp)
> {
> break;
> }
> else
> {
> service_str = tmp;
> tmp += axutil_strlen(axis2_request_url_prefix);
> break;// I added this line to get it to work...
> }
> }
--
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=12563862#action_12563862 ] Dinesh Premalal commented on AXIS2C-933: Hi Devs, Is this patches are complete? Can I commit them into svn ? > 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-916) C++ style comments found in code.
[ https://issues.apache.org/jira/browse/AXIS2C-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563857#action_12563857 ] Dinesh Premalal commented on AXIS2C-916: I tried on Linux, but I couldn't apply it too. > 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 >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]
Re: AW: AW: [Axis2C] how to return a MsgBox
Senaka Fernando wrote: Hi all, I believe you are requesting support for session on Axis2/C? So that you can have a conversation between Client and Server. Am I missing something here? AFAIK, Bill spoke on implementing Session with CURL. Or else is this possible through Savan/C (WS-Eventing)? Regards, Senaka Hello Josef, i've read your first post, opened a reply - starting to write my thoughts down - deleted it, cause im not an expert ;-) first, i think you have to write your server side callback method outside the service, cause the service is only active when triggerd. you can use axis2 api to create payload - clear. second, if i am right, not alle mep's from wsdl are supported. i think you want to have "Solicit-response"/"out-in". i do not know corba very well, but i think your former corba server could send the message to the client, cause the client is registerd and will be found over orb/naming service !? the client seems to be permanetly connected / has a listening port !? possible solutions i can imagine for axis2 : 1. the client has to ask from time to time if something has happend on serverside. if nothing has happend on serverside, server didn't send back anythink or just a message like "no thanks, ask again". otherwise the server replys with your yes/no question, client has to answer. but i think this is not what you want, if you talk about a server side callback. 2. when starting your client, you call a "registerWithServer" method, to let the server know the clients endpoint, using the servers context, maybe at application level ? write a service (not an axis service) that has a callback. when your conditions are met, query the context and send the question. now you have the problem, that the client is not listening - you have to run a axis service on clientside :-( You can use Apache Savan/C [1] to do just that. Your service need to be Savan enabled and you can subscribe to that service providing a url for listening from the service. This url could be another axis2 service or a callback. thanks Damitha [1]http://ws.apache.org/savan/c/ 3. client sends an async message to you server, server saves all informations in context to answer and quits without reply. i do no know what will happen ;-) maybe you have to increase client-side timeout ? write non axis service and your callback, when conditions are met, query the context and create payload, then answer the initial async question. cause i do not know if it is important to answer the question yes/no immediately, when conditions are met - maybee this is also possible : 4. write a non axis service, when condition is met, write a flag to the context. when client tries to communicate (you know the user is active), query the context for the flag, send an special-fault as answer. axis-client has to interpret this fault as yes/no question, send the answer and service can do its work, reseting the flag in context. after this, the user as to resend the initial message again. mh, i don't really have an answer for you, just some thoughts and to let you know that you are not alone with webservice paradigm and its problems ;-) mfg derMark Stadelmann Josef schrieb: Hi Dinesh What relates to Axis2C and what not, how can a novice like I know that in FULL. i.e. possible Callbacks to caling clients without posting the service thread, but making it wait for the answer to occure. i.e. Agent paradigm. I am just seeking for an elegant method to invoke from within an Axis2/C server/service something like a callback to the client which askes Windows for a Windows MSGBOX with YES NO Buttons and a msg and a title. When the user then clicks a button, the answer is transfered to the waiting server/service and the service will evaluate the asnwer and can then continue. I am seeking an elegant way, one of you migth know, such as how to call back or agree on a clall back routin in the originating Axis2/C client If nobody knows that at your side of the pond, well, then I have to do it the hard way by miyelf. I generate a client side stub which is invoked by a server/service which sends to any server/service a message a title, a cpation, and some buttons or at least ID's to it. The receiving service, in this case on a windows system, will then invoke a Windows Operating System call and ask for a MsgBox. Once the button is clicked the resulting button value is then returedn as an integer to the client, which is in this case the invoked web service. I did so in the past using a corba server on a windows system Now all what changes is CORBA to WebServices And the paradigm is CLIENT -> AGENT -> question to MSG-BOX-SERVER and back. where Client is a web service client on a PC the
[jira] Resolved: (AXIS2C-866) REOPEN - /util/src/base64.c incorrect calculation of length in 'axutil_base64_decode_len'
[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Premalal resolved AXIS2C-866.
Resolution: Fixed
Fix Version/s: 1.2.1
Issue is fixed by Shankar.
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: 1.2.0
>Reporter: Frank Huebbers
>Assignee: Dinesh Premalal
>Priority: Critical
> Fix For: 1.2.1
>
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2C-866) REOPEN - /util/src/base64.c incorrect calculation of length in 'axutil_base64_decode_len'
[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Premalal reassigned AXIS2C-866:
--
Assignee: Dinesh Premalal
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: 1.2.0
>Reporter: Frank Huebbers
>Assignee: Dinesh Premalal
>Priority: Critical
> Fix For: 1.2.1
>
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-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=12563814#action_12563814 ] Lahiru Gunathilake commented on AXIS2C-859: --- Thanks Bill for the comment.Here's my idea on your comment, First:This is very similar thing what i have done and only difference is there's no memory allocation in this method.However if it's better to avoid another memory allocation i will do it in that way. Second : This is not much clear for me.If you can explain some more that'll be great. Third Forth Fifth: +1for all three ideas. I'll implement these in that way. Regards Lahiru > 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]
RE: Can AXIS2C do this?
On Tue, 2008-01-29 at 13:59 -0800, Mike McKee wrote: > We are using Simple Server. I am only interested in the Server Side. > >From the looks of the code, it looks like AXIS2C Closes the connection > after each request. This causes problems for Clients (Microsoft and > others) who explicitly put things like Keepalive, or Continue in the > headers. Our interest is in using simple server, as a server that we are > going to imbed in our application. > > Is this recommended usage of AXIS2C, or do most people imbed in IIS or > APACHE? For a production environment we recommend using Axis2/c with Apache. Because Apache can handle concurrent requests without much degradation in performance. -Manjula, > > > > -Original Message- > From: Dinesh Premalal [mailto:[EMAIL PROTECTED] On Behalf Of Dinesh > Premalal > Sent: Monday, January 28, 2008 9:15 PM > To: axis-c-dev@ws.apache.org > Subject: Re: Can AXIS2C do this? > > Hi Mike, > > "Mike McKee" <[EMAIL PROTECTED]> writes: > > 2. I noticed that CONNECTION- KEEPALIVE is giving us trouble when we > use AXIS2C > > Server with HTTP 1.1 (Microsoft Developer Studio Web Services Client). > In > > looking at the AXIS2C source code, it appears that socket connections > are > > always being closed, and that KEEPALIVE is not supported. Can you > > confirm. > > In order to support KEEPALIVE you need to have your services on > Apache2 (mod_axis2) and on client side need to build Axis2/C with > libcurl enabled. > > ./configure --enable-libcurl=yes [other options] > > thanks, > Dinesh > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-866) REOPEN - /util/src/base64.c incorrect calculation of length in 'axutil_base64_decode_len'
[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563808#action_12563808
]
S.Uthaiyashankar commented on AXIS2C-866:
-
this is already done. We can close the issue.
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: 1.2.0
>Reporter: Frank Huebbers
>Priority: Critical
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-941) IIS Module: fails with large data element
[ https://issues.apache.org/jira/browse/AXIS2C-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Meier updated AXIS2C-941: -- Attachment: aewebservicesaxis70.wsdl The call I am making is CreateFileAttachment (see in the attached wsdl). The request looks like: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"; xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";> urn:uuid:780c518c-6056-4f84-af21-0552f856a6fd http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous http://localhost/axis2/services/aewebservices70 2008-01-29T22:43:02Z 2008-01-29T22:48:02Z joe 1000:42 TeamTrack Change Management tt.pdf true 2008-01-29T14:43:01.2138881-08:00 ATTACHACCESS-DEFAULT 59215 JVBERi0xLjQNJeL...Q0KJSVFT0YNCg== I replaced the middle of the large "encodedContents" value with "..." to avoid cluttering this issue. > IIS Module: fails with large data element > - > > Key: AXIS2C-941 > URL: https://issues.apache.org/jira/browse/AXIS2C-941 > Project: Axis2-C > Issue Type: Bug > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, IIS 5.1 >Reporter: Dave Meier >Priority: Blocker > Attachments: aewebservicesaxis70.wsdl > > > I have a web service that takes the following as input. Here is the wsdl: > > > > > > maxOccurs="1" nillable="false"/> > > > > > With the axis2_http_server.exe it works fine with a 163KB file, where the > contents of the file are written in base64 into the "encodedContents" > element. But when I run the IIS module and run the same client test, I get > back an error saying that the "encodedContents" element is NULL. > I tried a 1KB file with the IIS module and that worked great. So there > appears to be something limiting the sending of a large element when using > the IIS module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-941) IIS Module: fails with large data element
IIS Module: fails with large data element - Key: AXIS2C-941 URL: https://issues.apache.org/jira/browse/AXIS2C-941 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Environment: Windows XP, IIS 5.1 Reporter: Dave Meier Priority: Blocker I have a web service that takes the following as input. Here is the wsdl: With the axis2_http_server.exe it works fine with a 163KB file, where the contents of the file are written in base64 into the "encodedContents" element. But when I run the IIS module and run the same client test, I get back an error saying that the "encodedContents" element is NULL. I tried a 1KB file with the IIS module and that worked great. So there appears to be something limiting the sending of a large element when using the IIS module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-940) Using IIS Module, if an error is returned the beginning of the response is garbled (possible memory corruption)
Using IIS Module, if an error is returned the beginning of the response is garbled (possible memory corruption) --- Key: AXIS2C-940 URL: https://issues.apache.org/jira/browse/AXIS2C-940 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Environment: Windows XP, IIS 5.1 Reporter: Dave Meier Priority: Critical Build axis2c in release mode. Set up IIS 5.1 with the IIS module. Run the following client from the command line with an incorrect operation specified. Capture the results of the response. I used HTTP Analyzer V2 to capture the request and response. tcpmon.exe did not capture the response, probably because the problem with it. Command: D:\axis2c\c\buildrel\deploy\bin\samples>math addx 3 4 http://localhost:80/axis2/services/math Using endpoint : http://localhost:80/axis2/services/math Invoking operation addx with params 3 and 4 math stub invoke FAILED! D:\axis2c\c\buildrel\deploy\bin\samples> Response: ìKæK:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";> soapenv:Receiver http://www.w3.org/XML/1998/namespace";>Operation Not Found Operation Not Found, Endpoint referance address is httplocalhost80/axis2/services/math and wsa actions is (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=12563745#action_12563745 ] Bill Mitchell commented on AXIS2C-859: -- Thanks for picking up this issue, Lahiru. I was thinking about starting to look at it in detail myself. Examining the patch, I have a couple thoughts. First, you allocate a block of memory, escape_char, to hold the copy of the token to this point. But the size of the block is 4 on most machines, the sizeof a pointer to char. So this size will frequently not be enough to copy all the characters preceding the escaped character. It occurs to me that guththila tries to go to a lot of effort to avoid allocating memory. Having worked on some issues recently in the buffer management code, I would propose a different solution: moving the data in the buffer itself. Although the obvious solution would be to replace the escaped sequence with the intended character and slide the remainder of the buffer down, this could be timeconsuming. A clever idea might be to replace the escaped sequence, placing the intended character at the end of the sequence, and copy the characters up from the start of the token, moving the token start up and reducing its size. In most cases, this would not be a large amount of data to move, and it avoids the memory allocation entirely. Second, I like where you chose to insert this code, in the token_close logic. Although I can imagine trying to make this part of guththila_next, where it could massage the buffer contents while it was deciding where the token boundaries are, it seems best to leave that logic deciding where the edges of the tokens are without changing the characters inside the tokens. Third, looking at the examples of character escaping in various texts, it appears that one can find escaped character sequences in text and in attribute values. So this logic either needs to be duplicated, not pretty, or pushed down into a lower level shared routine. Fourth, you inserted this logic in the _char_data: case. It appears to me from the XML documentation that we are supposed to replace sequences in text, but not in comments. guththila_next() seems to confuse this issue, as it treats them both as _char_data. To distinguish the two, my guess is it would be better to define a new token type, rather than cheat and look at the m->guththila_event to tell them apart. A new token type might point the direction to solving the CDATA problem, whenever that gets approached. Maybe use _char_data for the raw char data, without processing, and a new _text_data for char data that undergoes processing of entity sequences. Fifth, when checking the following characters after the ampersand, it would be best to check first that enough characters are left in the token, before looking at the characters themselves and perhaps falling off the end of the buffer. Of course, I'm relatively new to this logic, so these are just my observations. > 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]
RE: Can AXIS2C do this?
We are using Simple Server. I am only interested in the Server Side. >From the looks of the code, it looks like AXIS2C Closes the connection after each request. This causes problems for Clients (Microsoft and others) who explicitly put things like Keepalive, or Continue in the headers. Our interest is in using simple server, as a server that we are going to imbed in our application. Is this recommended usage of AXIS2C, or do most people imbed in IIS or APACHE? -Original Message- From: Dinesh Premalal [mailto:[EMAIL PROTECTED] On Behalf Of Dinesh Premalal Sent: Monday, January 28, 2008 9:15 PM To: axis-c-dev@ws.apache.org Subject: Re: Can AXIS2C do this? Hi Mike, "Mike McKee" <[EMAIL PROTECTED]> writes: > 2. I noticed that CONNECTION- KEEPALIVE is giving us trouble when we use AXIS2C > Server with HTTP 1.1 (Microsoft Developer Studio Web Services Client). In > looking at the AXIS2C source code, it appears that socket connections are > always being closed, and that KEEPALIVE is not supported. Can you > confirm. In order to support KEEPALIVE you need to have your services on Apache2 (mod_axis2) and on client side need to build Axis2/C with libcurl enabled. ./configure --enable-libcurl=yes [other options] thanks, Dinesh -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-880) Function axis2_svc_client_add_header[Alastair FETTES]
[ https://issues.apache.org/jira/browse/AXIS2C-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal resolved AXIS2C-880. Resolution: Fixed Fix Version/s: (was: Current (Nightly)) 1.2.1 patch applied. Thanks Senaka, Alastair and Lahiru for the input. > Function axis2_svc_client_add_header[Alastair FETTES] > - > > Key: AXIS2C-880 > URL: https://issues.apache.org/jira/browse/AXIS2C-880 > Project: Axis2-C > Issue Type: Bug > Components: core/clientapi >Affects Versions: Current (Nightly) > Environment: Ubuntu 7.04 >Reporter: Lahiru Gunathilake >Assignee: Dinesh Premalal > Fix For: 1.2.1 > > Attachments: diff.txt > > > > AXIS2_EXTERN > axis2_status_t axis2_svc_client_add_header( > axis2_svc_client_t* svc_client, > const axutil_env_t* env, > axiom_node_t* header) > > The parameter svc_client does not take responsibility for the memory > allocated for header, although it does maintain an internal pointer to the > data. This can result in dangling pointer situations if the caller deletes > the memory passed using header before svc_client has a chance to remove the > header. > Solution: Document memory ownership for parameters and return value. > Investigate the use of pointers in the internal structure to avoid dangling > pointer situations. -- 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-880) Function axis2_svc_client_add_header[Alastair FETTES]
[ https://issues.apache.org/jira/browse/AXIS2C-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal reassigned AXIS2C-880: -- Assignee: Dinesh Premalal > Function axis2_svc_client_add_header[Alastair FETTES] > - > > Key: AXIS2C-880 > URL: https://issues.apache.org/jira/browse/AXIS2C-880 > Project: Axis2-C > Issue Type: Bug > Components: core/clientapi >Affects Versions: Current (Nightly) > Environment: Ubuntu 7.04 >Reporter: Lahiru Gunathilake >Assignee: Dinesh Premalal > Fix For: Current (Nightly) > > Attachments: diff.txt > > > > AXIS2_EXTERN > axis2_status_t axis2_svc_client_add_header( > axis2_svc_client_t* svc_client, > const axutil_env_t* env, > axiom_node_t* header) > > The parameter svc_client does not take responsibility for the memory > allocated for header, although it does maintain an internal pointer to the > data. This can result in dangling pointer situations if the caller deletes > the memory passed using header before svc_client has a chance to remove the > header. > Solution: Document memory ownership for parameters and return value. > Investigate the use of pointers in the internal structure to avoid dangling > pointer situations. -- 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-774) echo_non_blocking.c sample's timeout value is too high
[ https://issues.apache.org/jira/browse/AXIS2C-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal resolved AXIS2C-774. Resolution: Fixed Fix Version/s: 1.2.1 Current (Nightly) Assignee: Dinesh Premalal (was: Sanjaya Ratnaweera) > echo_non_blocking.c sample's timeout value is too high > -- > > Key: AXIS2C-774 > URL: https://issues.apache.org/jira/browse/AXIS2C-774 > Project: Axis2-C > Issue Type: Bug > Components: samples > Environment: Ubuntu 7.10 (Gutsy Gibbon) >Reporter: Senaka Fernando >Assignee: Dinesh Premalal > Fix For: Current (Nightly), 1.2.1 > > Attachments: diff.txt > > > The echo_non_blocking.c sample's timeout value is too high. Please refer > proposed patch (diff.txt) -- 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-774) echo_non_blocking.c sample's timeout value is too high
[ https://issues.apache.org/jira/browse/AXIS2C-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563650#action_12563650 ] Dinesh Premalal commented on AXIS2C-774: There is a problem in the compiler options that we used. In samples we used "$CFLAGS -ansi -Wall -D_LARGEFILE64_SOURCE " where as to build the core we use CFLAGS as "CFLAGS="$CFLAGS -ansi -Wall -Wno-implicit-function-declaration" . At src/core/clientapi/svc_client.c we don't get above warning because we have used -Wno-implicit-function-declaration. Adding -Wno-implicit-function-declaration into samples/configure.ac will solve the problem. > echo_non_blocking.c sample's timeout value is too high > -- > > Key: AXIS2C-774 > URL: https://issues.apache.org/jira/browse/AXIS2C-774 > Project: Axis2-C > Issue Type: Bug > Components: samples > Environment: Ubuntu 7.10 (Gutsy Gibbon) >Reporter: Senaka Fernando >Assignee: Sanjaya Ratnaweera > Attachments: diff.txt > > > The echo_non_blocking.c sample's timeout value is too high. Please refer > proposed patch (diff.txt) -- 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-854) Error in SOAP Action Based Dispatching
[ https://issues.apache.org/jira/browse/AXIS2C-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-854. Resolution: Fixed Fix Version/s: Current (Nightly) Fixed Issue > Error in SOAP Action Based Dispatching > -- > > Key: AXIS2C-854 > URL: https://issues.apache.org/jira/browse/AXIS2C-854 > Project: Axis2-C > Issue Type: Bug > Components: core/addressing, core/context, core/deployment, > core/description, core/engine, core/phaseresolver >Affects Versions: 1.2.0 >Reporter: Senaka Fernando >Priority: Critical > Fix For: Current (Nightly) > > Attachments: diff.txt, diff2.txt > > > IN SOAP Action Based Dispatching, the Axis2/C engine is not capable of > identifying operations corresponding to SOAP Actions that do not contain a > URL with the operation name as a part of it. And, thus, violates the > specification of WS-I where the SOAP action can be any valid uri. > The proposed fix in diff.txt enables the user to specify such uri's as an > actionMapping element in the services.xml. This satisfies the usage of the > particular element as in [1]. > However, due to our implementation, the user can also specify such uri's as a > wsamapping parameter. And, that parameter is available as a > operation-to-action-mapping even when WS-Addressing is disabled and thus > violating the use of the wsamapping parameter as in [2]. > To overcome this issue, I have attached a second patch that allows the user > only to use the actionMapping element if WS-Addressing is disabled, so that > the SOAP Action Based Dispatcher can identify the particular operation. When > WS-Addressing is enabled, the wsamapping parameter and the actionMapping > element are both available for operation name resolution. > But for services that do not have WS-Addressing enabled in the service.xml > but where WS-Addressing is engaged globally, the second patch (diff2.txt), > has an awkward approach of setting action-mappings specified in wsamapping > parameters when the phase resolver globally engages modules to services. This > is due to our implementation having global module attachment after populating > all the services. > A better approach would have been to initially identify globally enabled > modules and attach them to each service during the population stage. Correct > me if I'm wrong. However, this requires a great deal of re-working and I have > not attempted that. > [1] http://wso2.org/library/2060 > [2] http://wso2.org/library/2605 -- 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: AW: AW: [Axis2C] how to return a MsgBox
Hi all, I believe you are requesting support for session on Axis2/C? So that you can have a conversation between Client and Server. Am I missing something here? AFAIK, Bill spoke on implementing Session with CURL. Or else is this possible through Savan/C (WS-Eventing)? Regards, Senaka > Hello Josef, > > i've read your first post, opened a reply - starting to > write my thoughts down - deleted it, cause im not an expert ;-) > > first, i think you have to write your server side callback method > outside the service, cause the service is only active when triggerd. > you can use axis2 api to create payload - clear. > > second, if i am right, not alle mep's from wsdl are supported. > i think you want to have "Solicit-response"/"out-in". > > i do not know corba very well, but i think your former corba server > could send the message to the client, cause the client is registerd > and will be found over orb/naming service !? the client seems to be > permanetly connected / has a listening port !? > > > possible solutions i can imagine for axis2 : > > 1. the client has to ask from time to time if something has happend > on serverside. if nothing has happend on serverside, server didn't > send back anythink or just a message like "no thanks, ask again". > otherwise the server replys with your yes/no question, client has to > answer. > but i think this is not what you want, if you talk about a > server side callback. > > 2. when starting your client, you call a "registerWithServer" method, > to let the server know the clients endpoint, using the servers context, > maybe at application level ? > write a service (not an axis service) that has a callback. when your > conditions are met, query the context and send the question. > now you have the problem, that the client is not listening - you have > to run a axis service on clientside :-( > > 3. client sends an async message to you server, server saves all > informations in context to answer and quits without reply. > i do no know what will happen ;-) maybe you have to increase client-side > timeout ? > write non axis service and your callback, when conditions are met, query > the context and create payload, then answer the initial async question. > > > cause i do not know if it is important to answer the question yes/no > immediately, when conditions are met - maybee this is also possible : > > 4. write a non axis service, when condition is met, write a flag to the > context. when client tries to communicate (you know the user is active), > query the context for the flag, send an special-fault as > answer. axis-client has to interpret this fault as yes/no question, > send the answer and service can do its work, reseting the flag in > context. after this, the user as to resend the initial message again. > > > mh, i don't really have an answer for you, just some thoughts and to let > you know that you are not alone with webservice paradigm and its > problems ;-) > > mfg derMark > > > > > > > > > > > > Stadelmann Josef schrieb: >> Hi Dinesh >> >> What relates to Axis2C and what not, how can a novice like I >> know that in FULL. i.e. possible Callbacks to caling clients >> without posting the service thread, but making it wait for the >> answer to occure. i.e. Agent paradigm. >> >> I am just seeking for an elegant method to invoke from within >> an Axis2/C server/service something like a callback to the client >> which askes Windows for a Windows MSGBOX with YES NO Buttons and >> a msg and a title. >> >> When the user then clicks a button, the answer is transfered >> to the waiting server/service and the service will evaluate >> the asnwer and can then continue. >> >> >> I am seeking an elegant way, one of you migth know, such as how >> to call back or agree on a clall back routin in the originating >> Axis2/C client >> >> If nobody knows that at your side of the pond, well, then I have >> to do it the hard way by miyelf. >> >> I generate a client side stub which is invoked by a server/service >> which sends to any server/service a message >> a title, a cpation, and some buttons or at least ID's to it. >> >> The receiving service, in this case on a windows system, will then >> invoke a Windows Operating System call and ask for a MsgBox. >> >> Once the button is clicked the resulting button value >> is then returedn as an integer to the client, which is in this >> case the invoked web service. >> >> I did so in the past using a corba server on a windows system >> >> Now all what changes is CORBA to WebServices >> >> And the paradigm is CLIENT -> AGENT -> question to MSG-BOX-SERVER >> and back. >> >> where Client is a web service client on a PC >> >> the Agent is the axis2/c webservice server which needs to ask back >> >> the Server is service hosted on the same PC as the Client resides. >> >> The bas thing is that
[jira] Commented: (AXIS2C-774) echo_non_blocking.c sample's timeout value is too high
[ https://issues.apache.org/jira/browse/AXIS2C-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563605#action_12563605 ] Senaka Fernando commented on AXIS2C-774: Hi Dinesh, No. It can't be our code. Because, we use the same function in the svc_client, but won't get an error. May be we are missing something in our build system in that case. Regards, Senaka > echo_non_blocking.c sample's timeout value is too high > -- > > Key: AXIS2C-774 > URL: https://issues.apache.org/jira/browse/AXIS2C-774 > Project: Axis2-C > Issue Type: Bug > Components: samples > Environment: Ubuntu 7.10 (Gutsy Gibbon) >Reporter: Senaka Fernando >Assignee: Sanjaya Ratnaweera > Attachments: diff.txt > > > The echo_non_blocking.c sample's timeout value is too high. Please refer > proposed patch (diff.txt) -- 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-774) echo_non_blocking.c sample's timeout value is too high
[ https://issues.apache.org/jira/browse/AXIS2C-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Premalal reopened AXIS2C-774: Hi, I'm getting this warning for following compiler versions. gcc-4.2 (GCC) 4.2.3 20080114 (prerelease) (Debian 4.2.2-7) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc (GCC) 4.1.3 20080114 (prerelease) (Debian 4.1.2-19) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc (GCC) 4.0.4 20060904 (prerelease) (Debian 4.0.3-7) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cc1: warnings being treated as errors echo_non_blocking.c: In function 'main': echo_non_blocking.c:128: warning: implicit declaration of function 'usleep' make: *** [echo_non_blocking.o] Error 1 I think , It is not because something wrong in compiler but in our code. > echo_non_blocking.c sample's timeout value is too high > -- > > Key: AXIS2C-774 > URL: https://issues.apache.org/jira/browse/AXIS2C-774 > Project: Axis2-C > Issue Type: Bug > Components: samples > Environment: Ubuntu 7.10 (Gutsy Gibbon) >Reporter: Senaka Fernando >Assignee: Sanjaya Ratnaweera > Attachments: diff.txt > > > The echo_non_blocking.c sample's timeout value is too high. Please refer > proposed patch (diff.txt) -- 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-866) REOPEN - /util/src/base64.c incorrect calculation of length in 'axutil_base64_decode_len'
[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563594#action_12563594
]
Dinesh Premalal commented on AXIS2C-866:
Devs, Can we get this done for 1.2.1 release Or does it take some more time ?
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: 1.2.0
>Reporter: Frank Huebbers
>Priority: Critical
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-845) samples configure command should be corrected.
[
https://issues.apache.org/jira/browse/AXIS2C-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563591#action_12563591
]
Senaka Fernando commented on AXIS2C-845:
Fixed on head.
Regards,
Senaka
> 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
>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] Updated: (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 updated AXIS2C-935: --- Attachment: (was: diff_rest.txt) > 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] Updated: (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 updated AXIS2C-935: --- Attachment: diff_rest.txt > 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]
Fwd: svn commit: r611719 [2/7] - in /webservices/axis2/trunk/c/xdocs: ./ docs/ docs/hello/client/ docs/hello/service/ docs/mod_log/
Hi Damitha,
I think , this commit has messed the generated site for the release
1.2.1 .
-- Forwarded message --
From: <[EMAIL PROTECTED]>
Date: Jan 14, 2008 11:30 AM
Subject: svn commit: r611719 [2/7] - in /webservices/axis2/trunk/c/xdocs: ./
docs/ docs/hello/client/ docs/hello/service/ docs/mod_log/
To: [EMAIL PROTECTED]
Modified: webservices/axis2/trunk/c/xdocs/docs/axis2c_manual.html
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/c/xdocs/docs/axis2c_manual.html?rev=611719&r1=611718&r2=611719&view=diff
==
--- webservices/axis2/trunk/c/xdocs/docs/axis2c_manual.html (original)
+++ webservices/axis2/trunk/c/xdocs/docs/axis2c_manual.html Sun Jan 13
22:00:36 2008
@@ -1,34 +1,19 @@
-
-
- Manual
-
-
-
-
-Preamble
-
-This document is intended to be a reference
-manual for http://ws.apache.org/axis2/c";>Apache Axis2/C. This
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>Apache
Axis2/C - Manual
+ @import url("../style/maven-base.css");
+
+ @import
url("../style/maven-classic.css");http://www.apache.org/"; id="organizationLogo">http://www.apache.org/images/asf-logo.gif";>http://ws.apache.org/axis2/c"; id="projectLogo">http://ws.apache.org/axis2/images/axis.jpg";>
+ Last published: 09 January 2008
+ | Doc for 1.2.0Apache Axis2/CApache Axis2/C Homehttp://nethu.org/
[jira] Commented: (AXIS2C-939) IIS Module does not set dll path and LoadLibrary call does not specify libraries current dir as start of search path
[
https://issues.apache.org/jira/browse/AXIS2C-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563487#action_12563487
]
Supun Kamburugamuva commented on AXIS2C-939:
Hi Dave,
I don't know the reason, but I couldn't apply your patch (there is an error
when I try to apply the patch). Anyway I have extracted the code manually and
now I'm trying to test it. Hope to apply the patch as soon as possible. Thanks
for finding this bug and trying to fix it.
Supun..
> IIS Module does not set dll path and LoadLibrary call does not specify
> libraries current dir as start of search path
>
>
> Key: AXIS2C-939
> URL: https://issues.apache.org/jira/browse/AXIS2C-939
> Project: Axis2-C
> Issue Type: Bug
> Components: transport/http
>Affects Versions: Current (Nightly)
> Environment: Windows XP, IIS 5.1
>Reporter: Dave Meier
> Attachments: axis2_isapi_plugin_c_diff.txt, axutils_windows_c_diff.txt
>
>
> I have a services dll that depends on other dlls. When I use
> axis2_http_server.exe it works fine, but under the IIS module, my service dll
> fails to load with a "Failed in creating DLL" message.
> I modified the code and was able to get it to work and can provide a diff
> once I learn how to do that. The change involved setting the dll path in the
> IIS module code and modifying the LoadLibrary call that Axis2C uses to load
> the service dll. The second change involves telling LoadLibrary to search
> the same directory where the dll is located first when looking for other dlls
> that the service dll depends upon. This change avoids a problem where an
> incorrect dll is picked up from somewhere else in the search path (aka "dll
> hell").
> --
> Change 1 - file "axis2_isapi_plugin.c", method
> "HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)"
> --
> DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
> {
> DWORD rc = HSE_STATUS_ERROR;
> lpECB->dwHttpStatusCode = HTTP_INTERNAL_SERVER_ERROR;
> if (axis2_worker)
> {
> // windows cannot find the correct dlls unless the dir is set
> // but we want to reset to previous dir after the load
> char szOriginalPath[_MAX_PATH + 1];
> char szPath[_MAX_PATH + 1];
> DWORD dwBufferSize = 0;
> ZeroMemory(szOriginalPath, sizeof szOriginalPath);
> dwBufferSize = sizeof szOriginalPath;
> #if _WIN32_WINNT >= 0x0502 // we stop supporting old WIN OSs
> GetDllDirectory( dwBufferSize, szOriginalPath );
> #else
> GetCurrentDirectory( dwBufferSize, szOriginalPath );
> #endif // _WIN32_WINNT >= 0x050
> ZeroMemory(szPath, sizeof szPath);
> dwBufferSize = sizeof szPath;
> lpECB->GetServerVariable(lpECB->ConnID, "APPL_PHYSICAL_PATH", szPath,
> &dwBufferSize);
> if ( strlen( szPath ) > 0 )
> {
> // windows cannot find the correct dlls unless the path is set
> #if _WIN32_WINNT >= 0x0502 // we stop supporting old WIN OSs
> SetDllDirectory( szPath );
> #else
> SetCurrentDirectory( szPath );
> #endif // _WIN32_WINNT >= 0x050
> }
> AXIS2_IIS_WORKER_PROCESS_REQUEST(axis2_worker, axutil_env, lpECB);
> // windows cannot find the correct dlls unless the dir is set
> // but we want to reset to previous dir after the load
> #if _WIN32_WINNT >= 0x0502 // we stop supporting old WIN OSs
> SetDllDirectory( szOriginalPath );
> #else
> SetCurrentDirectory( szOriginalPath );
> #endif // _WIN32_WINNT >= 0x050
> }
> else
> return HSE_STATUS_ERROR;
> return HSE_STATUS_SUCCESS;
> }
> --
> Change 2 - file "axutil_windows.c", method "callLoadLib(char *lib)":
> --
> return LoadLibraryEx(lib, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); // was
> "return LoadLibrary(lib);"
--
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: [Axis2]tcpmon binary in source distribution.
Dinesh Premalal wrote: Hi Sanjaya, After I package source distribution for 1.2.1 release , I can see tcpmon binary file placed under tools/tcpmon/src directory. Could apply a fix for that please ? Fixed. Thanks ~sanjaya thanks, Dinesh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]tcpmon binary in source distribution.
Hi Sanjaya, After I package source distribution for 1.2.1 release , I can see tcpmon binary file placed under tools/tcpmon/src directory. Could apply a fix for that please ? thanks, Dinesh. -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis2/C 1.2.1 release feature list
Hi Devs, Here [1] is the Axis2/C 1.2.1 release feature list so far. Ill update it as we fixing more jiras. If you see that I have missed any thing please feel free to update. thanks, Dinesh 1.http://wiki.apache.org/ws/FrontPage/Axis2C/releases/1%2e2%2e1 -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (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:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-859: -- Attachment: diff.txt Now guththila parses escape charactor.Please go through the patch file and apply this since this may reduce the performance of Guththila parser. > 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]
Re: [jira] Created: (AXIS2C-932) IIS module fails with service that has the name "services" in it
If u r using linux, just use svn diff >*patch_file-name*.diff Otherwise (windows) use Tortoise as Milinda mentioned. Regards, Kasun
Re: Supporting PUT on Axis2/C
Hi, I spoke to Keith, who worked on REST support on Axis2/Java, and according to him, you can basically upload files using PUT. In this kind of a situation the the operation would require having one parameter which is a FILE pointer. We are looking forward to implement that on Axis2/C, which would justify the use of a PUT method in RESTful Services' scenarios. Well on the contrary we could have a servlet like scenario too. But, the intentions were to implement REST. Regards, Senaka Hi, See my comments below > > > if there is a need to support PUT as part of REST my guess is we need > > to discuss a bit more of where exactly we need PUT to be. The > > semantics of PUT is to 'store' something in the server and IMHO our > > current service model does not have such a semantic [either in REST or > > SOAP]. The semantic we have right now is a file as an input to a > > service (if there is file argument somewhere) and that IMHO should be > > sent in some format in a POST (may be multipart/form-data ?) > > > > Well can we not leave the semntics of "store" to the service > implementer? As the engine, what we are interested in is, if it is a PUT > request, locate the operation that maps to it and pass on the payload. > Then as far as the engine is concerned we are done. The semantics on > what to do in within the operation that maps to a PUT is up to the user. > IMHO, if we try and deal with the REST PUT semantics at the engine > level, we are making things overly complicated. I see the point. What I am trying to get at is to see whether there is a clear separation where we would use PUT against a POST during a REST call. in other words why would I call a service with PUT instead of POST ? if the semantics of the service is up to the implementer then it really does not matter whether the header says PUT or POST - all that matters would be the information that helps to map to the service/operation [ Which I believe is the URL ] But I have to agree that the engine enforcing REST semantics is an overly complicated solution. If this is something like providing a servlet like solution [ it was the best analogy I could think of. Basically you get doGet,doPost,doPut and doDelete methods that can be overridden at will] then +1 to go ahead with it. -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
