Re: [C++] M2 RC1 status
1.8.5 On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Pete Robbins wrote: > 2.4.3 is what we have working on Win. I'm sure 2.5 would be fine but > it was > pre-req'ing vc7.x and a particular .Net framework level... a right pain! > > We will probably, no definitely, build our windows distros with vc7 as we > think Python requires it. But then.. the Ruby extension won't compile > with > anything but VC6!!! (but we hacked our code so that we tricked Ruby into > thinking we were on VC6... seems to work). > > So we are going with VC6, Python 2.4 and Ruby 1.8. > > Cheers, > Ok I'll use these levels. Which exact level of Ruby are you using? 1.8.1? 1.8.5? any other? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 RC1 status
Pete Robbins wrote: 2.4.3 is what we have working on Win. I'm sure 2.5 would be fine but it was pre-req'ing vc7.x and a particular .Net framework level... a right pain! We will probably, no definitely, build our windows distros with vc7 as we think Python requires it. But then.. the Ruby extension won't compile with anything but VC6!!! (but we hacked our code so that we tricked Ruby into thinking we were on VC6... seems to work). So we are going with VC6, Python 2.4 and Ruby 1.8. Cheers, Ok I'll use these levels. Which exact level of Ruby are you using? 1.8.1? 1.8.5? any other? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
2.4.3 is what we have working on Win. I'm sure 2.5 would be fine but it was pre-req'ing vc7.x and a particular .Net framework level... a right pain! We will probably, no definitely, build our windows distros with vc7 as we think Python requires it. But then.. the Ruby extension won't compile with anything but VC6!!! (but we hacked our code so that we tricked Ruby into thinking we were on VC6... seems to work). So we are going with VC6, Python 2.4 and Ruby 1.8. Cheers, On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Pete Robbins wrote: > That looks good. I think Andy was going to generate/zip/sign/publish the > packages for the distros. I tried Python 2.5 on Windows but had to go > down > to 2.4 so we'll stick there! > > Cheers, > > > On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> Pete Robbins wrote: >> > Sounds about right. I need to add Ruby and Python extensions into the >> > windows command line build. Hopefully this will be done today. >> > >> > Cheers, >> > >> > >> > On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi all, >> >> >> >> Just a quick one to find out where we are with items for C++ M2 RC1. >> >> From recent commits I think the status is: >> >> >> >> SDO >> >> - Stdcxx as a build option on Linux and Windows - done, aside from >> >> Linux support, probably not going to include Linux support >> >> - Support for an identified level of the SDO spec (2.01) - readme >> >> updated, but needs checking >> >> >> >> SCA >> >> - CPP, WS, Python, Ruby builds in source & binary release - Linux: >> >> done. Windows: CPP & WS done, Python & Ruby to do >> >> - Support for an identified level of the SCA assembly (0.96) and C++ >> >> C&I specs (0.95) - readme updated, but needs checking & adding to. >> >> >> >> Samples >> >> - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - >> >> documentation & deploy scripts done, Calculator windows build script >> >> done, BigBank windows build script to do. >> >> >> >> Docs >> >> - How to build SDO (with or without stdcxx) and SCA - done >> >> - How to deploy WS service/module to Axis2C - done >> >> - How to build/run the samples for SDO/SCA - done >> >> - Describe the new SCA language extensions progamming models - done >> >> - Release notes - updated, needs checking/adding to (see above) >> >> - How to turn existing C and/or C++ code into an SCA component - >> >> updated the "How to create a C++ component" doc - is this sufficient? >> >> >> >> Deployment >> >> - Simplify and open our tuscany-root folder structure to allow people >> >> to choose the structure that best fits their environment - done >> >> >> >> Release Requirements >> >> - Update Licence text in source files to the new Apache wording - >> done >> >> >> >> >> >> Does that look about right to people? Any other updates? Anything >> >> else to >> >> go in? >> >> >> >> Cheers! >> >> >> >> Andy >> >> >> >> - >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> Who has a complete environment to build a Linux distribution? >> >> I am able to generate a Linux distribution in the following environment: >> Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) >> Axis2c 0.94 >> Python 2.3.4 >> Ruby 1.8.1 >> PHP 5.1.6 >> httpd-2.2.3 >> Libxml2 2.6.20 >> >> My Python and Ruby installations are a little old, so I'll try to >> upgrade them to: >> Python 2.4.3 >> Ruby 1.8.5 >> later today... >> >> Do these levels look light to you for this release? Should we use >> different levels? >> >> I can help generate the distribution or just help with testing if >> somebody else has a better environment to build it (like a recent Fedora >> core for example). >> >> Let me know. Thanks. >> >> -- >> Jean-Sebastien >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > Pete, Our emails just crossed :) I had just sent another email saying Python 2.5 instead of 2.4.3 (and actually just downloaded 2.5). But I'd understand if you'd prefer to stay on 2.4.3 on Linux to stay in sync with Windows? I'm happy with that, on one hand Python 2.5 is the latest production release, but on the other hand it is very recent so I'm not sure if many people are already using it. Let me know which one you prefer to use for the binary distro (given that people can always build with the specific level they want from the source distro). Andy, if you are actually building the official distros on your machine please let me know which levels you are using. I'll use the same levels for testing then. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 RC1 status
Pete Robbins wrote: That looks good. I think Andy was going to generate/zip/sign/publish the packages for the distros. I tried Python 2.5 on Windows but had to go down to 2.4 so we'll stick there! Cheers, On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Pete Robbins wrote: > Sounds about right. I need to add Ruby and Python extensions into the > windows command line build. Hopefully this will be done today. > > Cheers, > > > On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> Just a quick one to find out where we are with items for C++ M2 RC1. >> From recent commits I think the status is: >> >> SDO >> - Stdcxx as a build option on Linux and Windows - done, aside from >> Linux support, probably not going to include Linux support >> - Support for an identified level of the SDO spec (2.01) - readme >> updated, but needs checking >> >> SCA >> - CPP, WS, Python, Ruby builds in source & binary release - Linux: >> done. Windows: CPP & WS done, Python & Ruby to do >> - Support for an identified level of the SCA assembly (0.96) and C++ >> C&I specs (0.95) - readme updated, but needs checking & adding to. >> >> Samples >> - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - >> documentation & deploy scripts done, Calculator windows build script >> done, BigBank windows build script to do. >> >> Docs >> - How to build SDO (with or without stdcxx) and SCA - done >> - How to deploy WS service/module to Axis2C - done >> - How to build/run the samples for SDO/SCA - done >> - Describe the new SCA language extensions progamming models - done >> - Release notes - updated, needs checking/adding to (see above) >> - How to turn existing C and/or C++ code into an SCA component - >> updated the "How to create a C++ component" doc - is this sufficient? >> >> Deployment >> - Simplify and open our tuscany-root folder structure to allow people >> to choose the structure that best fits their environment - done >> >> Release Requirements >> - Update Licence text in source files to the new Apache wording - done >> >> >> Does that look about right to people? Any other updates? Anything >> else to >> go in? >> >> Cheers! >> >> Andy >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > Who has a complete environment to build a Linux distribution? I am able to generate a Linux distribution in the following environment: Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) Axis2c 0.94 Python 2.3.4 Ruby 1.8.1 PHP 5.1.6 httpd-2.2.3 Libxml2 2.6.20 My Python and Ruby installations are a little old, so I'll try to upgrade them to: Python 2.4.3 Ruby 1.8.5 later today... Do these levels look light to you for this release? Should we use different levels? I can help generate the distribution or just help with testing if somebody else has a better environment to build it (like a recent Fedora core for example). Let me know. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Pete, Our emails just crossed :) I had just sent another email saying Python 2.5 instead of 2.4.3 (and actually just downloaded 2.5). But I'd understand if you'd prefer to stay on 2.4.3 on Linux to stay in sync with Windows? I'm happy with that, on one hand Python 2.5 is the latest production release, but on the other hand it is very recent so I'm not sure if many people are already using it. Let me know which one you prefer to use for the binary distro (given that people can always build with the specific level they want from the source distro). Andy, if you are actually building the official distros on your machine please let me know which levels you are using. I'll use the same levels for testing then. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
btw I changed the cpp/sca/build.sh to detect if you had the PYTHON_xxx and RUBY_xxx environment set and to configure with --enable-python --enable-ruby if they were. Cheers, On 10/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: That looks good. I think Andy was going to generate/zip/sign/publish the packages for the distros. I tried Python 2.5 on Windows but had to go down to 2.4 so we'll stick there! Cheers, On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Pete Robbins wrote: > > Sounds about right. I need to add Ruby and Python extensions into the > > windows command line build. Hopefully this will be done today. > > > > Cheers, > > > > > > On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > >> > >> Hi all, > >> > >> Just a quick one to find out where we are with items for C++ M2 RC1. > >> From recent commits I think the status is: > >> > >> SDO > >> - Stdcxx as a build option on Linux and Windows - done, aside from > >> Linux support, probably not going to include Linux support > >> - Support for an identified level of the SDO spec (2.01) - readme > >> updated, but needs checking > >> > >> SCA > >> - CPP, WS, Python, Ruby builds in source & binary release - Linux: > >> done. Windows: CPP & WS done, Python & Ruby to do > >> - Support for an identified level of the SCA assembly (0.96) and C++ > >> C&I specs (0.95) - readme updated, but needs checking & adding to. > >> > >> Samples > >> - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - > >> documentation & deploy scripts done, Calculator windows build script > >> done, BigBank windows build script to do. > >> > >> Docs > >> - How to build SDO (with or without stdcxx) and SCA - done > >> - How to deploy WS service/module to Axis2C - done > >> - How to build/run the samples for SDO/SCA - done > >> - Describe the new SCA language extensions progamming models - done > >> - Release notes - updated, needs checking/adding to (see above) > >> - How to turn existing C and/or C++ code into an SCA component - > >> updated the "How to create a C++ component" doc - is this sufficient? > >> > >> Deployment > >> - Simplify and open our tuscany-root folder structure to allow people > >> to choose the structure that best fits their environment - done > >> > >> Release Requirements > >> - Update Licence text in source files to the new Apache wording - > done > >> > >> > >> Does that look about right to people? Any other updates? Anything > >> else to > >> go in? > >> > >> Cheers! > >> > >> Andy > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > Who has a complete environment to build a Linux distribution? > > I am able to generate a Linux distribution in the following environment: > Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) > Axis2c 0.94 > Python 2.3.4 > Ruby 1.8.1 > PHP 5.1.6 > httpd-2.2.3 > Libxml2 2.6.20 > > My Python and Ruby installations are a little old, so I'll try to > upgrade them to: > Python 2.4.3 > Ruby 1.8.5 > later today... > > Do these levels look light to you for this release? Should we use > different levels? > > I can help generate the distribution or just help with testing if > somebody else has a better environment to build it (like a recent Fedora > > core for example). > > Let me know. Thanks. > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete -- Pete
Re: [C++] M2 RC1 status
That looks good. I think Andy was going to generate/zip/sign/publish the packages for the distros. I tried Python 2.5 on Windows but had to go down to 2.4 so we'll stick there! Cheers, On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Pete Robbins wrote: > Sounds about right. I need to add Ruby and Python extensions into the > windows command line build. Hopefully this will be done today. > > Cheers, > > > On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> Just a quick one to find out where we are with items for C++ M2 RC1. >> From recent commits I think the status is: >> >> SDO >> - Stdcxx as a build option on Linux and Windows - done, aside from >> Linux support, probably not going to include Linux support >> - Support for an identified level of the SDO spec (2.01) - readme >> updated, but needs checking >> >> SCA >> - CPP, WS, Python, Ruby builds in source & binary release - Linux: >> done. Windows: CPP & WS done, Python & Ruby to do >> - Support for an identified level of the SCA assembly (0.96) and C++ >> C&I specs (0.95) - readme updated, but needs checking & adding to. >> >> Samples >> - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - >> documentation & deploy scripts done, Calculator windows build script >> done, BigBank windows build script to do. >> >> Docs >> - How to build SDO (with or without stdcxx) and SCA - done >> - How to deploy WS service/module to Axis2C - done >> - How to build/run the samples for SDO/SCA - done >> - Describe the new SCA language extensions progamming models - done >> - Release notes - updated, needs checking/adding to (see above) >> - How to turn existing C and/or C++ code into an SCA component - >> updated the "How to create a C++ component" doc - is this sufficient? >> >> Deployment >> - Simplify and open our tuscany-root folder structure to allow people >> to choose the structure that best fits their environment - done >> >> Release Requirements >> - Update Licence text in source files to the new Apache wording - done >> >> >> Does that look about right to people? Any other updates? Anything >> else to >> go in? >> >> Cheers! >> >> Andy >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > Who has a complete environment to build a Linux distribution? I am able to generate a Linux distribution in the following environment: Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) Axis2c 0.94 Python 2.3.4 Ruby 1.8.1 PHP 5.1.6 httpd-2.2.3 Libxml2 2.6.20 My Python and Ruby installations are a little old, so I'll try to upgrade them to: Python 2.4.3 Ruby 1.8.5 later today... Do these levels look light to you for this release? Should we use different levels? I can help generate the distribution or just help with testing if somebody else has a better environment to build it (like a recent Fedora core for example). Let me know. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 RC1 status
Jean-Sebastien Delfino wrote: Pete Robbins wrote: Sounds about right. I need to add Ruby and Python extensions into the windows command line build. Hopefully this will be done today. Cheers, On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Who has a complete environment to build a Linux distribution? I am able to generate a Linux distribution in the following environment: Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) Axis2c 0.94 Python 2.3.4 Ruby 1.8.1 PHP 5.1.6 httpd-2.2.3 Libxml2 2.6.20 My Python and Ruby installations are a little old, so I'll try to upgrade them to: Python 2.4.3 Should have been Python 2.5 instead of 2.4.3. Ruby 1.8.5 later today... Do these levels look light to you for this release? Should we use different levels? I can help generate the distribution or just help with testing if somebody else has a better environment to build it (like a recent Fedora core for example). Let me know. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
Pete Robbins wrote: Sounds about right. I need to add Ruby and Python extensions into the windows command line build. Hopefully this will be done today. Cheers, On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Who has a complete environment to build a Linux distribution? I am able to generate a Linux distribution in the following environment: Redhat Enterprise Linux 4 (with a 2.6.9-34 kernel) Axis2c 0.94 Python 2.3.4 Ruby 1.8.1 PHP 5.1.6 httpd-2.2.3 Libxml2 2.6.20 My Python and Ruby installations are a little old, so I'll try to upgrade them to: Python 2.4.3 Ruby 1.8.5 later today... Do these levels look light to you for this release? Should we use different levels? I can help generate the distribution or just help with testing if somebody else has a better environment to build it (like a recent Fedora core for example). Let me know. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
Pete Robbins wrote:
Sebastien,
fyi I'm looking and this and will have a different "fix" up there later
today/tomorrow so no need for us both to look at it ;-)
Cheers,
On 10/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Pete Robbins wrote:
> > We need to consider the pass by-value vs pass by-reference
semantics,
> > including "deep copying" the DataObject tree. I have thought
about his
>
> > and
> > we should discuss this after M2. I'll put together a proposal on
> another
> > thread.
> >
> > For now though I would change your patch and have Operation allocate
> and
> > free DataObjectPtrs as appropriate. The memory leak of the odd int,
> > double,
> > or even a string is not going to be significant but with
DataObjectPtr
> > the
> > DOs will never get freed... or the DataFactory that created them
> ...etc..
> >
> >
> >void Operation::addParameter(const DataObjectPtr *parm)
> >{
> >LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
> >parameters.insert(parameters.end(),
Parameter((void*)parm,
> > DATAOBJECT));
> >}
> >
> > would become
> >
> >void Operation::addParameter(const DataObjectPtr *parm)
> >{
> >LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
> > parameters.insert(parameters.end(), Parameter((void*)new
> > DataObjectPtr(*parm), DATAOBJECT));
> >}
> >
> > and the Operation destructor would need to find all the DATAOBJECT
> type
> > paramters and delete the DataObjectPtr.
> >
> > Cheers,
> > On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>
> >> Pete Robbins wrote:
> >> > On 10/10/06, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
wrote:
> >> >>
> >> >> On the plane on my way to ApacheCon I was playing around with
our
> Web
> >> >> Services support (adding a Web Services client to BigBank) and
> >> found a
> >> >> serious problem in Axis2Client and WSServiceProxy, which
allocate
> the
> >> >> DataObject pointers they return on the stack instead of doing a
> new
> >> >> DataObjectPtr. This causes a memory violation if a client
tries to
>
> >> >> access a DataObject returned from a Web service.
> >> >>
> >> >> I raised JIRA TUSCANY-816 for this, have the fix but need to
do a
> >> little
> >> >> more testing before I commit it. If things go well I should be
> >> able to
> >> >> commit it later this evening.
> >> >
> >> >
> >> > Having a quick glance at this code I was wondering who frees
up the
> >> > memory
> >> > allocated by Axis2Client and set in the Operation?
> >>
> >> Currently, nobody :) We had already started to discuss this
issue in
> >> this thread:
> >>
> >>
>
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED]
> >>
> >> but we don't have a definitive solution for it yet.
> >>
> >> > For DataObjectPtr we could have the
> >> > Operation::setParameter/setReturnValue
> >> > methods new up a DataObjectPtr and free it in the destructor.
This
> >> would
> >> > work nicely with this as it is reference counted. A different
> solution
> >> > would
> >> > be needed for the other types.
> >>
> >> I think you're right, but we need to take a close look at the
> lifecycle
> >> of the data flowing through the runtime. For example, data to a
> client
> >> component returned from a service invocation cannot be freed until
> the
> >> client component finishes.
> >>
> >> Here's a first analysis of how we could handle the data set into an
> >> Operation parameters or returnValue. It may not be completely right
> but
> >> it's a starting point to help trigger some ideas...
> >>
> >> Parameters:
> >> - a DataObjectPtr set into the parameter --> can be freed when the
> >> Operation is deleted (in the ServiceProxy::invoke method just
before
> >> returning)
> >> - the DataObject pointed to by that DataObjectPtr --> will be freed
> when
> >> its reference count goes down to 0
> >> - a string* or int* or char** set into the parameter --> can be
freed
>
> >> when the Operation is deleted
> >> - the string or int pointed to by that string* or int* --> can be
> freed
> >> when the Operation is deleted
> >> - the char* --> document that the component getting the char* is
> >> responsible for freeing it? or free it when the Operation is
deleted?
> >>
> >> Return value:
> >> - a DataObjectPtr set into the return value --> can be freed when
> the
> >> Operation is deleted
> >> - the DataObject pointed to by that DataObjectPtr --> will be freed
> when
> >> its reference count goes down to 0
> >> - a string* or int* or char** set into the parameter --> can be
freed
> >> when the Operation is deleted
> >> - the string or int pointed to by that string* or int* --> can be
> freed
> >> when the Operation is deleted
> >> - the char* --> document that the component getting the char* is
> >> responsible for freeing it? or?
> >>
> >> Anyway, I'm not sure what you guys
Re: [C++] M2 RC1 status
Sebastien,
fyi I'm looking and this and will have a different "fix" up there later
today/tomorrow so no need for us both to look at it ;-)
Cheers,
On 10/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Pete Robbins wrote:
> > We need to consider the pass by-value vs pass by-reference semantics,
> > including "deep copying" the DataObject tree. I have thought about his
>
> > and
> > we should discuss this after M2. I'll put together a proposal on
> another
> > thread.
> >
> > For now though I would change your patch and have Operation allocate
> and
> > free DataObjectPtrs as appropriate. The memory leak of the odd int,
> > double,
> > or even a string is not going to be significant but with DataObjectPtr
> > the
> > DOs will never get freed... or the DataFactory that created them
> ...etc..
> >
> >
> >void Operation::addParameter(const DataObjectPtr *parm)
> >{
> >LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
> >parameters.insert(parameters.end(), Parameter((void*)parm,
> > DATAOBJECT));
> >}
> >
> > would become
> >
> >void Operation::addParameter(const DataObjectPtr *parm)
> >{
> >LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
> > parameters.insert(parameters.end(), Parameter((void*)new
> > DataObjectPtr(*parm), DATAOBJECT));
> >}
> >
> > and the Operation destructor would need to find all the DATAOBJECT
> type
> > paramters and delete the DataObjectPtr.
> >
> > Cheers,
> > On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>
> >> Pete Robbins wrote:
> >> > On 10/10/06, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> >> >>
> >> >> On the plane on my way to ApacheCon I was playing around with our
> Web
> >> >> Services support (adding a Web Services client to BigBank) and
> >> found a
> >> >> serious problem in Axis2Client and WSServiceProxy, which allocate
> the
> >> >> DataObject pointers they return on the stack instead of doing a
> new
> >> >> DataObjectPtr. This causes a memory violation if a client tries to
>
> >> >> access a DataObject returned from a Web service.
> >> >>
> >> >> I raised JIRA TUSCANY-816 for this, have the fix but need to do a
> >> little
> >> >> more testing before I commit it. If things go well I should be
> >> able to
> >> >> commit it later this evening.
> >> >
> >> >
> >> > Having a quick glance at this code I was wondering who frees up the
> >> > memory
> >> > allocated by Axis2Client and set in the Operation?
> >>
> >> Currently, nobody :) We had already started to discuss this issue in
> >> this thread:
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL
PROTECTED]
> >>
> >> but we don't have a definitive solution for it yet.
> >>
> >> > For DataObjectPtr we could have the
> >> > Operation::setParameter/setReturnValue
> >> > methods new up a DataObjectPtr and free it in the destructor. This
> >> would
> >> > work nicely with this as it is reference counted. A different
> solution
> >> > would
> >> > be needed for the other types.
> >>
> >> I think you're right, but we need to take a close look at the
> lifecycle
> >> of the data flowing through the runtime. For example, data to a
> client
> >> component returned from a service invocation cannot be freed until
> the
> >> client component finishes.
> >>
> >> Here's a first analysis of how we could handle the data set into an
> >> Operation parameters or returnValue. It may not be completely right
> but
> >> it's a starting point to help trigger some ideas...
> >>
> >> Parameters:
> >> - a DataObjectPtr set into the parameter --> can be freed when the
> >> Operation is deleted (in the ServiceProxy::invoke method just before
> >> returning)
> >> - the DataObject pointed to by that DataObjectPtr --> will be freed
> when
> >> its reference count goes down to 0
> >> - a string* or int* or char** set into the parameter --> can be freed
>
> >> when the Operation is deleted
> >> - the string or int pointed to by that string* or int* --> can be
> freed
> >> when the Operation is deleted
> >> - the char* --> document that the component getting the char* is
> >> responsible for freeing it? or free it when the Operation is deleted?
> >>
> >> Return value:
> >> - a DataObjectPtr set into the return value --> can be freed when
> the
> >> Operation is deleted
> >> - the DataObject pointed to by that DataObjectPtr --> will be freed
> when
> >> its reference count goes down to 0
> >> - a string* or int* or char** set into the parameter --> can be freed
> >> when the Operation is deleted
> >> - the string or int pointed to by that string* or int* --> can be
> freed
> >> when the Operation is deleted
> >> - the char* --> document that the component getting the char* is
> >> responsible for freeing it? or?
> >>
> >> Anyway, I'm not sure what you guys think, but unless we have a very
> >> clear view of how
Re: [C++] M2 RC1 status
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote:
> We need to consider the pass by-value vs pass by-reference semantics,
> including "deep copying" the DataObject tree. I have thought about his
> and
> we should discuss this after M2. I'll put together a proposal on another
> thread.
>
> For now though I would change your patch and have Operation allocate and
> free DataObjectPtrs as appropriate. The memory leak of the odd int,
> double,
> or even a string is not going to be significant but with DataObjectPtr
> the
> DOs will never get freed... or the DataFactory that created them
...etc..
>
>
>void Operation::addParameter(const DataObjectPtr *parm)
>{
>LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
>parameters.insert(parameters.end(), Parameter((void*)parm,
> DATAOBJECT));
>}
>
> would become
>
>void Operation::addParameter(const DataObjectPtr *parm)
>{
>LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
>parameters.insert(parameters.end(), Parameter((void*)new
> DataObjectPtr(*parm), DATAOBJECT));
>}
>
> and the Operation destructor would need to find all the DATAOBJECT type
> paramters and delete the DataObjectPtr.
>
> Cheers,
> On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Pete Robbins wrote:
>> > On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> On the plane on my way to ApacheCon I was playing around with our
Web
>> >> Services support (adding a Web Services client to BigBank) and
>> found a
>> >> serious problem in Axis2Client and WSServiceProxy, which allocate
the
>> >> DataObject pointers they return on the stack instead of doing a new
>> >> DataObjectPtr. This causes a memory violation if a client tries to
>> >> access a DataObject returned from a Web service.
>> >>
>> >> I raised JIRA TUSCANY-816 for this, have the fix but need to do a
>> little
>> >> more testing before I commit it. If things go well I should be
>> able to
>> >> commit it later this evening.
>> >
>> >
>> > Having a quick glance at this code I was wondering who frees up the
>> > memory
>> > allocated by Axis2Client and set in the Operation?
>>
>> Currently, nobody :) We had already started to discuss this issue in
>> this thread:
>>
>>
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL
PROTECTED]
>>
>> but we don't have a definitive solution for it yet.
>>
>> > For DataObjectPtr we could have the
>> > Operation::setParameter/setReturnValue
>> > methods new up a DataObjectPtr and free it in the destructor. This
>> would
>> > work nicely with this as it is reference counted. A different
solution
>> > would
>> > be needed for the other types.
>>
>> I think you're right, but we need to take a close look at the lifecycle
>> of the data flowing through the runtime. For example, data to a client
>> component returned from a service invocation cannot be freed until the
>> client component finishes.
>>
>> Here's a first analysis of how we could handle the data set into an
>> Operation parameters or returnValue. It may not be completely right but
>> it's a starting point to help trigger some ideas...
>>
>> Parameters:
>> - a DataObjectPtr set into the parameter --> can be freed when the
>> Operation is deleted (in the ServiceProxy::invoke method just before
>> returning)
>> - the DataObject pointed to by that DataObjectPtr --> will be freed
when
>> its reference count goes down to 0
>> - a string* or int* or char** set into the parameter --> can be freed
>> when the Operation is deleted
>> - the string or int pointed to by that string* or int* --> can be freed
>> when the Operation is deleted
>> - the char* --> document that the component getting the char* is
>> responsible for freeing it? or free it when the Operation is deleted?
>>
>> Return value:
>> - a DataObjectPtr set into the return value --> can be freed when the
>> Operation is deleted
>> - the DataObject pointed to by that DataObjectPtr --> will be freed
when
>> its reference count goes down to 0
>> - a string* or int* or char** set into the parameter --> can be freed
>> when the Operation is deleted
>> - the string or int pointed to by that string* or int* --> can be freed
>> when the Operation is deleted
>> - the char* --> document that the component getting the char* is
>> responsible for freeing it? or?
>>
>> Anyway, I'm not sure what you guys think, but unless we have a very
>> clear view of how to fix this, I'd suggest to tackle this problem after
>> the M2 release and live with the small memory leak for now.
>>
>> Thoughts?
>>
>> >
>> > Cheers,
>> >
>> >
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
Ah OK I didn't realize that not freeing the DataObjectPtr was going to
keep all the related
Re: [C++] M2 RC1 status
Pete Robbins wrote:
We need to consider the pass by-value vs pass by-reference semantics,
including "deep copying" the DataObject tree. I have thought about his
and
we should discuss this after M2. I'll put together a proposal on another
thread.
For now though I would change your patch and have Operation allocate and
free DataObjectPtrs as appropriate. The memory leak of the odd int,
double,
or even a string is not going to be significant but with DataObjectPtr
the
DOs will never get freed... or the DataFactory that created them ...etc..
void Operation::addParameter(const DataObjectPtr *parm)
{
LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
parameters.insert(parameters.end(), Parameter((void*)parm,
DATAOBJECT));
}
would become
void Operation::addParameter(const DataObjectPtr *parm)
{
LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
parameters.insert(parameters.end(), Parameter((void*)new
DataObjectPtr(*parm), DATAOBJECT));
}
and the Operation destructor would need to find all the DATAOBJECT type
paramters and delete the DataObjectPtr.
Cheers,
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote:
> On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> On the plane on my way to ApacheCon I was playing around with our Web
>> Services support (adding a Web Services client to BigBank) and
found a
>> serious problem in Axis2Client and WSServiceProxy, which allocate the
>> DataObject pointers they return on the stack instead of doing a new
>> DataObjectPtr. This causes a memory violation if a client tries to
>> access a DataObject returned from a Web service.
>>
>> I raised JIRA TUSCANY-816 for this, have the fix but need to do a
little
>> more testing before I commit it. If things go well I should be
able to
>> commit it later this evening.
>
>
> Having a quick glance at this code I was wondering who frees up the
> memory
> allocated by Axis2Client and set in the Operation?
Currently, nobody :) We had already started to discuss this issue in
this thread:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED]
but we don't have a definitive solution for it yet.
> For DataObjectPtr we could have the
> Operation::setParameter/setReturnValue
> methods new up a DataObjectPtr and free it in the destructor. This
would
> work nicely with this as it is reference counted. A different solution
> would
> be needed for the other types.
I think you're right, but we need to take a close look at the lifecycle
of the data flowing through the runtime. For example, data to a client
component returned from a service invocation cannot be freed until the
client component finishes.
Here's a first analysis of how we could handle the data set into an
Operation parameters or returnValue. It may not be completely right but
it's a starting point to help trigger some ideas...
Parameters:
- a DataObjectPtr set into the parameter --> can be freed when the
Operation is deleted (in the ServiceProxy::invoke method just before
returning)
- the DataObject pointed to by that DataObjectPtr --> will be freed when
its reference count goes down to 0
- a string* or int* or char** set into the parameter --> can be freed
when the Operation is deleted
- the string or int pointed to by that string* or int* --> can be freed
when the Operation is deleted
- the char* --> document that the component getting the char* is
responsible for freeing it? or free it when the Operation is deleted?
Return value:
- a DataObjectPtr set into the return value --> can be freed when the
Operation is deleted
- the DataObject pointed to by that DataObjectPtr --> will be freed when
its reference count goes down to 0
- a string* or int* or char** set into the parameter --> can be freed
when the Operation is deleted
- the string or int pointed to by that string* or int* --> can be freed
when the Operation is deleted
- the char* --> document that the component getting the char* is
responsible for freeing it? or?
Anyway, I'm not sure what you guys think, but unless we have a very
clear view of how to fix this, I'd suggest to tackle this problem after
the M2 release and live with the small memory leak for now.
Thoughts?
>
> Cheers,
>
>
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ah OK I didn't realize that not freeing the DataObjectPtr was going to
keep all the related DataObjects around... What you're proposing looks
good to me. For M2 I agree with you that we should only handle the
DataObject case, but I'm curious: will the same technique apply to the
other types as well then?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
Re: [C++] M2 RC1 status
We need to consider the pass by-value vs pass by-reference semantics,
including "deep copying" the DataObject tree. I have thought about his and
we should discuss this after M2. I'll put together a proposal on another
thread.
For now though I would change your patch and have Operation allocate and
free DataObjectPtrs as appropriate. The memory leak of the odd int, double,
or even a string is not going to be significant but with DataObjectPtr the
DOs will never get freed... or the DataFactory that created them ...etc..
void Operation::addParameter(const DataObjectPtr *parm)
{
LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
parameters.insert(parameters.end(), Parameter((void*)parm,
DATAOBJECT));
}
would become
void Operation::addParameter(const DataObjectPtr *parm)
{
LOGINFO(4, "Operation::addParameter(DataObjectPtr)");
parameters.insert(parameters.end(), Parameter((void*)new
DataObjectPtr(*parm), DATAOBJECT));
}
and the Operation destructor would need to find all the DATAOBJECT type
paramters and delete the DataObjectPtr.
Cheers,
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote:
> On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> On the plane on my way to ApacheCon I was playing around with our Web
>> Services support (adding a Web Services client to BigBank) and found a
>> serious problem in Axis2Client and WSServiceProxy, which allocate the
>> DataObject pointers they return on the stack instead of doing a new
>> DataObjectPtr. This causes a memory violation if a client tries to
>> access a DataObject returned from a Web service.
>>
>> I raised JIRA TUSCANY-816 for this, have the fix but need to do a
little
>> more testing before I commit it. If things go well I should be able to
>> commit it later this evening.
>
>
> Having a quick glance at this code I was wondering who frees up the
> memory
> allocated by Axis2Client and set in the Operation?
Currently, nobody :) We had already started to discuss this issue in
this thread:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL
PROTECTED]
but we don't have a definitive solution for it yet.
> For DataObjectPtr we could have the
> Operation::setParameter/setReturnValue
> methods new up a DataObjectPtr and free it in the destructor. This would
> work nicely with this as it is reference counted. A different solution
> would
> be needed for the other types.
I think you're right, but we need to take a close look at the lifecycle
of the data flowing through the runtime. For example, data to a client
component returned from a service invocation cannot be freed until the
client component finishes.
Here's a first analysis of how we could handle the data set into an
Operation parameters or returnValue. It may not be completely right but
it's a starting point to help trigger some ideas...
Parameters:
- a DataObjectPtr set into the parameter --> can be freed when the
Operation is deleted (in the ServiceProxy::invoke method just before
returning)
- the DataObject pointed to by that DataObjectPtr --> will be freed when
its reference count goes down to 0
- a string* or int* or char** set into the parameter --> can be freed
when the Operation is deleted
- the string or int pointed to by that string* or int* --> can be freed
when the Operation is deleted
- the char* --> document that the component getting the char* is
responsible for freeing it? or free it when the Operation is deleted?
Return value:
- a DataObjectPtr set into the return value --> can be freed when the
Operation is deleted
- the DataObject pointed to by that DataObjectPtr --> will be freed when
its reference count goes down to 0
- a string* or int* or char** set into the parameter --> can be freed
when the Operation is deleted
- the string or int pointed to by that string* or int* --> can be freed
when the Operation is deleted
- the char* --> document that the component getting the char* is
responsible for freeing it? or?
Anyway, I'm not sure what you guys think, but unless we have a very
clear view of how to fix this, I'd suggest to tackle this problem after
the M2 release and live with the small memory leak for now.
Thoughts?
>
> Cheers,
>
>
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
Re: [C++] M2 RC1 status
Pete Robbins wrote: On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. Having a quick glance at this code I was wondering who frees up the memory allocated by Axis2Client and set in the Operation? Currently, nobody :) We had already started to discuss this issue in this thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] but we don't have a definitive solution for it yet. For DataObjectPtr we could have the Operation::setParameter/setReturnValue methods new up a DataObjectPtr and free it in the destructor. This would work nicely with this as it is reference counted. A different solution would be needed for the other types. I think you're right, but we need to take a close look at the lifecycle of the data flowing through the runtime. For example, data to a client component returned from a service invocation cannot be freed until the client component finishes. Here's a first analysis of how we could handle the data set into an Operation parameters or returnValue. It may not be completely right but it's a starting point to help trigger some ideas... Parameters: - a DataObjectPtr set into the parameter --> can be freed when the Operation is deleted (in the ServiceProxy::invoke method just before returning) - the DataObject pointed to by that DataObjectPtr --> will be freed when its reference count goes down to 0 - a string* or int* or char** set into the parameter --> can be freed when the Operation is deleted - the string or int pointed to by that string* or int* --> can be freed when the Operation is deleted - the char* --> document that the component getting the char* is responsible for freeing it? or free it when the Operation is deleted? Return value: - a DataObjectPtr set into the return value --> can be freed when the Operation is deleted - the DataObject pointed to by that DataObjectPtr --> will be freed when its reference count goes down to 0 - a string* or int* or char** set into the parameter --> can be freed when the Operation is deleted - the string or int pointed to by that string* or int* --> can be freed when the Operation is deleted - the char* --> document that the component getting the char* is responsible for freeing it? or? Anyway, I'm not sure what you guys think, but unless we have a very clear view of how to fix this, I'd suggest to tackle this problem after the M2 release and live with the small memory leak for now. Thoughts? Cheers, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
Sounds about right. I need to add Ruby and Python extensions into the windows command line build. Hopefully this will be done today. Cheers, On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 RC1 status
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. Having a quick glance at this code I was wondering who frees up the memory allocated by Axis2Client and set in the Operation? For DataObjectPtr we could have the Operation::setParameter/setReturnValue methods new up a DataObjectPtr and free it in the destructor. This would work nicely with this as it is reference counted. A different solution would be needed for the other types. Cheers, -- Pete
Re: [C++] M2 RC1 status
Andrew Borley wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes, On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
