Re: [SDO for C++] How to raise JIRAs for 2.1 spec compliance
Geoff, there is a specification category for Jiras so when you raise one you can select SDO C++ and specification. Prefixing the summary field is a good idea.. maybe [SDO C++ 2.1 Spec] as the specification classification covers Java/C++ and sdo/sca. Actually I'm not sure if the specification category is for changes we, Tuscany, want to see in the specs... Just raise them against SDO C++ with the [SDO C++ 2.1 Spec] summary prefix Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff. -- Pete
Re: [SDO for C++] How to raise JIRAs for 2.1 spec compliance
Whatever you like. You don't see the component in the Jira created message so maybe we should put this in there. Or... get Jira to add it in automagically if anyone knows how?? Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Are you sure about the SDO C++ part in square brackets? These JIRAs will already have their component property set to C++ SDO so they are easy enough to identify as belonging to SDO for C++. I was trying not to clutter the summary too much. Regards, Geoff. On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, there is a specification category for Jiras so when you raise one you can select SDO C++ and specification. Prefixing the summary field is a good idea.. maybe [SDO C++ 2.1 Spec] as the specification classification covers Java/C++ and sdo/sca. Actually I'm not sure if the specification category is for changes we, Tuscany, want to see in the specs... Just raise them against SDO C++ with the [SDO C++ 2.1 Spec] summary prefix Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff. -- Pete -- Pete
Re: [SDO for C++] How to raise JIRAs for 2.1 spec compliance
Actually you may have noticed we don't prefix the Jira summaries at the moment ;-) Maybe we should spread this discussion... On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Whatever you like. You don't see the component in the Jira created message so maybe we should put this in there. That's a good point. OK, I'm persuaded. I'll use [SDO C++ 2.1 Spec] Regards, Geoff. Or... get Jira to add it in automagically if anyone knows how?? Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Are you sure about the SDO C++ part in square brackets? These JIRAs will already have their component property set to C++ SDO so they are easy enough to identify as belonging to SDO for C++. I was trying not to clutter the summary too much. Regards, Geoff. On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, there is a specification category for Jiras so when you raise one you can select SDO C++ and specification. Prefixing the summary field is a good idea.. maybe [SDO C++ 2.1Spec] as the specification classification covers Java/C++ and sdo/sca. Actually I'm not sure if the specification category is for changes we, Tuscany, want to see in the specs... Just raise them against SDO C++ with the [SDO C++ 2.1 Spec] summary prefix Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff. -- Pete -- Pete -- Pete
Re: [C++] Showing PHP-SDO and PHP-SCA in our BigBank sample?
I'm assuming this does not require our Tuscany PHP language extension that we agreed would NOT be in this release? Cheers, On 16/10/06, haleh mahbod [EMAIL PROTECTED] wrote: This is good idea. This sample could also be published on osoa.org where SCA for PHP is posted. On 10/15/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, Our current C++ Bigbank sample includes a nice PHP client that shows how to use the SDO for PHP extension (built on top of our SDO C++ implementation and available at http://pecl.php.net/package/SDO) and the PHP SOAP extensions to invoke the SCA BigBank app. There's now a new SCA for PHP extension available on www.osoa.org (see http://www.osoa.org/display/PHP/SOA+PHP+Homepage). Would it make sense to replace the call to the SOAP extensions by a call to that new SCA for PHP extension? I think it would give us a very nice integration scenario for our M2 release. Could this be added without destabiliziing the release? I just reviewed the RC1 and think we're almost there so I wouldn't want at all to break it by adding stuff at the last minute! On the other hand if it's really easy to modify the PHP part of the Bigbank sample to include that PHP-SCA package that would be really cool... P.S: a side note, that PHP client is pretty well documented, listed in the Readme etc, and looks good, but actually missing from the RC1 binary distro :) this is just a small bug in the build, I'll create a JIRA for this, independent of the question I'm asking here... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: C++ Test framework, was SDO Java: Getting Involved -- Tests/Samples
I'm not familiar with cxxtest but as we need to write a SCA C++ test suite it would be good to use the same tool that SDO uses. So we should certainly take a look at this and use every bit of help that's available ;-) Cheers, On 14/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] T Gould wrote: In addition to the actual tests, I think it would be wise if we make sure we are on common ground relative to the test framework -- for both Java and C++. I am not certain how we would best go about doing this, but a couple of items would include: *ensuring we are using the same tools. (we use JUnit and CxxTest) *what if any architectural documents for Java and C++ test suites exist --- if this is none - we might want to work togeher to build out the documents *can we work together to create test suite design? tom Sounds good to me. I suggest we start discussing proposals on the dev list, then when we have a good idea of the general direction use our Wiki to work on documenting it. So here's my small contribution to help initiate the discussion: CxxTest looks good to me. We could develop new tests with it, and progressively port existing test cases (both SCA and SDO) to it. I don't know if everybody in the group is very familiar with CxxTest so maybe we could use some of Tom's test cases as examples to bootstrap this process. Pete, I remember that you had mentioned some ideas a while back around testing in SCA C++. Have you looked at CxxTest? What do you think? Tom, could you share your experience with CxxTest? is it easy to integrate in an automake build on Linux? what about a VStudio environment? are you using Perl or Python with it? are you using a different framework for function and integration tests? Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
[jira] Commented: (TUSCANY-848) Some files missing the Apache license header
[ http://issues.apache.org/jira/browse/TUSCANY-848?page=comments#action_12442543 ] Pete Robbins commented on TUSCANY-848: -- I'm not sure how we fix the SDO test files. These are files that show the expected output of SDO serialisation and the like. The expected output will never contain a licence header. It seems odd that these files need the licence. Some files missing the Apache license header Key: TUSCANY-848 URL: http://issues.apache.org/jira/browse/TUSCANY-848 Project: Tuscany Issue Type: Bug Components: C++ SCA, C++ SDO Affects Versions: Cpp-M2 Reporter: Jean-Sebastien Delfino Priority: Blocker Fix For: Cpp-M2 In both the source and bin distributions, the following files are missing the Apache license header: SCA GettingStarted.html and samples/GettingStarted.html. In both SCA and SDO, all the Makefile.am files. In both SCA and SDO, doc/css/maven-base.css and maven-theme.css. SCA xsd/readme.txt. SCA, the two package.html file in scagen.jar. And in the source distributions: In both SCA and SDO configure.ac Under SDO runtime/core/test/ a number of .txt, .xs, .wsdl test files: 48736_xml.txt 48736_xsd.txt StockQuoteService.wsdl b46633.txt b46634_out.txt b47137.txt b47137b.txt b47293.txt b48633_xml.txt b48633b_xsd.txt b48636_xml.txt b48636_xsd.txt b48686_xml.txt b48686_xsd.txt badelement.txt bothgroups_xsd.txt bothgroupssamename_xsd.txt bug2.txt bug45933-output.txt bug48300_xml.txt bug48300_xsd.txt bunique-out.txt bunique-out.xsd_safe.txt bunique-outxml.txt buniqueread-out.txt calculator2.wsdl calculator2a.wsdl carotest3.txt csload-output.txt csload2-output.txt csload3-output.txt cssave-output.txt cssave2-output.txt datetest.txt defaults.txt doctest.txt emptycs1.txt emptycs2.txt emptycs3.txt getproptest.txt groupingroup_xsd.txt grouprefingroup_xsd.txt grouptoolate_xsd.txt groupwithprefix_xsd.txt inc1.txt inc2.txt jira490.txt jira705.xsd jira705_out.txt list1_xml.txt list1_xsd.txt loadload-output.txt maintest.txt matttest1.txt merle1.txt notns.txt nulltest.txt oddchars.txt openloadNSout.txt openseq.txt order1.txt order2.txt querytest.txt saveopen-output.txt scenario1.txt scenario2.txt scenario3.txt scenario4.txt scenario5.txt sequence.txt setmany.txt setnull.txt showdefault1.txt showdefault2.txt simple.txt stock.wsdl stock_wsdl.txt stock_xml.txt testabstract.txt testerrors.txt testinc2.txt testopen.txt testorder.txt teststyles.txt testsubsload.txt testutils.txt testwsdl.txt travel.txt userdata.txt xhtml1.xsd xhtml_out.txt To run the ARAT tool, get it from svn checkout http://arat.googlecode.com/svn/trunk/ arat, build it with Ant (you just need the JDK and Ant) then run java -jar rat-0.1-SNAPSHOT.jar directory-to-scan. It will produce a report showing the licenses and notices that it finds. Violations are marked with a '!'. The tool incorrectly reports violations on binary files and the INSTALL files which I think are OK (I have not found an Apache project with a license at the top of its INSTALL file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-848) Some files missing the Apache license header
[ http://issues.apache.org/jira/browse/TUSCANY-848?page=comments#action_12442628 ] Pete Robbins commented on TUSCANY-848: -- I have added the correct licence info to: SCA GettingStarted.html and samples/GettingStarted.html. In both SCA and SDO, all the Makefile.am files. In both SCA and SDO, doc/css/maven-base.css and maven-theme.css. SCA, the two package.html file in scagen.jar. And in the source distributions: In both SCA and SDO configure.ac Also I deleted the SCA xsd/readme.txt. which contains no useful info. The SDO runtime/core/test files that are input only have had licence headers added. The remaining files are expected output files and can be classed as binary and therefore do not need licence headers (see query I posted to [EMAIL PROTECTED]). I will list these files in a readme.txt in the runtime/core/test folder. Some files missing the Apache license header Key: TUSCANY-848 URL: http://issues.apache.org/jira/browse/TUSCANY-848 Project: Tuscany Issue Type: Bug Components: C++ SCA, C++ SDO Affects Versions: Cpp-M2 Reporter: Jean-Sebastien Delfino Assigned To: Pete Robbins Priority: Blocker Fix For: Cpp-M2 In both the source and bin distributions, the following files are missing the Apache license header: SCA GettingStarted.html and samples/GettingStarted.html. In both SCA and SDO, all the Makefile.am files. In both SCA and SDO, doc/css/maven-base.css and maven-theme.css. SCA xsd/readme.txt. SCA, the two package.html file in scagen.jar. And in the source distributions: In both SCA and SDO configure.ac Under SDO runtime/core/test/ a number of .txt, .xs, .wsdl test files: 48736_xml.txt 48736_xsd.txt StockQuoteService.wsdl b46633.txt b46634_out.txt b47137.txt b47137b.txt b47293.txt b48633_xml.txt b48633b_xsd.txt b48636_xml.txt b48636_xsd.txt b48686_xml.txt b48686_xsd.txt badelement.txt bothgroups_xsd.txt bothgroupssamename_xsd.txt bug2.txt bug45933-output.txt bug48300_xml.txt bug48300_xsd.txt bunique-out.txt bunique-out.xsd_safe.txt bunique-outxml.txt buniqueread-out.txt calculator2.wsdl calculator2a.wsdl carotest3.txt csload-output.txt csload2-output.txt csload3-output.txt cssave-output.txt cssave2-output.txt datetest.txt defaults.txt doctest.txt emptycs1.txt emptycs2.txt emptycs3.txt getproptest.txt groupingroup_xsd.txt grouprefingroup_xsd.txt grouptoolate_xsd.txt groupwithprefix_xsd.txt inc1.txt inc2.txt jira490.txt jira705.xsd jira705_out.txt list1_xml.txt list1_xsd.txt loadload-output.txt maintest.txt matttest1.txt merle1.txt notns.txt nulltest.txt oddchars.txt openloadNSout.txt openseq.txt order1.txt order2.txt querytest.txt saveopen-output.txt scenario1.txt scenario2.txt scenario3.txt scenario4.txt scenario5.txt sequence.txt setmany.txt setnull.txt showdefault1.txt showdefault2.txt simple.txt stock.wsdl stock_wsdl.txt stock_xml.txt testabstract.txt testerrors.txt testinc2.txt testopen.txt testorder.txt teststyles.txt testsubsload.txt testutils.txt testwsdl.txt travel.txt userdata.txt xhtml1.xsd xhtml_out.txt To run the ARAT tool, get it from svn checkout http://arat.googlecode.com/svn/trunk/ arat, build it with Ant (you just need the JDK and Ant) then run java -jar rat-0.1-SNAPSHOT.jar directory-to-scan. It will produce a report showing the licenses and notices that it finds. Violations are marked with a '!'. The tool incorrectly reports violations on binary files and the INSTALL files which I think are OK (I have not found an Apache project with a license at the top of its INSTALL file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-848) Some files missing the Apache license header
[ http://issues.apache.org/jira/browse/TUSCANY-848?page=all ] Pete Robbins resolved TUSCANY-848. -- Resolution: Fixed Some files missing the Apache license header Key: TUSCANY-848 URL: http://issues.apache.org/jira/browse/TUSCANY-848 Project: Tuscany Issue Type: Bug Components: C++ SCA, C++ SDO Affects Versions: Cpp-M2 Reporter: Jean-Sebastien Delfino Assigned To: Pete Robbins Priority: Blocker Fix For: Cpp-M2 In both the source and bin distributions, the following files are missing the Apache license header: SCA GettingStarted.html and samples/GettingStarted.html. In both SCA and SDO, all the Makefile.am files. In both SCA and SDO, doc/css/maven-base.css and maven-theme.css. SCA xsd/readme.txt. SCA, the two package.html file in scagen.jar. And in the source distributions: In both SCA and SDO configure.ac Under SDO runtime/core/test/ a number of .txt, .xs, .wsdl test files: 48736_xml.txt 48736_xsd.txt StockQuoteService.wsdl b46633.txt b46634_out.txt b47137.txt b47137b.txt b47293.txt b48633_xml.txt b48633b_xsd.txt b48636_xml.txt b48636_xsd.txt b48686_xml.txt b48686_xsd.txt badelement.txt bothgroups_xsd.txt bothgroupssamename_xsd.txt bug2.txt bug45933-output.txt bug48300_xml.txt bug48300_xsd.txt bunique-out.txt bunique-out.xsd_safe.txt bunique-outxml.txt buniqueread-out.txt calculator2.wsdl calculator2a.wsdl carotest3.txt csload-output.txt csload2-output.txt csload3-output.txt cssave-output.txt cssave2-output.txt datetest.txt defaults.txt doctest.txt emptycs1.txt emptycs2.txt emptycs3.txt getproptest.txt groupingroup_xsd.txt grouprefingroup_xsd.txt grouptoolate_xsd.txt groupwithprefix_xsd.txt inc1.txt inc2.txt jira490.txt jira705.xsd jira705_out.txt list1_xml.txt list1_xsd.txt loadload-output.txt maintest.txt matttest1.txt merle1.txt notns.txt nulltest.txt oddchars.txt openloadNSout.txt openseq.txt order1.txt order2.txt querytest.txt saveopen-output.txt scenario1.txt scenario2.txt scenario3.txt scenario4.txt scenario5.txt sequence.txt setmany.txt setnull.txt showdefault1.txt showdefault2.txt simple.txt stock.wsdl stock_wsdl.txt stock_xml.txt testabstract.txt testerrors.txt testinc2.txt testopen.txt testorder.txt teststyles.txt testsubsload.txt testutils.txt testwsdl.txt travel.txt userdata.txt xhtml1.xsd xhtml_out.txt To run the ARAT tool, get it from svn checkout http://arat.googlecode.com/svn/trunk/ arat, build it with Ant (you just need the JDK and Ant) then run java -jar rat-0.1-SNAPSHOT.jar directory-to-scan. It will produce a report showing the licenses and notices that it finds. Violations are marked with a '!'. The tool incorrectly reports violations on binary files and the INSTALL files which I think are OK (I have not found an Apache project with a license at the top of its INSTALL file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Licence headers in test files
We are preparing for a release of Tuscany C++ and have run the aRat tool. This has thrown up some files that are part of our tests that do not include ASL headers. These files are expected output of tests, for example, we serialize a SDO to an xml file and compare the output file with the expected result file to verify the test passed. So... adding licence headers to these files is a bit of a pain as the code would never generate the header as part of it's serialization! So my questions: 1. Do these files require headers? 2. As an alternative, is it ok to add a NOTICE file to the directory containing these files listing them as licenced? If the answers are 1. Yes and 2. No, we will have to do some re-writing of our test verification. Cheers, -- Pete
Re: Licence headers in test files
many thanks for the swift clarification. On 16/10/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 10/16/06, Pete Robbins [EMAIL PROTECTED] wrote: We are preparing for a release of Tuscany C++ and have run the aRat tool. This has thrown up some files that are part of our tests that do not include ASL headers. These files are expected output of tests, for example, we serialize a SDO to an xml file and compare the output file with the expected result file to verify the test passed. So... adding licence headers to these files is a bit of a pain as the code would never generate the header as part of it's serialization! yeh - aRat does raise false positives and the results need interpretation So my questions: 1. Do these files require headers? i regard files containing expected results such as these as binary. 2. As an alternative, is it ok to add a NOTICE file to the directory containing these files listing them as licenced? a README or a NOTICE in the directory is not necessary but would be a good idea. documentation is good and saves having to answer questions about why they don't have a header. if this file is in some reasonable format which RAT could read then they could be automatically marked as binaries and ignored by RAT for the future. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: C++ SCA and SDO M2 Release Candidate 1 now available
Nice one. I'm downloading Windows src and bin and will run through using the doc only. Should be fun ;-) Cheeers, On 12/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi everyone, I have posted candidates for the C++ SCA and SDO M2 release here: http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC1 Please take a look, read the docs, build run the libraries and samples let us know how you find it so that we can either re-spin the release or vote on it asap. The website documentation is currently based on the M1 release and will be re-written to sync with what is in the release. About Tuscany SCA C++ === Tuscany SCA C++ provides a runtime implementation for the for the Service Component Architecture 0.96 Assembly specification and the 0.95 C++ Client Implementation Model specification, written in C++ and will currently support C++, Python and Ruby component implementation types. The specifications can be found at http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications It is possible to interoperate with Tuscany SCA Java via the Web Service bindings for services and references but restrictions apply. This is not yet a complete implementation and known restrictions are described below. Supported SCA Assembly Model features * All features are supported unless listed under the known restrictions below. See SCA Assembly Model specification. Supported language bindings * Component implementations written in C++. See the SCA C++ Client and Implementation Model specification. * Component implementations written in Python. See the doc/PythonExtension.html documentation. * Component implementations written in Python. See the doc/RubyExtension.html documentation. * Component interfaces described by C++ classes. See SCA Client and Implementation Model specification. Supported service and reference bindings * The web service binding is supported. This implementation will support web services which using document literal SOAP bindings conforming to the WS-I basic profile (rpc/encoded is not yet supported). Known restrictions * Local service interfaces cannot use overloaded operations (the SCA specification limits remote service interfaces to not using overloaded operations). * Each WSDL definition for a web service binding must be in a single WSDL document. * No load time validation of the deployed SCA application (run time validation only). * No metadata API. About Tuscany SDO for C++ = Tuscany SDO is an implementation of the Service Data Objects 2.01 specification for C++ developers found at http://www.osoa.org/display/Main/Service+Data+Objects+Specifications - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
[jira] Created: (TUSCANY-837) Issues with Windows M2 RC1 SDO
Issues with Windows M2 RC1 SDO -- Key: TUSCANY-837 URL: http://issues.apache.org/jira/browse/TUSCANY-837 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M2 Environment: Windows Reporter: Pete Robbins Fix For: Cpp-M2 Using this jira to check in updates while testing RC1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-565) Windows Debug build of Calculator sample incorrect
[ http://issues.apache.org/jira/browse/TUSCANY-565?page=all ] Pete Robbins closed TUSCANY-565. Fix Version/s: Cpp-current (was: Cpp-M1) Resolution: Fixed Windows Debug build of Calculator sample incorrect -- Key: TUSCANY-565 URL: http://issues.apache.org/jira/browse/TUSCANY-565 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M1 Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current 1. Debug build on VC6 builds Calc.exe instead of Client.exe 2. deploy.cmd and wsdeploy.cmd copy Release versions of exes 3. VC7 debug builds Client.exe bu Calc.pdb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-566) Debug mode deploy and wsdeploy command files need altering
[ http://issues.apache.org/jira/browse/TUSCANY-566?page=all ] Pete Robbins closed TUSCANY-566. Resolution: Fixed Debug mode deploy and wsdeploy command files need altering -- Key: TUSCANY-566 URL: http://issues.apache.org/jira/browse/TUSCANY-566 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SCA Affects Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current The wsdeploy and deploy command files located in the Calculator directory under samples/ides/devstudio6 and samples/ides/devstudio7 are always copying the Release dll rather than selecting the Debug or Release based on active configuration. This: set buildMode=Release if .Debug == %1. ( set buildMode=Debug ) should be this: set buildMode=Release if Debug. == %1. ( set buildMode=Debug ) (The dot has moved from before Debug to after). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-783) Include CPP, WS, SCA, Python and Ruby extensions in binary releases
[ http://issues.apache.org/jira/browse/TUSCANY-783?page=all ] Pete Robbins resolved TUSCANY-783. -- Fix Version/s: Cpp-current (was: Cpp-M2) Resolution: Fixed Include CPP, WS, SCA, Python and Ruby extensions in binary releases --- Key: TUSCANY-783 URL: http://issues.apache.org/jira/browse/TUSCANY-783 Project: Tuscany Issue Type: Improvement Components: C++ Build, C++ SCA Affects Versions: Cpp-M2 Environment: Windows Linux Reporter: Andrew Borley Assigned To: Pete Robbins Fix For: Cpp-current Binary releases for M2 should contain the CPP, WS, SCA, Python and Ruby extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-91) Replace Tuscany-model.config with import.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-91?page=all ] Pete Robbins closed TUSCANY-91. --- Resolution: Fixed new method of loading wsdl/xsds introduced Replace Tuscany-model.config with import.wsdl --- Key: TUSCANY-91 URL: http://issues.apache.org/jira/browse/TUSCANY-91 Project: Tuscany Issue Type: New Feature Components: C++ SCA Affects Versions: Cpp-current Reporter: Pete Robbins Priority: Minor Fix For: Cpp-current Sync with Java SCA method of defining wsdls -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-500) Failure on use of croncrete complex types in WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-500?page=comments#action_12441407 ] Pete Robbins commented on TUSCANY-500: -- Can you tell us what exactly doesn't work? There are no symptoms explained in the problem description. Failure on use of croncrete complex types in WSDL - Key: TUSCANY-500 URL: http://issues.apache.org/jira/browse/TUSCANY-500 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Fix For: Java-M2 There is something strange happeing in the WSDL based registration of types. When I use an annonymous concrete types in the Big Bank sample, for example xsd:element name=getAccountReport xsd:complexType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:element ... xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The types that are registered are... Type: commonj.sdo#BigDecimal Type: commonj.sdo#BigInteger Type: commonj.sdo#Boolean Type: commonj.sdo#Byte Type: commonj.sdo#Bytes Type: commonj.sdo#ChangeSummary Type: commonj.sdo#Character Type: commonj.sdo#DataObject Type: commonj.sdo#Date Type: commonj.sdo#Double Type: commonj.sdo#Float Type: commonj.sdo#Integer Type: commonj.sdo#Long Type: commonj.sdo#OpenDataObject Type: commonj.sdo#Short Type: commonj.sdo#String Type: commonj.sdo#URI Type: http://www.bigbank.com/AccountService#AccountReport Property: checking type: http://www.bigbank.com/AccountService#CheckingA ccount Property: savings type: http://www.bigbank.com/AccountService#SavingsAcc ount Property: stocks type: http://www.bigbank.com/AccountService#StockAccoun t Type: http://www.bigbank.com/AccountService#CheckingAccount Property: accountNumber type: commonj.sdo#String Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#RootType Property: getAccountReport type: http://www.bigbank.com/AccountService#g etAccountReport Property: getAccountReportResponse type: http://www.bigbank.com/AccountS ervice#getAccountReportResponse Type: http://www.bigbank.com/AccountService#SavingsAccount Property: accountNumber type: commonj.sdo#String Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#StockAccount Property: accountNumber type: commonj.sdo#String Property: symbol type: commonj.sdo#String Property: quantity type: commonj.sdo#Integer Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#customerID Property: customerID type: commonj.sdo#String Type: http://www.bigbank.com/AccountService#getAccountReport Property: customerID type: http://www.bigbank.com/AccountService#custome rID Type: http://www.bigbank.com/AccountService#getAccountReportResponse Property: accountReport type: http://www.bigbank.com/AccountService#Acco untReport Type: http://www.quickstockquote.com/StockQuoteService/#RootType Property: getQuote type: http://www.quickstockquote.com/StockQuoteServic e/#getQuote Property: getQuoteResponse type: http://www.quickstockquote.com/StockQuo teService/#getQuoteResponse Type: http://www.quickstockquote.com/StockQuoteService/#getQuote Property: symbol type: commonj.sdo#String Type: http://www.quickstockquote.com/StockQuoteService/#getQuoteResponse Property: quote type: commonj.sdo#Float and the sample works. If I use a concrete type for the input param instead, for example, xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ Then the types that are registered are Type: commonj.sdo#BigDecimal Type: commonj.sdo#BigInteger Type: commonj.sdo#Boolean Type: commonj.sdo#Byte Type: commonj.sdo#Bytes Type: commonj.sdo#ChangeSummary Type: commonj.sdo#Character Type: commonj.sdo#DataObject Type: commonj.sdo#Date Type: commonj.sdo#Double Type: commonj.sdo#Float Type: commonj.sdo#Integer Type
[jira] Closed: (TUSCANY-509) Big Bank Axis logging loop
[ http://issues.apache.org/jira/browse/TUSCANY-509?page=all ] Pete Robbins closed TUSCANY-509. Resolution: Cannot Reproduce The code around here has changed so I'm closing this. Big Bank Axis logging loop -- Key: TUSCANY-509 URL: http://issues.apache.org/jira/browse/TUSCANY-509 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Fix For: Cpp-current Axis2Client.cpp ln 282 LOGINFO_2 causes and endless loop in the case where the server being called returns an error. I changed this to a LOGINFO, i.e. no var args and carried on. I didn't go back and try it with successful responses. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-556) Investigation of XMLBeans, XBeans etc
[ http://issues.apache.org/jira/browse/TUSCANY-556?page=all ] Pete Robbins closed TUSCANY-556. Resolution: Later This can be discussed on the mailing list. It is not an issue Investigation of XMLBeans, XBeans etc - Key: TUSCANY-556 URL: http://issues.apache.org/jira/browse/TUSCANY-556 Project: Tuscany Issue Type: Wish Components: C++ SCA, C++ SDO Reporter: Ed Slattery Priority: Minor Fix For: Cpp-M1 Find out how they interoperate and whether there is synergy to leverage or interfacing to write. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-792) Update licence text in all source files to latest Apache wording
[ http://issues.apache.org/jira/browse/TUSCANY-792?page=all ] Pete Robbins closed TUSCANY-792. Resolution: Fixed done Update licence text in all source files to latest Apache wording Key: TUSCANY-792 URL: http://issues.apache.org/jira/browse/TUSCANY-792 Project: Tuscany Issue Type: Improvement Components: C++ SCA, C++ SDO Affects Versions: Cpp-M2 Reporter: Andrew Borley Assigned To: Pete Robbins Fix For: Cpp-M2 Done at r452786 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-798) Compile warning in Composite constructor
[ http://issues.apache.org/jira/browse/TUSCANY-798?page=all ] Pete Robbins closed TUSCANY-798. Resolution: Fixed Compile warning in Composite constructor Key: TUSCANY-798 URL: http://issues.apache.org/jira/browse/TUSCANY-798 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows VC6 Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: TUSCANY-798-a.patch, TUSCANY-798.patch Composite constructor passes this to it's super class ComponentType. This gets a compiler warning on VC6 and is, in my opinion, unnecessary. I'm not sure why ComponentType takes a Composite* in it's constructor, it doesn't need it and it is never used! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Leaking libxml memory
Ah yes. I have a fix for this. It is caused by the SDOXMLString::substring
method creating 2 copies of the string and only freeing one of them. this
method is called when parsing the QName string in type=fred:joe so we end
up with an extra fred and joe when this is called.
I will raise a Jira and put the fix in.
Cheers,
On 11/10/06, Caroline Maynard [EMAIL PROTECTED] wrote:
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
?xml version=1.0?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=courses
xsd:complexType
xsd:sequence
xsd:element name=course minOccurs=0
maxOccurs=unbounded
xsd:complexType
xsd:sequence
xsd:element name=title type=xsd:string/
xsd:element name=description
type=xsd:string/
xsd:element name=credits
type=xsd:decimal/
xsd:element name=lastmodified
type=xsd:dateTime minOccurs=1/
/xsd:sequence
xsd:attribute name=cid type=xsd:ID/
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh-defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) ID
1 981 4 malloc() in none(0) xsd
2 971 3 malloc() in none(0) ID
3 968 4 malloc() in none(0) xsd
4 875 9 malloc() in none(0) dateTime
5 872 4 malloc() in none(0) xsd
6 861 9 malloc() in none(0) dateTime
7 858 4 malloc() in none(0) xsd
8 770 8 malloc() in none(0) decimal
9 767 4 malloc() in none(0) xsd
10756 8 malloc() in none(0) decimal
11753 4 malloc() in none(0) xsd
12677 7 malloc() in none(0) string
13674 4 malloc() in none(0) xsd
14663 7 malloc() in none(0) string
15660 4 malloc() in none(0) xsd
16584 7 malloc() in none(0) string
17581 4 malloc() in none(0) xsd
18570 7 malloc() in none(0) string
19567 4 malloc() in none(0) xsd
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
[jira] Commented: (TUSCANY-825) Memory leak in SDOXMLString
[
http://issues.apache.org/jira/browse/TUSCANY-825?page=comments#action_12441458
]
Pete Robbins commented on TUSCANY-825:
--
It is caused by the SDOXMLString::substring method creating 2 copies of the
string and only freeing one of them. this method is called when parsing the
QName string in type=fred:joe so we end up with an extra fred and joe
when this is called.
Memory leak in SDOXMLString
---
Key: TUSCANY-825
URL: http://issues.apache.org/jira/browse/TUSCANY-825
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
Assigned To: Pete Robbins
Fix For: Cpp-current
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
?xml version=1.0?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=courses
xsd:complexType
xsd:sequence
xsd:element name=course minOccurs=0
maxOccurs=unbounded
xsd:complexType
xsd:sequence
xsd:element name=title type=xsd:string/
xsd:element name=description
type=xsd:string/
xsd:element name=credits type=xsd:decimal/
xsd:element name=lastmodified
type=xsd:dateTime minOccurs=1/
/xsd:sequence
xsd:attribute name=cid type=xsd:ID/
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh-defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) ID
1 981 4 malloc() in none(0) xsd
2 971 3 malloc() in none(0) ID
3 968 4 malloc() in none(0) xsd
4 875 9 malloc() in none(0) dateTime
5 872 4 malloc() in none(0) xsd
6 861 9 malloc() in none(0) dateTime
7 858 4 malloc() in none(0) xsd
8 770 8 malloc() in none(0) decimal
9 767 4 malloc() in none(0) xsd
10756 8 malloc() in none(0) decimal
11753 4 malloc() in none(0) xsd
12677 7 malloc() in none(0) string
13674 4 malloc() in none(0) xsd
14663 7 malloc() in none(0) string
15660 4 malloc() in none(0) xsd
16584 7 malloc() in none(0) string
17581 4 malloc() in none(0) xsd
18570 7 malloc() in none(0) string
19567 4 malloc() in none(0) xsd
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-825) Memory leak in SDOXMLString
[ http://issues.apache.org/jira/browse/TUSCANY-825?page=all ]
Pete Robbins resolved TUSCANY-825.
--
Resolution: Fixed
Memory leak in SDOXMLString
---
Key: TUSCANY-825
URL: http://issues.apache.org/jira/browse/TUSCANY-825
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
Assigned To: Pete Robbins
Fix For: Cpp-current
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
?xml version=1.0?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=courses
xsd:complexType
xsd:sequence
xsd:element name=course minOccurs=0
maxOccurs=unbounded
xsd:complexType
xsd:sequence
xsd:element name=title type=xsd:string/
xsd:element name=description
type=xsd:string/
xsd:element name=credits type=xsd:decimal/
xsd:element name=lastmodified
type=xsd:dateTime minOccurs=1/
/xsd:sequence
xsd:attribute name=cid type=xsd:ID/
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh-defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) ID
1 981 4 malloc() in none(0) xsd
2 971 3 malloc() in none(0) ID
3 968 4 malloc() in none(0) xsd
4 875 9 malloc() in none(0) dateTime
5 872 4 malloc() in none(0) xsd
6 861 9 malloc() in none(0) dateTime
7 858 4 malloc() in none(0) xsd
8 770 8 malloc() in none(0) decimal
9 767 4 malloc() in none(0) xsd
10756 8 malloc() in none(0) decimal
11753 4 malloc() in none(0) xsd
12677 7 malloc() in none(0) string
13674 4 malloc() in none(0) xsd
14663 7 malloc() in none(0) string
15660 4 malloc() in none(0) xsd
16584 7 malloc() in none(0) string
17581 4 malloc() in none(0) xsd
18570 7 malloc() in none(0) string
19567 4 malloc() in none(0) xsd
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples
On 11/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 10/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Proxies are generated by the scagen tool. The tool is written in Java and uses an XSL stylesheet to generate the Proxy code. The code for the tool is under under sca/tools/scagen. It has always been working well for me on Redhat Linux. Can you try to run this from the sample.calculator directory: java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . and see if you get any error messages or exceptions? That worked without apparent error, but ... Also which JDK are you using? 1.5.0 as stated in your instructions, but ... I bungled the PATH setting, with the result that the javac command activates the 1.5 compiler, but the JVM is still the 1.4 version. Once I sorted that out the problem went away and the samples build without a problem. Unfortunately, I still can't run scatest.sh successfully. In your instructions it says To run the SCA runtime tests: cd $HOME/tuscany/cpp/sdo ./scatest.sh However, when I do this I get [EMAIL PROTECTED]:~/tuscany/Generic/sca$ ./scatest.sh Using SCA installed at /home/gwinn/tuscany/Generic/sca/deploy Using SDO installed at /home/gwinn/tuscany/Generic/sdo/deploy Using Axis2C installed at /home/gwinn/tuscany/axis2c-bin-0.94-linux ./scatest.sh: line 52: cd: /home/gwinn/tuscany/Generic/sca/deploy/bin/test: No such file or directory ./scatest.sh: line 53: ./tuscany_sca_test: No such file or directory which looks as though something hasn't been built. I also tried scatest no longer exists so I'm not surprised it doesn't run ;- To run the SCA calculator sample: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/bin ./runclient.sh and that doesn't work because the deploy directory doesn't have a bin sub-directory. Is there an extra step in the SCA build process to build the tests? The deployment layout has changed for M2 and the doc you are following is no longer valid. Try: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/sample.calculator.client ./runclient.sh Cheers, -- Pete
Re: [SDO C++] Leaking libxml memory
fixed - http://issues.apache.org/jira/browse/TUSCANY-825
On 11/10/06, Pete Robbins [EMAIL PROTECTED] wrote:
Ah yes. I have a fix for this. It is caused by the SDOXMLString::substring
method creating 2 copies of the string and only freeing one of them. this
method is called when parsing the QName string in type=fred:joe so we end
up with an extra fred and joe when this is called.
I will raise a Jira and put the fix in.
Cheers,
On 11/10/06, Caroline Maynard [EMAIL PROTECTED] wrote:
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
?xml version=1.0?
xsd:schema xmlns:xsd= http://www.w3.org/2001/XMLSchema;
xsd:element name=courses
xsd:complexType
xsd:sequence
xsd:element name=course minOccurs=0
maxOccurs=unbounded
xsd:complexType
xsd:sequence
xsd:element name=title type=xsd:string/
xsd:element name=description
type=xsd:string/
xsd:element name=credits
type=xsd:decimal/
xsd:element name=lastmodified
type=xsd:dateTime minOccurs=1/
/xsd:sequence
xsd:attribute name=cid type=xsd:ID/
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh-defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) ID
1 981 4 malloc() in none(0) xsd
2 971 3 malloc() in none(0) ID
3 968 4 malloc() in none(0) xsd
4 875 9 malloc() in none(0) dateTime
5 872 4 malloc() in none(0) xsd
6 861 9 malloc() in none(0) dateTime
7 858 4 malloc() in none(0) xsd
8 770 8 malloc() in none(0) decimal
9 767 4 malloc() in none(0) xsd
10756 8 malloc() in none(0) decimal
11753 4 malloc() in none(0) xsd
12677 7 malloc() in none(0) string
13674 4 malloc() in none(0) xsd
14663 7 malloc() in none(0) string
15660 4 malloc() in none(0) xsd
16584 7 malloc() in none(0) string
17581 4 malloc() in none(0) xsd
18570 7 malloc() in none(0) string
19567 4 malloc() in none(0) xsd
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
Pete
Re: [C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples
Yes please! On 11/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: OK. I tried invoking ./runclient as described and it tells me that 5 divided by 2 is 2.5 which seems reasonable. Is it worth me posting instructions on how to build on Ubuntu? Geoff. On 11/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 11/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 10/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Proxies are generated by the scagen tool. The tool is written in Java and uses an XSL stylesheet to generate the Proxy code. The code for the tool is under under sca/tools/scagen. It has always been working well for me on Redhat Linux. Can you try to run this from the sample.calculator directory: java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . and see if you get any error messages or exceptions? That worked without apparent error, but ... Also which JDK are you using? 1.5.0 as stated in your instructions, but ... I bungled the PATH setting, with the result that the javac command activates the 1.5 compiler, but the JVM is still the 1.4 version. Once I sorted that out the problem went away and the samples build without a problem. Unfortunately, I still can't run scatest.sh successfully. In your instructions it says To run the SCA runtime tests: cd $HOME/tuscany/cpp/sdo ./scatest.sh However, when I do this I get [EMAIL PROTECTED]:~/tuscany/Generic/sca$ ./scatest.sh Using SCA installed at /home/gwinn/tuscany/Generic/sca/deploy Using SDO installed at /home/gwinn/tuscany/Generic/sdo/deploy Using Axis2C installed at /home/gwinn/tuscany/axis2c-bin-0.94-linux ./scatest.sh: line 52: cd: /home/gwinn/tuscany/Generic/sca/deploy/bin/test: No such file or directory ./scatest.sh: line 53: ./tuscany_sca_test: No such file or directory which looks as though something hasn't been built. I also tried scatest no longer exists so I'm not surprised it doesn't run ;- To run the SCA calculator sample: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/bin ./runclient.sh and that doesn't work because the deploy directory doesn't have a bin sub-directory. Is there an extra step in the SCA build process to build the tests? The deployment layout has changed for M2 and the doc you are following is no longer valid. Try: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/sample.calculator.client ./runclient.sh Cheers, -- Pete -- Pete
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
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 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?
Not quite. DataObjectPtr is easy as it is reference counted
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 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
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++ CI 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
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++ CI 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
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++ CI 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
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++] SDO can't load an XML doc with no namespace
Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=customer type=customerType/ xsd:complexType name=customerType xsd:sequence xsd:any namespace=##other processContents=lax/ /xsd:sequence /xsd:complexType /xsd:schema Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a schemaless xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=customer type=customerType/ xsd:complexType name=customerType xsd:sequence xsd:any namespace=##other processContents=lax/ /xsd:sequence /xsd:complexType /xsd:schema Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
You are assuming the state of the DataFactory that is passed in when loading the xml. XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns clean XML helper with virgin DataFactory XMLDocumentPtr xmlD = xmlH-load(mySchemaless.xml); // your fix would make this work BUT the DataFactory is now frozen XMLDocumentPtr xmlD = xmlH-load(anotherSchemaless.xml); // Bang! - can't add a new open type as DF is frozen I would look at always defining an open type e.g. commonj/sdo#AnyOpenType in a DataFactory. When loading the schemaless xml you create one of these then create the DO's from the xml with this as the root (pseudo-root). The XMLDocument returned would have the first DO defined from the xml as the rootDataObject, not the pseudo-root. Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That is still a separate issue from the one Sebastian raised. Sebastian specifically stated that he did not have an xsd and didn't want one. Loading an XML instance without type information in that situation can be done, via a small xsd file immediately (as a workaround), and via small code change soon. The issue of frozen type systems affects other things besides this one. It needs to be fixed, but it's still a separate question. Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a schemaless xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=customer type=customerType/ xsd:complexType name=customerType xsd:sequence xsd:any namespace=##other processContents=lax/ /xsd:sequence /xsd:complexType /xsd:schema Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported
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
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++ CI 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++] Does ComponentType constructor need Composite* ?
I think we should revert that change I made then but it would be nice to get it to compile on windows ;-) I'm still not happy with Composite constructor passing it's this pointer to it's parent ComponentType. Is this not wrong? Is it saying I am a Composite and I am contained in myself?? In this case is the ComponentType contained in the composite? I think not so instead of passing this to ComponentType constructor maybe 0 would be more appropriate? Am I making sense? Cheers, On 06/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Pete Robbins wrote: Yes it does help! I need to go and read the Assembly spec again ;0) But for now I think the change I put in is fine. Cheers, Pete, I thought that your change was OK too, but I just rebuilt everything after updating from SVN and unfortunately this change breaks the Ruby extension. Sorry I should have detected this before... but line 75 of RubyImplementation.cpp needs the root directory of the composite to find the Ruby script, as most people will specify a path to the script file relative to the .composite file in implementation.ruby script=.../. The Ruby extension hits what I was trying to describe earlier in this thread. Implementation artifacts are packaged with the composite, so they need to know which composite they are packaged in, the current directory etc. The Python and PHP extensions probably do not run into this because they don't look at the script until the first invoke (and are passed the composite at that point), but they will run into this as soon as they try to read and introspect a script earlier in the load sequence. So right now the Ruby extension is broken by this change. To build on Linux without it, use configure --enable-ruby=no. Pete, I tried to find a work around for this problem - so that you wouldn't have to revert some of these changes :) and avoid loading the script up-front, but then realized that I really need to, to introspect it and derive the services and references that will be presented to the other components in the composite for wiring for example. This is way before the first invocation comes or the first ServiceWrapper gets created. Also we can have multiple ServiceWrappers for a single Implementation object and we should load the script only once per Implementation, so I'll recommend that the Python and PHP extension load their scripts as well in the Implementation instead of the ServiceWrapper (but this can wait, we don't need to change that right now). So I don't see any easy way around this... If the other people are OK with that I can live without the Ruby extension for some time until you get to it or we find another solution, but I'm afraid we're going to have to put this Composite* back... Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Does ComponentType constructor need Composite* ?
OK, I'll revert the change. Is there an easy way to do that in svn? Cheers, On 06/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Pete Robbins wrote: I think we should revert that change I made then but it would be nice to get it to compile on windows ;-) I'm still not happy with Composite constructor passing it's this pointer to it's parent ComponentType. Is this not wrong? Is it saying I am a Composite and I am contained in myself?? In this case is the ComponentType contained in the composite? I think not so instead of passing this to ComponentType constructor maybe 0 would be more appropriate? Am I making sense? Cheers, Yes, you're making sense :) Here's a few thoughts: 1) A composite is not contained in itself. 2) The SCA recursive composition, where: composite A contains a component B and component B is an instance of a composite C does not imply containment. In this example composite C is not contained in B. C could be used to create components in other composites D, E, F. C is probably packaged and installed separately from A. 3) On the other hand, somebody could also nest composite C inside composite A, zip A into A.zip and have C inside A.zip... Then we could probably ask the question of containment... As far as I know the SCA spec does not address all the packaging scenarios yet and doesn't cover that. 4) Now a troubling thought (at least it troubles me): A componentType uses interfaces and types, which are normally packaged in the composite containing the componentType. This is easy for componentTypes describing simple implementations (a script, a C++ class etc.). Now a Composite is also a ComponentType, but it uses on its services and references interfaces and types usually packaged in... itself... Given that in most cases it'll need to share these interfaces and types with other composites, there is probably something wrong here, missing in the spec, and obviously missing in our implementations... In doubt, since all these composites are contained in an SCA system, I'd suggest we pass the pointer to the SCA system composite for now. And 0 as you propose will probably work as well :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Does ComponentType constructor need Composite* ?
On 06/10/06, Pete Robbins [EMAIL PROTECTED] wrote: OK, I'll revert the change. Is there an easy way to do that in svn? Cheers, Yes there is using TortoiseSVN ;-) -- Pete
Re: [C++] Does ComponentType constructor need Composite* ?
OK... change made in 798 is backed out and CompositeConstructor passes 0 to it's parent ComponentType. Ruby builds fine now. Cheers, On 06/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 06/10/06, Pete Robbins [EMAIL PROTECTED] wrote: OK, I'll revert the change. Is there an easy way to do that in svn? Cheers, Yes there is using TortoiseSVN ;-) -- Pete -- Pete
[jira] Created: (TUSCANY-798) Compile warning in Composite constructor
Compile warning in Composite constructor Key: TUSCANY-798 URL: http://issues.apache.org/jira/browse/TUSCANY-798 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows VC6 Reporter: Pete Robbins Assigned To: Pete Robbins Composite constructor passes this to it's super class ComponentType. This gets a compiler warning on VC6 and is, in my opinion, unnecessary. I'm not sure why ComponentType takes a Composite* in it's constructor, it doesn't need it and it is never used! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-798) Compile warning in Composite constructor
[ http://issues.apache.org/jira/browse/TUSCANY-798?page=all ] Pete Robbins updated TUSCANY-798: - Attachment: TUSCANY-798.patch This patch removes the Composite* from the ComponetnType constructor. I'll apply it when I can confirm it really isn't needed. Compile warning in Composite constructor Key: TUSCANY-798 URL: http://issues.apache.org/jira/browse/TUSCANY-798 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows VC6 Reporter: Pete Robbins Assigned To: Pete Robbins Attachments: TUSCANY-798.patch Composite constructor passes this to it's super class ComponentType. This gets a compiler warning on VC6 and is, in my opinion, unnecessary. I'm not sure why ComponentType takes a Composite* in it's constructor, it doesn't need it and it is never used! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Does ComponentType constructor need Composite* ?
I think it does not. I raised TUSCANY-798 as I was getting a windows compile warning when Composite constructor was passing it's this pointer to the ComponentType constructor. ComponentType saves away the pointer to a Composite but never uses it, nor is the getComposite() method ever called. My patch attached to the Jira removes the Composite* form the ComponentType constructor and all is well. Looking further into the code there is a method ImplementationExtension::getImplementation(Composite* composite, DataObjectPtr scdlImplementation). The only place that the value composite is ever used is to construct the ComponentType (and this is not needed). I propose to change the extension method signature to ComponentType* getImplementation(DataObjectPtr scdlImplementation) and obviously change the impls of this method in the extensions. Any objections/comments? Cheers, -- Pete
[jira] Updated: (TUSCANY-798) Compile warning in Composite constructor
[ http://issues.apache.org/jira/browse/TUSCANY-798?page=all ] Pete Robbins updated TUSCANY-798: - Attachment: TUSCANY-798-a.patch Here is a complete patch removing Composite* from the getImplementation() calls Compile warning in Composite constructor Key: TUSCANY-798 URL: http://issues.apache.org/jira/browse/TUSCANY-798 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows VC6 Reporter: Pete Robbins Assigned To: Pete Robbins Attachments: TUSCANY-798-a.patch, TUSCANY-798.patch Composite constructor passes this to it's super class ComponentType. This gets a compiler warning on VC6 and is, in my opinion, unnecessary. I'm not sure why ComponentType takes a Composite* in it's constructor, it doesn't need it and it is never used! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Does ComponentType constructor need Composite* ?
I attached a patch of my proposed fix to the Jira On 05/10/06, Pete Robbins [EMAIL PROTECTED] wrote: I think it does not. I raised TUSCANY-798 as I was getting a windows compile warning when Composite constructor was passing it's this pointer to the ComponentType constructor. ComponentType saves away the pointer to a Composite but never uses it, nor is the getComposite() method ever called. My patch attached to the Jira removes the Composite* form the ComponentType constructor and all is well. Looking further into the code there is a method ImplementationExtension::getImplementation(Composite* composite, DataObjectPtr scdlImplementation). The only place that the value composite is ever used is to construct the ComponentType (and this is not needed). I propose to change the extension method signature to ComponentType* getImplementation(DataObjectPtr scdlImplementation) and obviously change the impls of this method in the extensions. Any objections/comments? Cheers, -- Pete -- Pete
Re: [C++] A name for M2
package-1.0-incubator-M2 looks good for me. On 05/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi everyone, We need to choose a full name for the forthcoming release, so I've put a few suggestions below - any favourite? So far we've been referring to this release as M2 or Milestone 2 so all the suggestions below have M2 in them. We don't have the Maven restriction to start with a number, but we may want to follow the Java naming for M2 (1.0-incubator-M2), alternatively we could follow the names from the first C++ release: tuscany_sca_cpp- 0.1.incubating-M1 and tuscany_sdo_cpp-0.1.incubating-M1 Some alternatives are: tuscany_sca_cpp-1.0-incubator-M2 tuscany_sca_cpp-0.1.incubating-M2 tuscany_sca_cpp-0.2.incubating-M2 Any preferences/better ideas? Mine would be the first in the list to show that we are at a similar level to the Java side ;-). Cheers Andy -- Pete
Re: [C++] Does ComponentType constructor need Composite* ?
On 05/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I thought that a ComponentType would need to know the composite it lives in, to reflect interfaces, or use complex data types for properties, which are currently packaged with a composite. But in the model Composite is a subclass of ComponentType and you say a ComponentType lives in a Composite? If so I think the model is wrong. Do we need a review of the model. I have to say I haven't looked into it in detail ... as it worked ;-) Cheers, -- Pete
Re: [C++] BigBank sample updated
+1 to using string, char* is so 80's ;-) On 05/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: Hi, I've updated the BigBank sample today to get it working on windows based on the new directory and deployment structure. One thing I had to do to get it all working was change all the component interfaces from using char* strings to std::string, as the changes to the binding.ws service and reference stuff that went in for r449433 means that using char* strings causes a crash. Was this the desired effect of the change? Do we want users to only use std::string in their component interfaces? Is there a way to accomodate both std::string and char*? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I guess r449433 introduced that bug, that was not the intent. I didn't see the bug on Linux but that may have been an oversight. I'm trying to wrap-up the changes to remove the requirement for the packages/ and configuration/ folders (and it's taking a little longer because my initial stab at this didn't go quite right). I'll take a look just after that. Independent of this bug, I like how you changed Bigbank to use std::strings (more convenient than char* to work with) so what do you guys think about keeping the std::strings in Bigbank even after the bug is fixed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Does ComponentType constructor need Composite* ?
Yes it does help! I need to go and read the Assembly spec again ;0) But for now I think the change I put in is fine. Cheers, On 05/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: On 05/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I thought that a ComponentType would need to know the composite it lives in, to reflect interfaces, or use complex data types for properties, which are currently packaged with a composite. But in the model Composite is a subclass of ComponentType and you say a ComponentType lives in a Composite? If so I think the model is wrong. Do we need a review of the model. I have to say I haven't looked into it in detail ... as it worked ;-) Cheers, Pete, OK I think I need to clarify what I meant by lives in a Composite. Let's look at this from multiple angles: A) A composite describes a type. A composite can be used as an implementation of a component. A composite declares service types, reference types, property types. So I think it is correct for Composite to extend ComponentType in the model. B) Let's now look at a .componentType file. The .componentType file is currently packaged with the other artifacts contributing to a Composite. The ComponentType references WSDLs, XSDs, possibly other language artifacts declaring types, in its interface and property definitions. These artifacts are also currently packaged with the Composite. The WSDL and XSD metadata (and the corresponding DataFactory) are associated with (live in) the Composite. That's what I meant with a ComponentType lives in a Composite. C) A variation on B: a ComponentType can be derived from a component implementation artifact (a Ruby script, a Python script, a C++ class if we add annotations to C++ at some point etc.). These implementation artifacts are currently packaged with a Composite so by derivation the ComponentType describing them belongs to the Composite as well. I think that we should discuss whether or not it's a good thing to use Composites as a packaging mechanism for implementation artifacts and type metadata. I have in mind some scenarios where multiple composites need to reuse a simple component implementation packaged and installed independently from these composites... Other even more obvious scenarios (like SupplyChain) need to share WSDL files, types and interfaces between composites... But I think all of this is a different, bigger and longer term subject, which will require some clarifications in the SCA spec and interesting work in perspective for our M3 release I guess :) Does that help? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
[jira] Closed: (TUSCANY-779) Update to new Apache Licence text
[ http://issues.apache.org/jira/browse/TUSCANY-779?page=all ] Pete Robbins closed TUSCANY-779. Fix Version/s: Cpp-M1 Resolution: Fixed Done! Update to new Apache Licence text - Key: TUSCANY-779 URL: http://issues.apache.org/jira/browse/TUSCANY-779 Project: Tuscany Issue Type: New Feature Components: C++ SCA, C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-M1 Text in all src files to be updated to the new Apache wording -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-796) SCA C++ build fails on VC++ 6
[ http://issues.apache.org/jira/browse/TUSCANY-796?page=all ] Pete Robbins reassigned TUSCANY-796: Assignee: Pete Robbins SCA C++ build fails on VC++ 6 - Key: TUSCANY-796 URL: http://issues.apache.org/jira/browse/TUSCANY-796 Project: Tuscany Issue Type: Bug Components: C++ Build Affects Versions: Cpp-M1 Environment: Windows XP Professional SP2 Reporter: Krishna Guda Assigned To: Pete Robbins Fails as below. Linking... Creating library Debug/tuscany_sca.lib and object Debug/tuscany_sca.exp ModelLoader.obj : error LNK2001: unresolved external symbol public: __thiscall tuscany::sca::model::WSDLInterface::WSDLInterface(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,bool,bool) (??0WSDLInt [EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) ModelLoader.obj : error LNK2001: unresolved external symbol public: static class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const tuscany::sca::model::WSDLInterface::typeQName ([EMAIL PROTECTED]@model@ [EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@B) Debug/tuscany_sca.dll : fatal error LNK1120: 2 unresolved externals Error executing link.exe. tuscany_sca.dll - 3 error(s), 1 warning(s) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-796) SCA C++ build fails on VC++ 6
[ http://issues.apache.org/jira/browse/TUSCANY-796?page=comments#action_12439831 ] Pete Robbins commented on TUSCANY-796: -- I am in the process of fixing up the build on VC6. The build projects/makefiles have not been updated since we restructured the code and developers have been using VC7.1 projects. SCA C++ build fails on VC++ 6 - Key: TUSCANY-796 URL: http://issues.apache.org/jira/browse/TUSCANY-796 Project: Tuscany Issue Type: Bug Components: C++ Build Affects Versions: Cpp-M1 Environment: Windows XP Professional SP2 Reporter: Krishna Guda Assigned To: Pete Robbins Fails as below. Linking... Creating library Debug/tuscany_sca.lib and object Debug/tuscany_sca.exp ModelLoader.obj : error LNK2001: unresolved external symbol public: __thiscall tuscany::sca::model::WSDLInterface::WSDLInterface(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,bool,bool) (??0WSDLInt [EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) ModelLoader.obj : error LNK2001: unresolved external symbol public: static class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const tuscany::sca::model::WSDLInterface::typeQName ([EMAIL PROTECTED]@model@ [EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@B) Debug/tuscany_sca.dll : fatal error LNK1120: 2 unresolved externals Error executing link.exe. tuscany_sca.dll - 3 error(s), 1 warning(s) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
[ http://issues.apache.org/jira/browse/TUSCANY-719?page=all ]
Pete Robbins reassigned TUSCANY-719:
Assignee: Pete Robbins
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Assigned To: Pete Robbins
Priority: Minor
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
[ http://issues.apache.org/jira/browse/TUSCANY-719?page=all ]
Pete Robbins resolved TUSCANY-719.
--
Fix Version/s: Cpp-current
Resolution: Fixed
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Assigned To: Pete Robbins
Priority: Minor
Fix For: Cpp-current
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-614) Add operator debug info for DataObjectPtr and others
[ http://issues.apache.org/jira/browse/TUSCANY-614?page=all ] Pete Robbins closed TUSCANY-614. Fix Version/s: Cpp-current Resolution: Fixed Add operator debug info for DataObjectPtr and others -- Key: TUSCANY-614 URL: http://issues.apache.org/jira/browse/TUSCANY-614 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current There is an SDOUTils function to print out the contents of a DataObject. This proposal is to add ostream operator to RefCountingPointer that will call a virtual function printSelf() on RefCountingObject. Anything inheriting from RefCountingObject (e.g. DataObject) can overide this method to provide diagnostic info. User simply has to code e.g. DatObjectPtr myDO = someFucntionThatReturnsDO(); cout myDO; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-431) XSDHelper does not always create a DataFactory
[ http://issues.apache.org/jira/browse/TUSCANY-431?page=all ] Pete Robbins closed TUSCANY-431. XSDHelper does not always create a DataFactory -- Key: TUSCANY-431 URL: http://issues.apache.org/jira/browse/TUSCANY-431 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current It is possible to construct an XSDHelper which does not contain a DataFactory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-448) ElementWithSDOName fails on write
[ http://issues.apache.org/jira/browse/TUSCANY-448?page=all ] Pete Robbins closed TUSCANY-448. ElementWithSDOName fails on write - Key: TUSCANY-448 URL: http://issues.apache.org/jira/browse/TUSCANY-448 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Fix For: Cpp-current Reading ElementWithSDONameElementWithSDOName/ElementWithSDOName against schema element name=ElementWithSDOName sdo:name=ElementWithSDONameSDOName type=string/ and writing out again gives rise to a runtime failure -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-211) MSVC build failure
[ http://issues.apache.org/jira/browse/TUSCANY-211?page=all ] Pete Robbins closed TUSCANY-211. MSVC build failure -- Key: TUSCANY-211 URL: http://issues.apache.org/jira/browse/TUSCANY-211 Project: Tuscany Issue Type: Bug Components: C++ SDO Environment: MSVC 7.0 Reporter: Simon Laws Assigned To: Pete Robbins Priority: Minor Link failure. Add: GroupEvent.cpp GroupDefinition.cpp to the sdo_runtime project and utils.cpp main.cpp to the sdo_test project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-426) Null pointer exception loading schema with ref to already defined type
[ http://issues.apache.org/jira/browse/TUSCANY-426?page=all ] Pete Robbins closed TUSCANY-426. Null pointer exception loading schema with ref to already defined type -- Key: TUSCANY-426 URL: http://issues.apache.org/jira/browse/TUSCANY-426 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Bug in XSDHelperImpl handling reference to type not being defined in this pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-305) Test data files are confusingly located
[ http://issues.apache.org/jira/browse/TUSCANY-305?page=all ] Pete Robbins closed TUSCANY-305. Test data files are confusingly located --- Key: TUSCANY-305 URL: http://issues.apache.org/jira/browse/TUSCANY-305 Project: Tuscany Issue Type: Improvement Components: C++ SDO Environment: Microsoft Visual Studio V7.1 running on Windows XP Reporter: Geoff Winn Assigned To: Ed Slattery Priority: Minor Attachments: TUSCANY-305.patch The build_instructions.txt file includes the following paragraph. The test project runs in the projects directory, where in C6 it ran in the Debug directory, so all the test comparison files are in the wrong place. You can copy the entire contents of runtime/core/test/Debug to projects/tuscany_sdo/sdo_test The directory paths quoted are slightly inaccurate and the attached patch corrects this text. However, more seriously, the directory structure that contains the test data files is more complicated than this paragraph suggests and a simple copy isn't sufficient. There are two exceptions. 1. The sdo_test program at one point looks for ..\test\test\include3.xsd. To comply with that, it is necessary to create a new test directory as a sibling of tuscany\cpp\sdo\projects\tuscany_sdo\sdo_runtime and then copy the test directory from tuscany\cpp\sdo\runtime\core\test into that newly created directory. 2. The sdo_test program also looks for ..\test2\includeother3.xsd To comply with that, it is necessary to copy the test2 directory from tuscany\cpp\sdo\runtime\core\test to be another sibling of tuscany\cpp\sdo\projects\tuscany_sdo\sdo_runtime ie one level higher than you get if you follow the simple copy instruction. These latter two points could also be recorded in the build_instructions.txt file, but it might be better in the long term to re-arrange the test data so that it doesn't use such intricate paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-455) patch for tuscany-443 using inline functions will not compile/work on Linux
[ http://issues.apache.org/jira/browse/TUSCANY-455?page=all ] Pete Robbins closed TUSCANY-455. patch for tuscany-443 using inline functions will not compile/work on Linux --- Key: TUSCANY-455 URL: http://issues.apache.org/jira/browse/TUSCANY-455 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Priority: Blocker Fix For: Cpp-current The methods in SDOString defined as inline in the .cpp are not accessable from another library/exe. This can work on Windows as there is an MS only way of exporting the function using dllexport. You can inline the functions by defining the methods in the class declaration in the header file. Please build ALL changes on Linux as well as Windows -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-553) Add a static null SDOString to the SDOString class
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ] Pete Robbins closed TUSCANY-553. Add a static null SDOString to the SDOString class -- Key: TUSCANY-553 URL: http://issues.apache.org/jira/browse/TUSCANY-553 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows and Linux Reporter: Geoff Winn Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-553.patch It is frequently necessary to create null strings as default parameters or to represent enmpty return values. Where these values are read only they can be references to a single class static. Add this static to the class for later use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-539) [SDO for C++] Augment client interface with methods taking SDOString parameters. Part 1
[ http://issues.apache.org/jira/browse/TUSCANY-539?page=all ] Pete Robbins closed TUSCANY-539. [SDO for C++] Augment client interface with methods taking SDOString parameters. Part 1 --- Key: TUSCANY-539 URL: http://issues.apache.org/jira/browse/TUSCANY-539 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows and Linux Reporter: Geoff Winn Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-539.patch Continuing the process of migrating SDO to use C++ style strings. Add methods that take const SDOString parameters to supplement the ones that take const char* parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-603) Attributes specified in xml instance doc are not validated against the schema definition
[ http://issues.apache.org/jira/browse/TUSCANY-603?page=all ] Pete Robbins closed TUSCANY-603. Attributes specified in xml instance doc are not validated against the schema definition Key: TUSCANY-603 URL: http://issues.apache.org/jira/browse/TUSCANY-603 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current When an instance document is loaded attributes on a type are set as attributes even if the schema specifies that the property is an element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-511) Big Bank memory error
[ http://issues.apache.org/jira/browse/TUSCANY-511?page=all ]
Pete Robbins closed TUSCANY-511.
Big Bank memory error
-
Key: TUSCANY-511
URL: http://issues.apache.org/jira/browse/TUSCANY-511
Project: Tuscany
Issue Type: Bug
Components: C++ SCA
Affects Versions: Cpp-current
Environment: Windows XP
Reporter: Simon Laws
Get memory error in the final leg of the big bank scneario. Was solved
temoprarily bu commenting the follwong out.
Axis2Client.cpp ln 149
/*
if (svc_client)
{
AXIS2_SVC_CLIENT_FREE(svc_client, env);
svc_client = NULL;
}
*/
Needs futher detailed investigation to determine if this is causing memory
corruption of something else is by, for example, freeing something twice
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-697) [C++ for SDO] Add remaining methods taking SDOString args rather than char*
[ http://issues.apache.org/jira/browse/TUSCANY-697?page=all ] Pete Robbins closed TUSCANY-697. [C++ for SDO] Add remaining methods taking SDOString args rather than char* --- Key: TUSCANY-697 URL: http://issues.apache.org/jira/browse/TUSCANY-697 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: All Reporter: Geoff Winn Fix For: Cpp-current Attachments: TUSCANY-697.patch This fix provides all the remaining methods that take SDOString arguments rather than char* arguments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-691) Paramater name interface appearc in the code which upsets VC7 2002
[ http://issues.apache.org/jira/browse/TUSCANY-691?page=all ] Pete Robbins closed TUSCANY-691. Paramater name interface appearc in the code which upsets VC7 2002 Key: TUSCANY-691 URL: http://issues.apache.org/jira/browse/TUSCANY-691 Project: Tuscany Issue Type: Bug Components: C++ SCA Environment: XP MSVC7 2002 Reporter: Simon Laws Assigned To: Andrew Borley Priority: Minor Fix For: Cpp-current Attachments: scamodelvc7patch.txt Changes interface to anInterface -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-508) Big Bank GetQute signature
[ http://issues.apache.org/jira/browse/TUSCANY-508?page=all ] Pete Robbins closed TUSCANY-508. Big Bank GetQute signature -- Key: TUSCANY-508 URL: http://issues.apache.org/jira/browse/TUSCANY-508 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws ChangedGetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp and associated StockQuoteExternal files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-510) Big Bank getQuote return type error
[ http://issues.apache.org/jira/browse/TUSCANY-510?page=all ] Pete Robbins closed TUSCANY-510. Big Bank getQuote return type error --- Key: TUSCANY-510 URL: http://issues.apache.org/jira/browse/TUSCANY-510 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: windows XP Reporter: Simon Laws StockQuoteExternalService.h/StockQuoteServiceImpl.cpp has incorrect return type for getQuote const char * should be float. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-486) Document deployment use of Axis2C WS EntryPoint
[ http://issues.apache.org/jira/browse/TUSCANY-486?page=all ] Pete Robbins closed TUSCANY-486. Document deployment use of Axis2C WS EntryPoint - Key: TUSCANY-486 URL: http://issues.apache.org/jira/browse/TUSCANY-486 Project: Tuscany Issue Type: Task Components: C++ SCA Affects Versions: Cpp-M1 Reporter: Andrew Borley Assigned To: Pete Robbins Fix For: Cpp-current Attachments: TUSCANY-486.patch, WS_ENTRYPOINT.txt Need documentation explaining how to expose an SCA component as a WS EntryPoint in Axis2C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-473) Exception thrown when serializing an element defined with sdo:name
[ http://issues.apache.org/jira/browse/TUSCANY-473?page=all ] Pete Robbins closed TUSCANY-473. Exception thrown when serializing an element defined with sdo:name -- Key: TUSCANY-473 URL: http://issues.apache.org/jira/browse/TUSCANY-473 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attempting to serialise the source.uri element from an sca.module file we get a Property not found exception thrown for source.uri this element has been renamed in the xsd using sdo:name=sourceURI so the serialization code should not be using the name source.uri. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-759) XPath test failure with compound queries
[ http://issues.apache.org/jira/browse/TUSCANY-759?page=all ] Pete Robbins closed TUSCANY-759. XPath test failure with compound queries Key: TUSCANY-759 URL: http://issues.apache.org/jira/browse/TUSCANY-759 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP 5.1.6, WinXP Reporter: Caroline Maynard Assigned To: Pete Robbins Fix For: Cpp-current Part of the SDO for PHP core unit tests uses a standard company-departments[]-employees[] model and tests Xpath expressions. All these tests worked with Tuscany C++ SDO revision level 431903. I recently ran them with 436761 and there was a failure. I then reverted to 433676 and the tests were successful. It's possible that the Tuscany-539 fix was the culprit. The failing test is attempting to read company[departments[name='ShoeDept']/employees[name='Jane Smith']] The values for name are both valid, but in the failing revision level an exception was thrown with the message Invalid path: followed by the xpath above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-764) Replace SDOString with std::string
[ http://issues.apache.org/jira/browse/TUSCANY-764?page=all ] Pete Robbins closed TUSCANY-764. Replace SDOString with std::string -- Key: TUSCANY-764 URL: http://issues.apache.org/jira/browse/TUSCANY-764 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: SDOString.patch, TUSCANY-764.patch SDOString is unnecessary and adds no function over std::string I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-506) Sequenced Open types are not being loaded via the sequence interface
[ http://issues.apache.org/jira/browse/TUSCANY-506?page=all ] Pete Robbins closed TUSCANY-506. Sequenced Open types are not being loaded via the sequence interface Key: TUSCANY-506 URL: http://issues.apache.org/jira/browse/TUSCANY-506 Project: Tuscany Issue Type: Bug Components: C++ SDO Environment: all Reporter: Ed Slattery Assigned To: Ed Slattery The parser used the dataObject interface to load open types, even if sequenced, so sometimes the sequence of the object doesnt contain the full list of properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-644) Choice group with duplicate element names in XSD schema leads to duplication of output from SDO
[ http://issues.apache.org/jira/browse/TUSCANY-644?page=all ] Pete Robbins closed TUSCANY-644. Choice group with duplicate element names in XSD schema leads to duplication of output from SDO --- Key: TUSCANY-644 URL: http://issues.apache.org/jira/browse/TUSCANY-644 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Assigned To: Pete Robbins Fix For: Cpp-current A PHP SDO user raised a bug (http://pecl.php.net/bugs/bug.php?id=8493) to the effect that having read the XSD for WSDL1.1 and having created operation data objects with input and output properties these properties are duplicated when the SDO is written out to XML. The symtom is caused because the WSDL schema in question contains a choice group that repeats elements of the same name but just in a different order (to represent different calling conventions in this case). SDO flattens the choice but for some reasone fails to spot the duplicate type names and hence the resulting data object property list has multiple properties of the same name. This is not good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-698) First pass PHP extension for C++ SCA
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ] Pete Robbins closed TUSCANY-698. First pass PHP extension for C++ SCA Key: TUSCANY-698 URL: http://issues.apache.org/jira/browse/TUSCANY-698 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-current Environment: XP Reporter: Simon Laws Assigned To: Jean-Sebastien Delfino Priority: Minor Attachments: phpextension1patch.txt, phpextensioncalculatorchangespatch.txt A first pass at an extension for the PHP scripting language. This follows the pattern layed down by Andy with the Python extension and has many limitations: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functionsimplementation.php module=DivideServiceImpl/ When the script has classes and functions implementation.php module=DivideServiceImpl class=DivideClass/ In the longer term though I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven;t included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-705) XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true
[ http://issues.apache.org/jira/browse/TUSCANY-705?page=all ] Pete Robbins closed TUSCANY-705. XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true --- Key: TUSCANY-705 URL: http://issues.apache.org/jira/browse/TUSCANY-705 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: WinXP Reporter: Caroline Maynard Priority: Critical Fix For: Cpp-current Attachments: bug8506.patch, bug8506.patch, TUSCANY-705-pr.patch, TUSCANY-705.patch See http://pecl.php.net/bugs/bug.php?id=8506 for the test example. The schema is: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=http://ConvertedStockQuote; xs:element name=getQuote xs:complexType xs:sequence xs:element name=ticker type=xs:string nillable=true/ /xs:sequence /xs:complexType /xs:element /xs:schema When the ticker element's value is not nil, the output is: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; tickerIBM/ticker /getQuote but when it is nil, my user gets: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; getQuote xmlns=http://ConvertedStockQuote; xsi:nil=true/ /getQuote I've attached a proposed patch. I removed the namespace URI to be consistent with the non-nil case, apologies if this is incorrect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-561) SDO Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-561?page=all ] Pete Robbins closed TUSCANY-561. SDO Sample build.cmd cannot find mspdb71.dll Key: TUSCANY-561 URL: http://issues.apache.org/jira/browse/TUSCANY-561 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SDO Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-561.patch SDO Sample build.cmd needs to call vcvars32 to set up the build environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-490) DataObjectPtr::getByte returns incorrect data
[ http://issues.apache.org/jira/browse/TUSCANY-490?page=all ]
Pete Robbins closed TUSCANY-490.
DataObjectPtr::getByte returns incorrect data
-
Key: TUSCANY-490
URL: http://issues.apache.org/jira/browse/TUSCANY-490
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Andrew Borley
Priority: Minor
Fix For: Cpp-current
Attachments: TUSCANY-490.patch
Some xml like byte123/byte where the byte element contains an xsd:byte
type, is converted into a DataObject and then queried.
// returns the correct data: 123
const char* cs = myDataObjectPtr-getCString(byte);
// Returns incorrect data: '1' (Ox31) - looks like it's just taking the
first character, rather than converting 123 to the character '{' (Ox7B)
char c = myDataObjectPtr-getByte(byte);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-587) WSDL XSD is read incorrectly.
[ http://issues.apache.org/jira/browse/TUSCANY-587?page=all ] Pete Robbins closed TUSCANY-587. WSDL XSD is read incorrectly. - Key: TUSCANY-587 URL: http://issues.apache.org/jira/browse/TUSCANY-587 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: All platforms Reporter: Geoff Winn Assigned To: Pete Robbins Fix For: Cpp-current When SDO for C++ reads the WSDL XSD (http://scemas.xmlsoap.org/wsdl/2003-02-11.xsd) some properties that are in fact many valued are identified in the internal model as single valued. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-501) Crash on SDOTypeNotFound exception
[ http://issues.apache.org/jira/browse/TUSCANY-501?page=all ] Pete Robbins closed TUSCANY-501. Crash on SDOTypeNotFound exception -- Key: TUSCANY-501 URL: http://issues.apache.org/jira/browse/TUSCANY-501 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Fix For: Cpp-current Attachments: TUSCANY-501.patch When SDOTypeNotFound is thrown the runtime crashes rather than reporting the error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-604) Exception thrown when sequenced type inherits from non-sequenced type
[ http://issues.apache.org/jira/browse/TUSCANY-604?page=all ] Pete Robbins closed TUSCANY-604. Exception thrown when sequenced type inherits from non-sequenced type - Key: TUSCANY-604 URL: http://issues.apache.org/jira/browse/TUSCANY-604 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current The SDO spec states that the isSequenced should be the same on a base type and it's descendents. In the C++ implementation an exception is thrown when e.g. a sequenced type extends a non-sequenced type. This prevents schema such as the wsdl schema(http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd) being loaded. In the current Java implementation isSequenced is inherited from the base type, we should do the same in the C++ implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-613) Move to 0.95 spec Assembly model
[ http://issues.apache.org/jira/browse/TUSCANY-613?page=all ] Pete Robbins closed TUSCANY-613. Resolution: Fixed Move to 0.95 spec Assembly model Key: TUSCANY-613 URL: http://issues.apache.org/jira/browse/TUSCANY-613 Project: Tuscany Issue Type: New Feature Components: C++ SCA Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: TUSCANY-613-2.patch, TUSCANY-613.patch To cover work for composites etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-779) Update to new Apache Licence text
Update to new Apache Licence text - Key: TUSCANY-779 URL: http://issues.apache.org/jira/browse/TUSCANY-779 Project: Tuscany Issue Type: New Feature Components: C++ SCA, C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Text in all src files to be updated to the new Apache wording -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++][SDO] Use of std::string
So, does anyone have any objection if I check in the updates to typedef SDOString as std::string? -- Pete
Re: [C++][SDO] Use of std::string
There are certainly some fixes already in SDO that are required by SCA so we will need to cut an SDO release as well. We may as wqell try to do this at the same time as SCA. We need to go through the SDO Jiras and prioritise them. Cheers, On 02/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Not me! On a releated note - is there any particular functionality or big fixes that would be good to get into M2 for SDO? We have a good list for SCA, but not much for SDO. Cheers Andy On 10/2/06, Pete Robbins [EMAIL PROTECTED] wrote: So, does anyone have any objection if I check in the updates to typedef SDOString as std::string? -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++][SDO] Use of std::string
On 02/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I'd like to get support for stdcxx in the Linux build as it already is in the XP one. I'm planning to review the JIRA list this week to see what's urgent or blocking other people. Thanks Geoff, that would be great! Cheers, -- Pete
[jira] Resolved: (TUSCANY-764) Replace SDOString with std::string
[ http://issues.apache.org/jira/browse/TUSCANY-764?page=all ] Pete Robbins resolved TUSCANY-764. -- Resolution: Fixed Replace SDOString with std::string -- Key: TUSCANY-764 URL: http://issues.apache.org/jira/browse/TUSCANY-764 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: SDOString.patch, TUSCANY-764.patch SDOString is unnecessary and adds no function over std::string I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Simplifying the deployment structure for our samples
No objections here. I always wanted ModelLoader to find all artifacts under root ;-) Cheers, On 02/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I'd like to simplify a little the deployment folder structure of our samples. The folder structure created by our build under deploy/ is currently different from the source development structure and I think it'll be simpler if in general we can just use the same structure for both, as this will allow people to run their code in place without having to move things around and will improve the code/build/run user experience. Here's what we have now: Source development tree: . ./sample.calculator.solution ./sample.calculator.solution/sample.calculator.solution.composite ./README ./sample.calculator.wsclient ./sample.calculator.wsclient/axis2_Calculator_stub.cpp ./sample.calculator.wsclient/CalculatorWSClient.cpp ./sample.calculator.wsclient/axis2_Calculator_stub.h ./sample.calculator.wsclient/runwsclient.sh ./sample.calculator.wsclient/runwsclient.bat ./sample.calculator.wsclient/Makefile.am ./sample.calculator ./sample.calculator/Calculator.wsdl ./sample.calculator/CalculatorImpl.h ./sample.calculator/Calculator.h ./sample.calculator/DivideImpl.h ./sample.calculator/runwsserver.bat ./sample.calculator/runwsserver.sh ./sample.calculator/sample.calculator.composite ./sample.calculator/CalculatorImpl.componentType ./sample.calculator/DivideImpl.componentType ./sample.calculator/DivideImpl.cpp ./sample.calculator/Divide.h ./sample.calculator/Makefile.am ./sample.calculator/CalculatorImpl.cpp ./Makefile.am ./sample.calculator.client ./sample.calculator.client/Calculator.h ./sample.calculator.client/runclient.bat ./sample.calculator.client/runclient.sh ./sample.calculator.client/calculator_client ./sample.calculator.client/CalculatorClient.cpp ./sample.calculator.client/Makefile.am Structure currently created by our build under deploy/: . ./configuration ./configuration/sample.calculator.solution.composite ./bin ./bin/runclient.sh ./bin/runwsserver.sh ./bin/calculator_client ./bin/runwsclient.sh ./bin/calculator_wsclient ./packages ./packages/sample.calculator ./packages/sample.calculator/Calculator.wsdl ./packages/sample.calculator/libCalculator.so.0.0.0 ./packages/sample.calculator/sample.calculator.composite ./packages/sample.calculator/CalculatorImpl.componentType ./packages/sample.calculator/libCalculator.so ./packages/sample.calculator/DivideImpl.componentType ./packages/sample.calculator/libCalculator.la ./packages/sample.calculator/libCalculator.so.0 And here's the new structure under deploy/ with the changes that I'm proposing (basically the same structure as the source development tree): . ./sample.calculator.solution ./sample.calculator.solution/sample.calculator.solution.composite ./README ./sample.calculator.wsclient ./sample.calculator.wsclient/runwsclient.sh ./sample.calculator.wsclient/calculator_wsclient ./sample.calculator ./sample.calculator/Calculator.wsdl ./sample.calculator/libCalculator.so.0.0.0 ./sample.calculator/sample.calculator.composite ./sample.calculator/CalculatorImpl.componentType ./sample.calculator/libCalculator.so ./sample.calculator/DivideImpl.componentType ./sample.calculator/libCalculator.la ./sample.calculator/libCalculator.so.0 ./sample.calculator/runwsserver.sh ./sample.calculator.client ./sample.calculator.client/runclient.sh ./sample.calculator.client/calculator_client In addition to the build changes, to support this new structure we have to make a small change to our ModelLoader to look for artifacts directly under $Tuscany_scacpp_system_root instead of just the packages/ and configuration/ sub-folders. If there's no objection I'd like to start making these changes some time tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 Release
Andy, I'll do the change to the new licence text (hopefully tomorrow). Should we have an IRC chat to prioritise outstanding items and Jiras? Is is good to raise Jiras for all the work items such as doc etc so we can track what get checked in from now up to the release. If we are trying to close down for a release we should only be checking in for items that we need for the release. Cheers, On 02/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, I think it would be good if we could get our first release candidate cut by or during ApacheCon (which is next week!) - do people think that is possible? With this in mind I propose we concentrate on the higher priority stuff, which to my mind is documentation, samples, build requirements (licencing, build files, etc), the PHP extension and the support for a particular spec level. Do people agree with this? Is there some particular functionality/bug fix that should go in? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
[C++][SDO] Use of std::string
I've been playing around tidying up some of the SDO code where we have methods implemented that take parameters as char* and SDOString (See latest DataObjectImpl changes). I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- Pete
[jira] Created: (TUSCANY-764) Replace SDOString with std::string
Replace SDOString with std::string -- Key: TUSCANY-764 URL: http://issues.apache.org/jira/browse/TUSCANY-764 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: SDOString.patch SDOString is unnecessary and adds no function over std::string I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++][SDO] Use of std::string
I've opened Jira 764 and have attached a patch that typedefs SDOString to std::string Cheers, On 29/09/06, Pete Robbins [EMAIL PROTECTED] wrote: I've been playing around tidying up some of the SDO code where we have methods implemented that take parameters as char* and SDOString (See latest DataObjectImpl changes). I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- Pete -- Pete
[jira] Commented: (TUSCANY-764) Replace SDOString with std::string
[ http://issues.apache.org/jira/browse/TUSCANY-764?page=comments#action_12438734 ] Pete Robbins commented on TUSCANY-764: -- In addition to the patch for Linux you need to delete the line SDOString.cpp \ from the cpp/sdo/runtime/core/src/commonj/sdo/Makefile.am Replace SDOString with std::string -- Key: TUSCANY-764 URL: http://issues.apache.org/jira/browse/TUSCANY-764 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Attachments: SDOString.patch, TUSCANY-764.patch SDOString is unnecessary and adds no function over std::string I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. I experimented by typedef'ing SDOString to std::string and it won't be too tricky to fix the few compile errors. I will hold off checking this in until we have consensus that it is the right thing to do. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. Cheers, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++][SDO] Use of std::string
On 29/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 29/09/06, Pete Robbins [EMAIL PROTECTED] wrote: I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant. There were other reasons too, although the only one that remains is my own concern that we might eventually discover some extra functionality that we needed. However, it hasn't happened so far so as you say SDOString probably is redundant. Leaving SDOString as typedef'd will allow us to change it back to a class inheriting from std::string if necessary later. Next, we have many duplicate methods that take parameters as string or char*. I would like to remove all the methods that take char* as const string will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-) As far as I can tell they will. I had deliberately not made the switch to the string class only methods yet because it seemed premature in advance of the spec being changed. Finally, and a bit later, we need to look at changing the public APIs that return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string. This is another reason why I left it in its current state. I thought it would look a bit odd to have methods with a signature like const char * getSomeValue(const SDOString key) or whatever, and, as you say we can't change the return parameters in advance of the spec. I think SDOString should not be exposed to the user: const char * getSomeValue(const std::string key) is how I think the public API's should look. Cheers, -- Pete
[jira] Assigned: (TUSCANY-759) XPath test failure with compound queries
[ http://issues.apache.org/jira/browse/TUSCANY-759?page=all ] Pete Robbins reassigned TUSCANY-759: Assignee: Pete Robbins XPath test failure with compound queries Key: TUSCANY-759 URL: http://issues.apache.org/jira/browse/TUSCANY-759 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP 5.1.6, WinXP Reporter: Caroline Maynard Assigned To: Pete Robbins Part of the SDO for PHP core unit tests uses a standard company-departments[]-employees[] model and tests Xpath expressions. All these tests worked with Tuscany C++ SDO revision level 431903. I recently ran them with 436761 and there was a failure. I then reverted to 433676 and the tests were successful. It's possible that the Tuscany-539 fix was the culprit. The failing test is attempting to read company[departments[name='ShoeDept']/employees[name='Jane Smith']] The values for name are both valid, but in the failing revision level an exception was thrown with the message Invalid path: followed by the xpath above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE]Axis2C 0.94 Release Plan
Is Jira 209 fixed? Tuscany folk would really like this one! Cheers, On 27/09/06, Samisa Abeysinghe [EMAIL PROTECTED] wrote: +1.Samisa...Dinesh Premalal wrote: Since we have several new features and bug fixes , It is time to go for 0.94 release Please have a look at wiki http://wiki.apache.org/ws/FrontPage/Axis2C/releases/0.94 Please review the feature list and changes and add your comments. We would be able to do 0.94 release by end of this month. Your comments are welcome .. thanks, Dinesh - 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] -- Pete
