Re: [Axis2][VOTE]Bill Mitchell as a committer

[Milinda Pathirage]

Here's my +1 for Bill.

Milinda

On Jan 8, 2008 12:37 PM, Manjula Peiris <[EMAIL PROTECTED]> wrote:

> +1
>
> -Manjula.
>
> On Tue, 2008-01-08 at 11:10 +0530, Sanjaya Ratnaweera wrote:
> > +1
> >
> > ~sanjaya
> >
> > Dushshantha Chandradasa wrote:
> > > +1
> > >
> > > Dushshantha
> > >
> > > On Jan 8, 2008 10:59 AM, Nandika Jayawardana <[EMAIL PROTECTED]>
> > > wrote:
> > > +1
> > >
> > > -- Nandika
> > >
> > >
> > > On Jan 8, 2008 10:57 AM, Dimuthu Gamage <[EMAIL PROTECTED]>
> > > wrote:
> > > Bill gave good suggestions to improve the WSDL2C as
> > > well.
> > >
> > > Here is my +1 to give him the commitership.
> > >
> > > Thanks,
> > > Dimuthu
> > >
> > >
> > > On Jan 8, 2008 10:47 AM, Supun Kamburugamuva
> > > <[EMAIL PROTECTED]> wrote:
> > > > On Jan 8, 2008 10:28 AM, Dinesh Premalal
> > > <[EMAIL PROTECTED]> wrote:
> > > > > Hi Devs,
> > > > >
> > > > > I would like to propose Bill Mitchell as an
> > > Axis2/C
> > > > > committer. Bill has reported many issues and
> > > provided many
> > > > > patches. He has contributed towards the
> > > Axis2/C core, libcurl
> > > > > based HTTP transport layer and code
> > > generation tool. Here is some
> > > > > of the issues that Bill has reported and
> > > provided patches [1]. I'm
> > > > > sure he will continue his contribution
> > > towards the Axis2/C.
> > > > >
> > > > > Here is my +1 for Bill !
> > > > >
> > > > There is a great contribution to Guththila parser
> > > from Bill.
> > > >
> > > > Here is my +1.
> > > >
> > > > Thanks,
> > > > Supun..
> > > >
> > > >
> > > >
> > >
> -
> > > > 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]
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://nandikajayawardana.blogspot.com/
> > > WSO2 Inc: http://www.wso2.com
> > >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
http://think2ed.blogspot.com "thinksquared"
http://wsaxc.blogspot.com "Web Services With Axis2/C"

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Manjula Peiris]

+1

-Manjula.

On Tue, 2008-01-08 at 11:10 +0530, Sanjaya Ratnaweera wrote:
> +1
> 
> ~sanjaya
> 
> Dushshantha Chandradasa wrote: 
> > +1
> > 
> > Dushshantha
> > 
> > On Jan 8, 2008 10:59 AM, Nandika Jayawardana <[EMAIL PROTECTED]>
> > wrote:
> > +1
> >  
> > -- Nandika
> > 
> > 
> > On Jan 8, 2008 10:57 AM, Dimuthu Gamage <[EMAIL PROTECTED]>
> > wrote:
> > Bill gave good suggestions to improve the WSDL2C as
> > well.
> > 
> > Here is my +1 to give him the commitership. 
> > 
> > Thanks,
> > Dimuthu
> > 
> > 
> > On Jan 8, 2008 10:47 AM, Supun Kamburugamuva
> > <[EMAIL PROTECTED]> wrote:
> > > On Jan 8, 2008 10:28 AM, Dinesh Premalal
> > <[EMAIL PROTECTED]> wrote:
> > > > Hi Devs,
> > > >
> > > > I would like to propose Bill Mitchell as an
> > Axis2/C
> > > > committer. Bill has reported many issues and
> > provided many
> > > > patches. He has contributed towards the
> > Axis2/C core, libcurl 
> > > > based HTTP transport layer and code
> > generation tool. Here is some
> > > > of the issues that Bill has reported and
> > provided patches [1]. I'm
> > > > sure he will continue his contribution
> > towards the Axis2/C. 
> > > >
> > > > Here is my +1 for Bill !
> > > >
> > > There is a great contribution to Guththila parser
> > from Bill.
> > >
> > > Here is my +1.
> > >
> > > Thanks,
> > > Supun..
> > >
> > > 
> > >
> > 
> > -
> > > 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]
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > http://nandikajayawardana.blogspot.com/
> > WSO2 Inc: http://www.wso2.com 
> > 
> 


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

[jira] Updated: (AXIS2C-892) tool to generate md5 checksums of files using Axis2/C md5 implementation

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-892:
---

Attachment: md5.tar.gz

> tool to generate md5 checksums of files using Axis2/C md5 implementation
> 
>
> Key: AXIS2C-892
> URL: https://issues.apache.org/jira/browse/AXIS2C-892
> Project: Axis2-C
>  Issue Type: New Feature
>Affects Versions: Current (Nightly)
>Reporter: Senaka Fernando
> Attachments: md5.tar.gz
>
>
> I have developed a tool that generates md5 checksums of files using Axis2/C 
> md5 implementation. Refer md5.tar.gz for proposed tool. This confirms to 
> RFC1321 and is compatible with any other md5 implementation.
> 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] Created: (AXIS2C-892) tool to generate md5 checksums of files using Axis2/C md5 implementation

[Senaka Fernando (JIRA)]

tool to generate md5 checksums of files using Axis2/C md5 implementation


 Key: AXIS2C-892
 URL: https://issues.apache.org/jira/browse/AXIS2C-892
 Project: Axis2-C
  Issue Type: New Feature
Affects Versions: Current (Nightly)
Reporter: Senaka Fernando


I have developed a tool that generates md5 checksums of files using Axis2/C md5 
implementation. Refer md5.tar.gz for proposed tool. This confirms to RFC1321 
and is compatible with any other md5 implementation.

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: [VOTE]Bill Mitchell as a Committer

[Dinesh Premalal]

Hi,

   Please ignore this mail. We already started vote thread.

thanks,
Dinesh

On Jan 8, 2008 9:57 AM, Dinesh Premalal <[EMAIL PROTECTED]> wrote:

> Hi Devs,
>
>I would like to propose Bill Mitchell as an Axis2/C
>committer. Bill has reported many issues and provided many
>patches. He has contributed towards the Axis2/C core, libcurl
>based HTTP tranport layer and code generation tool. Here is some
>of the issues that Bill has reported and provided patches [1]. I'm
>sure he will continue his contribution towards the Axis2/C in
>future as well.
>
>Here is my +1 for Bill !
>
>
> thanks,
> Dineshs
>
> 1
> .http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=wtmitchell3
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Dinesh Premalal
http://xydinesh.wordpress.com

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Sanjaya Ratnaweera]

+1

   ~sanjaya

Dushshantha Chandradasa wrote:

+1

Dushshantha

On Jan 8, 2008 10:59 AM, Nandika Jayawardana <[EMAIL PROTECTED] 
> wrote:


+1
 
-- Nandika


On Jan 8, 2008 10:57 AM, Dimuthu Gamage <[EMAIL PROTECTED]
> wrote:

Bill gave good suggestions to improve the WSDL2C as well.

Here is my +1 to give him the commitership.

Thanks,
Dimuthu


On Jan 8, 2008 10:47 AM, Supun Kamburugamuva
<[EMAIL PROTECTED] > wrote:
> On Jan 8, 2008 10:28 AM, Dinesh Premalal <
[EMAIL PROTECTED] > wrote:
> > Hi Devs,
> >
> > I would like to propose Bill Mitchell as an Axis2/C
> > committer. Bill has reported many issues and provided many
> > patches. He has contributed towards the Axis2/C core,
libcurl
> > based HTTP transport layer and code generation tool.
Here is some
> > of the issues that Bill has reported and provided
patches [1]. I'm
> > sure he will continue his contribution towards the
Axis2/C.
> >
> > Here is my +1 for Bill !
> >
> There is a great contribution to Guththila parser from Bill.
>
> Here is my +1.
>
> Thanks,
> Supun..
>
>
>
-
> 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]





-- 
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com 

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Dushshantha Chandradasa]

+1

Dushshantha

On Jan 8, 2008 10:59 AM, Nandika Jayawardana <[EMAIL PROTECTED]> wrote:

> +1
>
> -- Nandika
>
> On Jan 8, 2008 10:57 AM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
>
> > Bill gave good suggestions to improve the WSDL2C as well.
> >
> > Here is my +1 to give him the commitership.
> >
> > Thanks,
> > Dimuthu
> >
> >
> > On Jan 8, 2008 10:47 AM, Supun Kamburugamuva <[EMAIL PROTECTED]> wrote:
> > > On Jan 8, 2008 10:28 AM, Dinesh Premalal < [EMAIL PROTECTED]> wrote:
> > > > Hi Devs,
> > > >
> > > > I would like to propose Bill Mitchell as an Axis2/C
> > > > committer. Bill has reported many issues and provided many
> > > > patches. He has contributed towards the Axis2/C core, libcurl
> > > > based HTTP transport layer and code generation tool. Here is
> > some
> > > > of the issues that Bill has reported and provided patches [1].
> > I'm
> > > > sure he will continue his contribution towards the Axis2/C.
> > > >
> > > > Here is my +1 for Bill !
> > > >
> > > There is a great contribution to Guththila parser from Bill.
> > >
> > > Here is my +1.
> > >
> > > Thanks,
> > > Supun..
> > >
> > >
> > > -
> > > 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]
> >
> >
>
>
> --
> http://nandikajayawardana.blogspot.com/
> WSO2 Inc: http://www.wso2.com

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Nandika Jayawardana]

+1

-- Nandika

On Jan 8, 2008 10:57 AM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:

> Bill gave good suggestions to improve the WSDL2C as well.
>
> Here is my +1 to give him the commitership.
>
> Thanks,
> Dimuthu
>
>
> On Jan 8, 2008 10:47 AM, Supun Kamburugamuva <[EMAIL PROTECTED]> wrote:
> > On Jan 8, 2008 10:28 AM, Dinesh Premalal <[EMAIL PROTECTED]> wrote:
> > > Hi Devs,
> > >
> > > I would like to propose Bill Mitchell as an Axis2/C
> > > committer. Bill has reported many issues and provided many
> > > patches. He has contributed towards the Axis2/C core, libcurl
> > > based HTTP transport layer and code generation tool. Here is some
> > > of the issues that Bill has reported and provided patches [1]. I'm
> > > sure he will continue his contribution towards the Axis2/C.
> > >
> > > Here is my +1 for Bill !
> > >
> > There is a great contribution to Guththila parser from Bill.
> >
> > Here is my +1.
> >
> > Thanks,
> > Supun..
> >
> >
> > -
> > 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]
>
>


-- 
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Dimuthu Gamage]

Bill gave good suggestions to improve the WSDL2C as well.

Here is my +1 to give him the commitership.

Thanks,
Dimuthu


On Jan 8, 2008 10:47 AM, Supun Kamburugamuva <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 10:28 AM, Dinesh Premalal <[EMAIL PROTECTED]> wrote:
> > Hi Devs,
> >
> > I would like to propose Bill Mitchell as an Axis2/C
> > committer. Bill has reported many issues and provided many
> > patches. He has contributed towards the Axis2/C core, libcurl
> > based HTTP transport layer and code generation tool. Here is some
> > of the issues that Bill has reported and provided patches [1]. I'm
> > sure he will continue his contribution towards the Axis2/C.
> >
> > Here is my +1 for Bill !
> >
> There is a great contribution to Guththila parser from Bill.
>
> Here is my +1.
>
> Thanks,
> Supun..
>
>
> -
> 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]

[VOTE]Bill Mitchell as a Committer

[Dinesh Premalal]

Hi Devs,

I would like to propose Bill Mitchell as an Axis2/C
committer. Bill has reported many issues and provided many
patches. He has contributed towards the Axis2/C core, libcurl
based HTTP tranport layer and code generation tool. Here is some
of the issues that Bill has reported and provided patches [1]. I'm
sure he will continue his contribution towards the Axis2/C in
future as well.  

Here is my +1 for Bill !


thanks,
Dineshs

1.http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=wtmitchell3

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

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Supun Kamburugamuva]

On Jan 8, 2008 10:28 AM, Dinesh Premalal <[EMAIL PROTECTED]> wrote:
> Hi Devs,
>
> I would like to propose Bill Mitchell as an Axis2/C
> committer. Bill has reported many issues and provided many
> patches. He has contributed towards the Axis2/C core, libcurl
> based HTTP transport layer and code generation tool. Here is some
> of the issues that Bill has reported and provided patches [1]. I'm
> sure he will continue his contribution towards the Axis2/C.
>
> Here is my +1 for Bill !
>
There is a great contribution to Guththila parser from Bill.

Here is my +1.

Thanks,
Supun..

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

Re: [Axis2][VOTE]Bill Mitchell as a committer

[Samisa Abeysinghe]

Dinesh Premalal wrote:

Hi Devs,

I would like to propose Bill Mitchell as an Axis2/C
committer. Bill has reported many issues and provided many
patches. He has contributed towards the Axis2/C core, libcurl
based HTTP transport layer and code generation tool. Here is some
of the issues that Bill has reported and provided patches [1]. I'm
sure he will continue his contribution towards the Axis2/C.

Here is my +1 for Bill !

+1 form me too.

Thanks,
Samisa...


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

[Axis2][VOTE]Bill Mitchell as a committer

[Dinesh Premalal]

Hi Devs,

I would like to propose Bill Mitchell as an Axis2/C
committer. Bill has reported many issues and provided many
patches. He has contributed towards the Axis2/C core, libcurl
based HTTP transport layer and code generation tool. Here is some
of the issues that Bill has reported and provided patches [1]. I'm
sure he will continue his contribution towards the Axis2/C.

Here is my +1 for Bill !


thanks,
Dinesh

1.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=wtmitchell3

--
Dinesh Premalal
http://xydinesh.wordpress.com

[jira] Updated: (AXIS2C-891) Guththila doesn't parse xml elements with default namespace correctly

[Dimuthu Gamage (JIRA)]

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

Dimuthu Gamage updated AXIS2C-891:
--

Component/s: guththila

> Guththila doesn't parse xml elements with default namespace correctly
> -
>
> Key: AXIS2C-891
> URL: https://issues.apache.org/jira/browse/AXIS2C-891
> Project: Axis2-C
>  Issue Type: Bug
>  Components: guththila
> Environment: Linux  (Ubuntu 7.10)
>Reporter: Dimuthu Gamage
>
> For an example consider the following XML.
> http://ws.apache.org/axis2/xsd";>
>
> 
> Whenever I checked the qname of param0 and rows0, it returns the namespace 
> uri with NULL values. But they actually should belong to the 
> "http://ws.apache.org/axis2/xsd";.
> This leads to fail code-generation tests with Guththila.

-- 
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-863) Non-blocking code generation and forwarding a context code not supported

[Frank Huebbers (JIRA)]

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

Frank Huebbers commented on AXIS2C-863:
---

I am using libxml2.

Also note that I don't have the problem with the December 1st, 2007 snapshot.

> Non-blocking code generation and forwarding a context code not supported
> 
>
> Key: AXIS2C-863
> URL: https://issues.apache.org/jira/browse/AXIS2C-863
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: wsdl2c tool
>Affects Versions: Current (Nightly)
>Reporter: Frank Huebbers
> Attachments: case21.tar.gz
>
>
> I am using the non-blocking web service calls as they are generated by the 
> wsdl2c codegen tool. What I am missing in the codegeneration, however, is the 
> context that I would like to forward as well to the non-blocking call. 
> Specifically, what I am currently getting is the following (for the prototype 
> in the header):
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
>axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> What would be more useful, however, is the following in the prototype:
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>  void *data,
> axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
> axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> With the following addition in the implementation:
> /* Set data object */
> axis2_callback_set_data(callback, data);
> This would allow users to store a context with their non-blocking call, as is 
> customary in other languages, without having to manually change the stub 
> after it was generated.
> I generated the client stub with the following options on the wsdl2c tool: 
> -uri myWSDL.wsdl -d adb -u

-- 
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-891) Guththila doesn't parse xml elements with default namespace correctly

[Dimuthu Gamage (JIRA)]

Guththila doesn't parse xml elements with default namespace correctly
-

 Key: AXIS2C-891
 URL: https://issues.apache.org/jira/browse/AXIS2C-891
 Project: Axis2-C
  Issue Type: Bug
 Environment: Linux  (Ubuntu 7.10)
Reporter: Dimuthu Gamage


For an example consider the following XML.
http://ws.apache.org/axis2/xsd";>
   


Whenever I checked the qname of param0 and rows0, it returns the namespace uri 
with NULL values. But they actually should belong to the 
"http://ws.apache.org/axis2/xsd";.
This leads to fail code-generation tests with Guththila.

-- 
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-863) Non-blocking code generation and forwarding a context code not supported

[Dimuthu Gamage (JIRA)]

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

Dimuthu Gamage commented on AXIS2C-863:
---

BTW, What is the XML parser you are using, Libxml2 (which is the default one) 
or  Guththila?

> Non-blocking code generation and forwarding a context code not supported
> 
>
> Key: AXIS2C-863
> URL: https://issues.apache.org/jira/browse/AXIS2C-863
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: wsdl2c tool
>Affects Versions: Current (Nightly)
>Reporter: Frank Huebbers
> Attachments: case21.tar.gz
>
>
> I am using the non-blocking web service calls as they are generated by the 
> wsdl2c codegen tool. What I am missing in the codegeneration, however, is the 
> context that I would like to forward as well to the non-blocking call. 
> Specifically, what I am currently getting is the following (for the prototype 
> in the header):
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
>axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> What would be more useful, however, is the following in the prototype:
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>  void *data,
> axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
> axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> With the following addition in the implementation:
> /* Set data object */
> axis2_callback_set_data(callback, data);
> This would allow users to store a context with their non-blocking call, as is 
> customary in other languages, without having to manually change the stub 
> after it was generated.
> I generated the client stub with the following options on the wsdl2c tool: 
> -uri myWSDL.wsdl -d adb -u

-- 
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-863) Non-blocking code generation and forwarding a context code not supported

[Dimuthu Gamage (JIRA)]

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

Dimuthu Gamage commented on AXIS2C-863:
---

Hi, This should possibly be a memory corruption. This should not be caused by 
the changes I made because it is not much to do with the serialization stuff. 

I couldnt regenerate the problem in my machine, should try with valgrind to 
identify the corruption. 

> Non-blocking code generation and forwarding a context code not supported
> 
>
> Key: AXIS2C-863
> URL: https://issues.apache.org/jira/browse/AXIS2C-863
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: wsdl2c tool
>Affects Versions: Current (Nightly)
>Reporter: Frank Huebbers
> Attachments: case21.tar.gz
>
>
> I am using the non-blocking web service calls as they are generated by the 
> wsdl2c codegen tool. What I am missing in the codegeneration, however, is the 
> context that I would like to forward as well to the non-blocking call. 
> Specifically, what I am currently getting is the following (for the prototype 
> in the header):
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
>axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> What would be more useful, however, is the following in the prototype:
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>  void *data,
> axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
> axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> With the following addition in the implementation:
> /* Set data object */
> axis2_callback_set_data(callback, data);
> This would allow users to store a context with their non-blocking call, as is 
> customary in other languages, without having to manually change the stub 
> after it was generated.
> I generated the client stub with the following options on the wsdl2c tool: 
> -uri myWSDL.wsdl -d adb -u

-- 
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-889) misleading error message from generated stub deserialize routine when SOAP fault received

[Dimuthu Gamage (JIRA)]

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

Dimuthu Gamage resolved AXIS2C-889.
---

Resolution: Fixed

Fixed. Thanks for pointing out this.

> misleading error message from generated stub deserialize routine when SOAP 
> fault received
> -
>
> Key: AXIS2C-889
> URL: https://issues.apache.org/jira/browse/AXIS2C-889
> Project: Axis2-C
>  Issue Type: Bug
>  Components: code generation
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml, libcurl
>Reporter: Bill Mitchell
>Priority: Trivial
>
> As you can see from the following line from the axis2.trace file, the error 
> message when a SOAP fault message is received instead of the expected 
> response, is misleading in that it indicates the SOAP fault was expected, and 
> the response message was received:
> [Sat Jan 05 21:32:21 2008] [error] .\adb_browseResponse.c(160) Failed in 
> building adb object for browseResponse : Expected 
> Fault|http://schemas.xmlsoap.org/soap/envelope/|SOAP but returned 
> browseResponse|http://frameware.xcentrisity.com/services/
> In the generated code, for example in the following code, the first 
> qname_to_string actually computes the response received, and the 
> qname_to_string of the _browseResponse->qname indicates the expected value.  
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, 
>   "Failed in building adb object for 
> browseResponse : "
>   "Expected %s but returned %s", 
>   axutil_qname_to_string(qname, env),
>   axutil_qname_to_string(_browseResponse-> qname, 
> env));
> Inverting the last two lines to read as follows would correct this problem:
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, 
>   "Failed in building adb object for 
> browseResponse : "
>   "Expected %s but returned %s", 
>   axutil_qname_to_string(_browseResponse-> qname, 
> env),
>   axutil_qname_to_string(qname, env));
> These lines appear to be at line 759 in CADBBeanTemplateSource.xsl.
> 
> 

-- 
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-890) IssuedToken and SAMLToken assertion support for neethi

[Milinda Lakmal Pathirage (JIRA)]

IssuedToken and SAMLToken assertion support for neethi
--

 Key: AXIS2C-890
 URL: https://issues.apache.org/jira/browse/AXIS2C-890
 Project: Axis2-C
  Issue Type: Improvement
Affects Versions: Current (Nightly)
Reporter: Milinda Lakmal Pathirage
 Fix For: Current (Nightly)


Neethi implementation doesn't support IssuedToken assertion and SAMLToken 
assertion currently. But to implement SAML Token support for Rampart/C and 
automate some parts in Trust implementation we need those two assertions to be 
supported by neethi implementation.


-- 
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-889) misleading error message from generated stub deserialize routine when SOAP fault received

[Bill Mitchell (JIRA)]

misleading error message from generated stub deserialize routine when SOAP 
fault received
-

 Key: AXIS2C-889
 URL: https://issues.apache.org/jira/browse/AXIS2C-889
 Project: Axis2-C
  Issue Type: Bug
  Components: code generation
Affects Versions: Current (Nightly)
 Environment: Windows XP, Visual Studio 2005, libxml, libcurl
Reporter: Bill Mitchell
Priority: Trivial


As you can see from the following line from the axis2.trace file, the error 
message when a SOAP fault message is received instead of the expected response, 
is misleading in that it indicates the SOAP fault was expected, and the 
response message was received:

[Sat Jan 05 21:32:21 2008] [error] .\adb_browseResponse.c(160) Failed in 
building adb object for browseResponse : Expected 
Fault|http://schemas.xmlsoap.org/soap/envelope/|SOAP but returned 
browseResponse|http://frameware.xcentrisity.com/services/

In the generated code, for example in the following code, the first 
qname_to_string actually computes the response received, and the 
qname_to_string of the _browseResponse->qname indicates the expected value.  
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, 
  "Failed in building adb object for browseResponse 
: "
  "Expected %s but returned %s", 
  axutil_qname_to_string(qname, env),
  axutil_qname_to_string(_browseResponse-> qname, 
env));
Inverting the last two lines to read as follows would correct this problem:
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, 
  "Failed in building adb object for browseResponse 
: "
  "Expected %s but returned %s", 
  axutil_qname_to_string(_browseResponse-> qname, 
env),
  axutil_qname_to_string(qname, env));
These lines appear to be at line 759 in CADBBeanTemplateSource.xsl.






-- 
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-864) Use of 'const' for arguments in setter methods of generated types

[Frank Huebbers (JIRA)]

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

Frank Huebbers closed AXIS2C-864.
-


I tried this out with the January 7, 2008 snapshot and it works great for me 
now :)

Frank

> Use of 'const' for arguments in setter methods of generated types
> -
>
> Key: AXIS2C-864
> URL: https://issues.apache.org/jira/browse/AXIS2C-864
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: wsdl2c tool
>Affects Versions: Current (Nightly)
>Reporter: Frank Huebbers
>
> In setter methods of the various types generated by the wsdl2c tool, I would 
> like to see a const classifier on the inputs, especially in the case when the 
> input is of type axis2_char_t. 
> For example, for a LoginType I have a username which I can set. In the 
> current version of the tool, the following prototype is generated:
> axis2_status_t AXIS2_CALL
> adb_LoginType_set_username(
> adb_LoginType_t* _LoginType,
> const axutil_env_t *env,
> axis2_char_t*  arg_username);
> What would be better, however, is the following:
> axis2_status_t AXIS2_CALL
> adb_LoginType_set_username(
> adb_LoginType_t* _LoginType,
> const axutil_env_t *env,
> const axis2_char_t*  arg_username);
> I generated the client stub with the following options on the wsdl2c tool: 
> -uri myWSDL.wsdl -d adb -u
> Thanks for all the help and time in advance.
> Cheers,
> 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] Reopened: (AXIS2C-863) Non-blocking code generation and forwarding a context code not supported

[Frank Huebbers (JIRA)]

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

Frank Huebbers reopened AXIS2C-863:
---


I tried out the updated wsdl2c tool and the non-blocking stubs were generated 
properly and this seems to work well.

However, there seems to be a new problem that arose for me when I updated to 
the new tool (snapshot 1/7/2008). I'm not sure whether this is related to the 
changes that were made so, I'm reopening this issue first.

Basically, there seems to be a problem in the generated SOAP message when a 
using types from a common wsdl file in another wsdl file. In the following 
scenario, I have a parent.wsdl file with a login type which, in turn, has types 
from a common.wsdl file. The SOAP message that is sent when using the generated 
code is:

http://schemas.xmlsoap.org/soap/envelope/";>












 This, of course, generates a SOAP fault on the receiving side. To make this 
work, however, I would expect the message to be:

http://schemas.xmlsoap.org/soap/envelope/";>












Note the difference on the xmlns:n0="urn:common.MyCompany.com". I am expecting 
that some variable wasn't initialized properly or something of that nature.

I generated this code with the -uri parent.wsdl -d adb -u using the codegen 
tool from the January 7th, 2008 Snapshot.

Any help would be greatly appreciated.

Cheers,
Frank

> Non-blocking code generation and forwarding a context code not supported
> 
>
> Key: AXIS2C-863
> URL: https://issues.apache.org/jira/browse/AXIS2C-863
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: wsdl2c tool
>Affects Versions: Current (Nightly)
>Reporter: Frank Huebbers
> Attachments: case21.tar.gz
>
>
> I am using the non-blocking web service calls as they are generated by the 
> wsdl2c codegen tool. What I am missing in the codegeneration, however, is the 
> context that I would like to forward as well to the non-blocking call. 
> Specifically, what I am currently getting is the following (for the prototype 
> in the header):
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
>axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> What would be more useful, however, is the following in the prototype:
> void axis2_stub_start_op_MyService_getProperties( axis2_stub_t *stub, const 
> axutil_env_t *env,
>  adb_getProperties_t* 
> _getProperties,
>  void *data,
> axis2_status_t ( 
> AXIS2_CALL *on_complete ) (struct axis2_callback *, const axutil_env_t *) ,
> axis2_status_t ( 
> AXIS2_CALL *on_error ) (struct axis2_callback *, const axutil_env_t *, int ) )
> With the following addition in the implementation:
> /* Set data object */
> axis2_callback_set_data(callback, data);
> This would allow users to store a context with their non-blocking call, as is 
> customary in other languages, without having to manually change the stub 
> after it was generated.
> I generated the client stub with the following options on the wsdl2c tool: 
> -uri myWSDL.wsdl -d adb -u

-- 
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-888) Utility to support HTTP Digest Authentication

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-888:
---

Attachment: diff.txt

> Utility to support HTTP Digest Authentication
> -
>
> Key: AXIS2C-888
> URL: https://issues.apache.org/jira/browse/AXIS2C-888
> Project: Axis2-C
>  Issue Type: New Feature
>  Components: util
>Affects Versions: 1.2.0
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> I have developed a utility to be used with HTTP Digest Authentication, which 
> implements the calculations of H(A1), H(A2), request-digest and 
> response-digest based on rfc2617. Using this utility we can implement digest 
> authentication (for both HTTP and Proxy) in AXIS2/C. Refer diff.txt for patch.
> 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] Created: (AXIS2C-888) Utility to support HTTP Digest Authentication

[Senaka Fernando (JIRA)]

Utility to support HTTP Digest Authentication
-

 Key: AXIS2C-888
 URL: https://issues.apache.org/jira/browse/AXIS2C-888
 Project: Axis2-C
  Issue Type: New Feature
  Components: util
Affects Versions: 1.2.0
Reporter: Senaka Fernando
 Attachments: diff.txt

I have developed a utility to be used with HTTP Digest Authentication, which 
implements the calculations of H(A1), H(A2), request-digest and response-digest 
based on rfc2617. Using this utility we can implement digest authentication 
(for both HTTP and Proxy) in AXIS2/C. Refer diff.txt for patch.

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]

[Vote] [Axis2-C] Vote for Apache Axis2/C 1.2.0 Release - Take 5

[Damitha Kumarage]

Hi Devs,

I have re-packaged and uploaded the Apache Axis2/C 1.2.0 release 
artifacts at [1].

The key used to sign the release artifacts can be found at [2].

The only change  from the previous release artifacts  is removing the 
Werror flag from the
configure.ac, util/configure.ac and neethi/configure.ac of the source 
packages.


Please test, review and vote on these latest release artifacts for
Apache Axis2/C 1.2.0 release.

I have tested and reviewed them and here is my vote: +1

Thanks,
Damitha

[1]http://people.apache.org/~damitha/release/axis2/1.2.0/
[2]http://people.apache.org/~damitha/release/axis2/1.2.0/KEYS


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

[jira] Updated: (AXIS2C-887) Message-Digest Algorithm for Axis2/C

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-887:
---

Attachment: diff.txt

> Message-Digest Algorithm for Axis2/C
> 
>
> Key: AXIS2C-887
> URL: https://issues.apache.org/jira/browse/AXIS2C-887
> Project: Axis2-C
>  Issue Type: New Feature
>  Components: tests, util
>Affects Versions: 1.2.0
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> I have attached herewith an implementation of md5 for Axis2/C along with test 
> cases that confirm to rfc1321 (R. Rivest, 1992). Refer diff.txt for patch.
> 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-887) Message-Digest Algorithm for Axis2/C

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-887:
---

Attachment: (was: diff.txt)

> Message-Digest Algorithm for Axis2/C
> 
>
> Key: AXIS2C-887
> URL: https://issues.apache.org/jira/browse/AXIS2C-887
> Project: Axis2-C
>  Issue Type: New Feature
>  Components: tests, util
>Affects Versions: 1.2.0
>Reporter: Senaka Fernando
>
> I have attached herewith an implementation of md5 for Axis2/C along with test 
> cases that confirm to rfc1321 (R. Rivest, 1992). Refer diff.txt for patch.
> 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-887) Message-Digest Algorithm for Axis2/C

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-887:
---

Attachment: diff.txt

> Message-Digest Algorithm for Axis2/C
> 
>
> Key: AXIS2C-887
> URL: https://issues.apache.org/jira/browse/AXIS2C-887
> Project: Axis2-C
>  Issue Type: New Feature
>  Components: tests, util
>Affects Versions: 1.2.0
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> I have attached herewith an implementation of md5 for Axis2/C along with test 
> cases that confirm to rfc1321 (R. Rivest, 1992). Refer diff.txt for patch.
> 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] Created: (AXIS2C-887) Message-Digest Algorithm for Axis2/C

[Senaka Fernando (JIRA)]

Message-Digest Algorithm for Axis2/C


 Key: AXIS2C-887
 URL: https://issues.apache.org/jira/browse/AXIS2C-887
 Project: Axis2-C
  Issue Type: New Feature
  Components: tests, util
Affects Versions: 1.2.0
Reporter: Senaka Fernando
 Attachments: diff.txt

I have attached herewith an implementation of md5 for Axis2/C along with test 
cases that confirm to rfc1321 (R. Rivest, 1992). Refer diff.txt for patch.

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] Resolved: (AXIS2C-885) Error in Service/Client compilation commands in axis2_manual

[Damitha Kumarage (JIRA)]

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

Damitha Kumarage resolved AXIS2C-885.
-

Resolution: Fixed

patch applied

> Error in Service/Client compilation commands in axis2_manual
> 
>
> Key: AXIS2C-885
> URL: https://issues.apache.org/jira/browse/AXIS2C-885
> Project: Axis2-C
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.2.0
> Environment: Linux
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> Error in Service/Client compilation commands in axis2_manual. Include folder 
> name has to be changed and -ldl -Wl,--rpath -Wl,$AXIS2C_HOME/lib is required 
> to get client to run. Refer diff.txt for proposed patch.
> 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-884) Seg fault in libxml when svc client torn down in a multithreaded client

[Bill Mitchell (JIRA)]

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

Bill Mitchell commented on AXIS2C-884:
--

To handle the multithreaded case, clearly the libxml2 documentation means what 
it says and there must be one initialize and one cleanup for the entire 
application.  This means creating new entry points, say axis2_initialize() and 
axis2_cleanup, that the application client calls at the appropriate points.  
But demanding that all clients call these as appropriate means changing all the 
test cases, all the samples, all the documentation

So, my suggestion is:

(1) Add new entry points, axis2_initialize() and axis2_cleanup() that the 
client may call to manage the initialization and tear down itself.  This would 
be required for correct multi-thread operation with libxml.  

(2) Add internal entry points, axis2_implicit_initialize, and 
axis2_implicit_cleanup, that op_client.c could use to accomplish the 
axiom_xml_reader_init() and cleanup.  These routines would keep a use-count of 
active users, and, when there was no explicit initialize, would perform the 
underlying initialization only on the first use and the cleanup only when the 
last use was complete.  

Change (2) will fix the single-thread crash above by ensuring that no 
xmlCleanupParser is issued while any structures are still in use.  And libxml2 
seems to tolerate serial reuse as long as it is in a single thread.  Change (1) 
gives the multithreaded client the chance to take control of the initialization 
and termination.  

> Seg fault in libxml when svc client torn down in a multithreaded client
> ---
>
> Key: AXIS2C-884
> URL: https://issues.apache.org/jira/browse/AXIS2C-884
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/deployment
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 
> 2.6.30, libcurl
>Reporter: Bill Mitchell
> Attachments: axis2.trace, desc_builder_diff.txt
>
>
> In a multithreaded application, if the stub/svc client is freed in a thread 
> different from that used when the svc client was built, libxml crashes.  The 
> trace below shows the information available from a release build with debug 
> information embedded.  
> I have verified this is not an effect of combining debug and release C 
> runtimes, or different versions of the C runtime.  Rebuilding all the libxml 
> related dlls with the same runtime as is used for Axis and the client app 
> does not solve the problem.  
> Interestingly, rebuilding libxml with threads disabled does make the crash go 
> away.  But the default build of libxml commonly available has native threads 
> enabled, and building without thread support may make the library not thread 
> safe.  
> By adding debug trace statements in the axis2.trace file, I have verified 
> that the xml_reader being torn down when the crash happens is the one used to 
> read the axis2.xml file when the configuration was first read.  (axis2.trace 
> file attached.)
> Looking at the code in libxml, it appears that libxml decides to close the 
> reader using an internal close routine intended for closing compressed 
> channels through zlib.  Apparently the C runtime library returns a -1 EOF 
> status when closing a file opened for read.  The close routine, gzio.c in 
> zlib, treats this as an error, and when libxml attempts to report the error 
> and determines that it is in a different thread, things really go downhill 
> fast.  I have not isolated why the EnterCriticalSection call crashes in the 
> system, but it does.  
> One way to avoid the problem would be to guarantee that the stub/svc client 
> is freed in the same thread as created it.  In my multithreaded client 
> application, though, I work hard to share the stub across threads 
> deliberately to reduce the number of distinct service clients and the 
> associated demand on the server.  
> Windows call traceback at time of crash:
>   ntdll.dll!7c918fea()
>   [Frames below may be incorrect and/or missing, no symbols loaded for 
> ntdll.dll] 
>   msvcr80.dll!78134d09()  
>   ntdll.dll!7c910e91()
>   ntdll.dll!7c9106eb()
>   msvcr80.dll!78134d83()  
>   ntdll.dll!7c90104b()
> > libxml2.dll!xmlGetGlobalState()  Line 570   C
>   libxml2.dll!__xmlLastError()  Line 709 + 0x5 bytes  C
>   libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* 
> schannel=0x, void (void *, const char *, )* 
> channel=0x, void * data=0x, void * ctx=0x, void * 
> nod=0x, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR, 
> const char * file=0x, int line=0, const char * str1=0x00c5d4

[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client

[Bill Mitchell (JIRA)]

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

Bill Mitchell commented on AXIS2C-884:
--

To isolate what kind of fix might work for the multithreading case, for testing 
I commented out the xmlInitParser() and xmlCleanupParser() calls and moved 
these into the application threads.  If these calls are issued once at the 
start of the application and once at the end, all works well.  The same is not 
true when attempting to use libxml2 serially in multiple threads.  In 
particular, I tried creating and freeing the stub around each SOAP message, and 
performing an xmlInitParser and xmlCleanupParser around each use.  Even in the 
application where mutex's can ensure that the xmlCleanupParser() completes 
before an xmlInitParser() is issued, and the use_counts are maintained under 
mutex to avoid race conditions, the first time libxml2 is initialized in a 
second thread after being freed in the first thread, the crash in 
xmlGetGlobalState reappears.  See the traceback below, as well as relevant 
trace lines from my application trace.

ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for 
ntdll.dll] 
kernel32.dll!7c80e98b() 
>   msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int 
> nBlockUse=0, const char * szFileName=0x2220, int nLine=67225284)  Line 
> 268 + 0x15 bytesC++
msvcr80d.dll!malloc(unsigned int nSize=17792788)  Line 154 + 0x15 bytes 
C++
libxml2.dll!xmlGetGlobalState()  Line 570   C

[EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2
[EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2

> Seg fault in libxml when svc client torn down in a multithreaded client
> ---
>
> Key: AXIS2C-884
> URL: https://issues.apache.org/jira/browse/AXIS2C-884
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/deployment
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 
> 2.6.30, libcurl
>Reporter: Bill Mitchell
> Attachments: axis2.trace, desc_builder_diff.txt
>
>
> In a multithreaded application, if the stub/svc client is freed in a thread 
> different from that used when the svc client was built, libxml crashes.  The 
> trace below shows the information available from a release build with debug 
> information embedded.  
> I have verified this is not an effect of combining debug and release C 
> runtimes, or different versions of the C runtime.  Rebuilding all the libxml 
> related dlls with the same runtime as is used for Axis and the client app 
> does not solve the problem.  
> Interestingly, rebuilding libxml with threads disabled does make the crash go 
> away.  But the default build of libxml commonly available has native threads 
> enabled, and building without thread support may make the library not thread 
> safe.  
> By adding debug trace statements in the axis2.trace file, I have verified 
> that the xml_reader being torn down when the crash happens is the one used to 
> read the axis2.xml file when the configuration was first read.  (axis2.trace 
> file attached.)
> Looking at the code in libxml, it appears that libxml decides to close the 
> reader using an internal close routine intended for closing compressed 
> channels through zlib.  Apparently the C runtime library returns a -1 EOF 
> status when closing a file opened for read.  The close routine, gzio.c in 
> zlib, treats this as an error, and when libxml attempts to report the error 
> and determines that it is in a different thread, things really go downhill 
> fast.  I have not isolated why the EnterCriticalSection call crashes in the 
> system, but it does.  
> One way to avoid the problem would be to guarantee that the stub/svc client 
> is freed in the same thread as created it.  In m

[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client

[Bill Mitchell (JIRA)]

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

Bill Mitchell commented on AXIS2C-884:
--

I modified my client application to create and reuse service stubs separately 
within each thread.  Using just one thread to with multiple service stubs to 
different URLs, I saw a similar libxml2 crash when the stub / svc clients are 
freed.  See the traceback below:

 msvcr80d.dll!CheckBytes(unsigned char * pb=0xfeeefee8, unsigned char 
bCheck='í', unsigned int nSize=3)  Line 1654 + 0x7 bytes  C++
 msvcr80d.dll!_free_dbg_nolock(void * pUserData=0xfeeefeee, int 
nBlockUse=1)  Line 1257 + 0x17 bytesC++
 msvcr80d.dll!_free_dbg(void * pUserData=0xfeeefeee, int nBlockUse=1)  Line 
1220 + 0xd bytesC++
 msvcr80d.dll!free(void * pUserData=0xfeeefeee)  Line 1178 + 0xb bytes  
C++
 libxml2.dll!xmlCharEncCloseFunc(_xmlCharEncodingHandler * 
handler=0x036f0760)  Line 2115 + 0xc bytes   C
 libxml2.dll!xmlFreeParserInputBuffer(_xmlParserInputBuffer * 
in=0x036eace8)  Line 2204 + 0xc bytes C
 libxml2.dll!xmlFreeInputStream(_xmlParserInput * input=0x036fb020)  Line 
1269 + 0xb bytes  C
 libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x036ead98)  Line 1679 
+ 0x9 bytes C
 libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x036f4d98)  Line 
2196 + 0xc bytes   C
 axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * 
parser=0x036fbc60, const axutil_env * env=0x0183ce10)  Line 503 + 0x9 bytes  C
 axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader * 
parser=0x036fbc60, const axutil_env * env=0x0183ce10)  Line 35   C
 axiom.dll!axiom_stax_builder_free(axiom_stax_builder * 
om_builder=0x036fa788, const axutil_env * env=0x0183ce10)  Line 885 C
 axiom.dll!axiom_soap_builder_free(axiom_soap_builder * 
soap_builder=0x036fa930, const axutil_env * env=0x0183ce10)  Line 189   C
 axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope * 
soap_envelope=0x036fb748, const axutil_env * env=0x0183ce10)  Line 168C
 axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x036e8658, 
const axutil_env * env=0x0183ce10)  Line 374   C
 axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x03700950, const 
axutil_env * env=0x0183ce10)  Line 165  C
>axis2_engine.dll!axis2_op_client_free(axis2_op_client * 
> op_client=0x03700868, const axutil_env * env=0x0183ce10)  Line 615 C
 axis2_engine.dll!axis2_svc_client_free(axis2_svc_client * 
svc_client=0x01864028, const axutil_env * env=0x0183ce10)  Line 1287 C
 axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x0186c630, const 
axutil_env * env=0x0183ce10)  Line 129C

The 0xfeeefeee is a prime indication that, when the second svc client is freed, 
libxml2 is trying to access memory that it already.  

Looking at the op_client.c and libxml2_reader_wrapper.c, it appear that Axis2c 
issues an xmlInitParser and xmlCleanupParser call for each op_client, 
apparently expecting that libxml2 will be tolerant and keep a count of users.  
This does not match the libxml2 documentation, which is very insistent that it 
expects one init at the beginning of the application, and one cleanup when all 
access is done.  

For testing, I tried modifying libxml2_reader_wrapper.c to keep a use_count and 
perform the xmlInitParser only on the first call, and the xmlCleanupParser only 
when all users are done:

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_init( )
{
if (xml_init_count++ == 0)
{
xmlInitParser();
}
return AXIS2_SUCCESS;
}

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_cleanup()
{
if ((xml_init_count > 0) &&
(--xml_init_count == 0)) 
{
xmlCleanupParser();
}
return AXIS2_SUCCESS;
}

This change remedies this second crash in msvcr80d.dll CheckBytes.  But crashes 
of the first type, in libxml2 xmlGetGlobalState still happen as soon as 
activity occurs in multiple threads.  

> Seg fault in libxml when svc client torn down in a multithreaded client
> ---
>
> Key: AXIS2C-884
> URL: https://issues.apache.org/jira/browse/AXIS2C-884
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/deployment
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 
> 2.6.30, libcurl
>Reporter: Bill Mitchell
> Attachments: axis2.trace, desc_builder_diff.txt
>
>
> In a multithreaded application, if the stub/svc client is freed in a thread 
> different from that used when the svc client was built, libxml crashes.  The 
> trace below shows the information available from a release build with debug 
> information embedded.  
> 

[jira] Issue Comment Edited: (AXIS2C-724) potential access violation in dir_windows.c

[hyeyoung yooon (JIRA)]

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

seera edited comment on AXIS2C-724 at 1/7/08 4:47 AM:
---

I'm agree with Atsushi.

There's something wrong in scandir().
Actually, My program didn't work properly using this function.

Did you find the solution about that?

I found the solution.

vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, dsize);
==> vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, sizeof(struct 
dirent));

That will be ok.

  was (Author: seera):
I'm agree with Atsushi.

There's something wrong in scandir().
Actually, My program didn't work properly using this function.

Did you find the solution about that?
  
> potential access violation in dir_windows.c
> ---
>
> Key: AXIS2C-724
> URL: https://issues.apache.org/jira/browse/AXIS2C-724
> Project: Axis2-C
>  Issue Type: Bug
>  Components: platforms/windows
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>
> I think scandir() has a potential access violation in dir_windows.c.
> The following is an extraction of scandir().
> int AXIS2_CALL scandir(const char *_dirname, 
>   struct dirent **__namelist[], 
>   int(*selector)(const struct dirent *entry), 
>   int(*compare)(const struct dirent **__d1, const struct dirent **__d2))
> {
> DIR*dirp = NULL;
> struct dirent  **vector = NULL;
> struct dirent  *dp = NULL;
> intvector_size = 0;
> intnfiles = 0;
> if (!(dirp = opendir(_dirname)))
> {
> return -1;
> }
> while ((dp = readdir(dirp)))
> {
> dsize = (int)sizeof(struct dirent) + (int)((strlen(dp->d_name) + 1) * 
> sizeof(char));
> newdp = (struct dirent *) malloc(dsize);
> if (newdp == NULL)
> {
> while (nfiles-- > 0)
> {
> free(vector[nfiles]);
> }
> free(vector);
> return -1;
> }
> vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, dsize);
> }
> Using memcpy() like this.
>   vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, dsize);
> The "dsize" defined like this.
>   dsize = (int)sizeof(struct dirent) + (int)((strlen(dp->d_name) + 1) * 
> sizeof(char));
> The "dp"(copy src) has only size of "struct dirent". Less size than "dsize".
> When access over "dp", it has potential access violation.

-- 
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-724) potential access violation in dir_windows.c

[hyeyoung yooon (JIRA)]

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

hyeyoung yooon commented on AXIS2C-724:
---

I'm agree with Atsushi.

There's something wrong in scandir().
Actually, My program didn't work properly using this function.

Did you find the solution about that?

> potential access violation in dir_windows.c
> ---
>
> Key: AXIS2C-724
> URL: https://issues.apache.org/jira/browse/AXIS2C-724
> Project: Axis2-C
>  Issue Type: Bug
>  Components: platforms/windows
>Affects Versions: 1.1.0
> Environment: OS:WindowsXP
>Reporter: Atsushi Monna
>
> I think scandir() has a potential access violation in dir_windows.c.
> The following is an extraction of scandir().
> int AXIS2_CALL scandir(const char *_dirname, 
>   struct dirent **__namelist[], 
>   int(*selector)(const struct dirent *entry), 
>   int(*compare)(const struct dirent **__d1, const struct dirent **__d2))
> {
> DIR*dirp = NULL;
> struct dirent  **vector = NULL;
> struct dirent  *dp = NULL;
> intvector_size = 0;
> intnfiles = 0;
> if (!(dirp = opendir(_dirname)))
> {
> return -1;
> }
> while ((dp = readdir(dirp)))
> {
> dsize = (int)sizeof(struct dirent) + (int)((strlen(dp->d_name) + 1) * 
> sizeof(char));
> newdp = (struct dirent *) malloc(dsize);
> if (newdp == NULL)
> {
> while (nfiles-- > 0)
> {
> free(vector[nfiles]);
> }
> free(vector);
> return -1;
> }
> vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, dsize);
> }
> Using memcpy() like this.
>   vector[nfiles++] = (struct dirent *) memcpy(newdp, dp, dsize);
> The "dsize" defined like this.
>   dsize = (int)sizeof(struct dirent) + (int)((strlen(dp->d_name) + 1) * 
> sizeof(char));
> The "dp"(copy src) has only size of "struct dirent". Less size than "dsize".
> When access over "dp", it has potential access violation.

-- 
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-851) Frequently Asked Questions

[Malinda Kaushalye Kapuruge (JIRA)]

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

Malinda Kaushalye Kapuruge commented on AXIS2C-851:
---

Yes we can. Once the FAQ is completed.
BTW, We might need to order these question in a suitable manner. For example 
from the simple question to more complicated ones. And would be nice if we can 
add few platform specific Q&As as well.



> Frequently Asked Questions
> --
>
> Key: AXIS2C-851
> URL: https://issues.apache.org/jira/browse/AXIS2C-851
> Project: Axis2-C
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Spencer Davis
>
> Several users of our software tend to ask the same questions time to time. 
> Hence
> the same question is asked over the mailing list multiple times and answered 
> in the
> same way. Rather than answering the same questions over and over again, we can
> put up FAQ lists with Frequently Asked Questions (and their answers).

-- 
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-885) Error in Service/Client compilation commands in axis2_manual

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-885:
---

Attachment: (was: diff.txt)

> Error in Service/Client compilation commands in axis2_manual
> 
>
> Key: AXIS2C-885
> URL: https://issues.apache.org/jira/browse/AXIS2C-885
> Project: Axis2-C
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.2.0
> Environment: Linux
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> Error in Service/Client compilation commands in axis2_manual. Include folder 
> name has to be changed and -ldl -Wl,--rpath -Wl,$AXIS2C_HOME/lib is required 
> to get client to run. Refer diff.txt for proposed patch.
> 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-885) Error in Service/Client compilation commands in axis2_manual

[Senaka Fernando (JIRA)]

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

Senaka Fernando updated AXIS2C-885:
---

Attachment: diff.txt

> Error in Service/Client compilation commands in axis2_manual
> 
>
> Key: AXIS2C-885
> URL: https://issues.apache.org/jira/browse/AXIS2C-885
> Project: Axis2-C
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.2.0
> Environment: Linux
>Reporter: Senaka Fernando
> Attachments: diff.txt
>
>
> Error in Service/Client compilation commands in axis2_manual. Include folder 
> name has to be changed and -ldl -Wl,--rpath -Wl,$AXIS2C_HOME/lib is required 
> to get client to run. Refer diff.txt for proposed patch.
> 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]