Re: [C++] Python extension available
Andrew Borley wrote: [snip] A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? Andy, Good catch. I have moved remotable to tuscany::sca::model::Interface. I have a real hard time understanding why the spec makes Scope part of interfaces instead of just implementations - IMHO the lifecyle of a component implementation should not be exposed as part of its interface - but both the Java and C++ SCA CI specs put it on Interface so I'm going to get over this for now, I'm probably missing something... I moved it as well to tuscany::sca::model::Interface. With these changes I was able to adjust your Python extension so that it does not depend anymore on the CPP extension. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python extension available
On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: [snip] A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? Andy, Good catch. I have moved remotable to tuscany::sca::model::Interface. I have a real hard time understanding why the spec makes Scope part of interfaces instead of just implementations - IMHO the lifecyle of a component implementation should not be exposed as part of its interface - but both the Java and C++ SCA CI specs put it on Interface so I'm going to get over this for now, I'm probably missing something... I moved it as well to tuscany::sca::model::Interface. With these changes I was able to adjust your Python extension so that it does not depend anymore on the CPP extension. That's cool - thanks! Andy
[jira] Created: (TUSCANY-697) [C++ for SDO] Add remaining methods taking SDOString args rather than char*
[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 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] Created: (TUSCANY-698) First pass PHP extension for C++ SCA
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 Priority: Minor 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] Updated: (TUSCANY-698) First pass PHP extension for C++ SCA
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ] Simon Laws updated TUSCANY-698: --- Attachment: phpextensioncalculatorchangespatch.txt apply to sca/samples/Calculator 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 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] Updated: (TUSCANY-698) First pass PHP extension for C++ SCA
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ] Simon Laws updated TUSCANY-698: --- Attachment: phpextension1patch.txt apply to sca/runtime/extensions 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 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]
Re: [C++] Cleaning up samples
On 9/5/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I checked in a copy of Calculator under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/Calculator-new/ , with a number of changes trying to simplify the sample and improve the consistency of the names used in the sample: - the subprojects follow the naming convention suggested in the SCA spec and the various SCA white papers on osoa.org (sample.calculator, sample.calculator.client etc.) helping create unique project names - similar naming convention for the composite names - changed Calculator subsystem to calculator solution - the business interfaces are named Calculator and Divide instead of CalculatorService, DivideService - the components are named CalculatorComponent and DivideComponent instead of CalculatorServiceComponent, DivideServiceComponent - the services are named CalculatorService and DivideService - and a few other minor cleanup changes, renamed readme.txt to README, renamed the .cmd to .bat, changed the .bat to be consistent with the .sh, and use the same executable name on Windows and Linux. If there's no objection, I plan to replace the existing Calculator sample with this new form, and also check in an updated version of Bigbank following the same pattern tomorrow. This will make our implementation of the Bigbank sample much closer to what's described in the OSOA Recursive Assembly white paper at http://www.osoa.org/display/Main/Recursive+Assembly+Model. I'm not sure what we should put in the README for each sample. Right now the contents of the README is Windows specific and probably obsolete, I was thinking of maybe having another file besides the README called HOWTO-DEPLOY describing how to deploy the sample to Axis2C... Comments and thoughts welcome. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] All sounds good to me. The README should have a description of what the sample does, what it is trying to demonstrate, and a summary of the various different configurations and platforms on which it will run. I.e. you might want to run the local or web services client on windows or *nix. So there will necessarily be quite a number of deployment and runtime instructions for what is actually a relatively simple demo. Your idea of having separate DEPLOY files for the different configurations sounds like the way to go. It might also be useful to include screen shots of the command line showing the run commands and the expected output. Also it would be good to have some discussion of how to turn debug on and what it shows you. This shouldn't be done on a sample by sample basis but I find it quite instructive. I have come across a set of typical configuration errors when using the samples, e.g. the one that always catches me is http://issues.apache.org/jira/browse/TUSCANY-499. We should create a samples FAQ I guess. There is quite a number of environement variables and paths that need to be set before it all works. We should review the run scripts to see if we can add more checking as they already check that appropriate environment variables are set. If you want some help with these things let me know. S
[C++] First pass PHP extesion
Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698) 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 functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentType was right but I'm prepared to be convinced. In the longer term 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. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon
Re: [C++] Beginning of a Ruby extension available
On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Wow, extensions galore:-)
Re: [C++] New Python sample
On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andy, I checked in an initial version of Calculator which demonstrates your Python extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculator/ . More work is necessary to make it complete, show a Python client, usage of SCA references in a Python component, and remove the .h files that are currently used to type interfaces, and complete the README, but this is a starting point... Sebastien , That looks great - I think it's better that we keep the samples separated rather than provide a million options on a single sample - that will only confuse people :-) Cheers Andy
Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
Quite a while back we had a Ruby container contributed for the Java runtime, see TUSCANY-365. Is anyone interested in looking at porting that to the new Java runtime and getting it to match what the C++ guys are doing? ...ant On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
Hi... I am interested in taking a look at this. I hope to get a feel of implementing container extensions through this. I shall get started with this rightaway. Ant, I might need your help for this after I do some ground work. Thanks. - Venkat On 9/6/06, ant elder [EMAIL PROTECTED] wrote: Quite a while back we had a Ruby container contributed for the Java runtime, see TUSCANY-365. Is anyone interested in looking at porting that to the new Java runtime and getting it to match what the C++ guys are doing? ...ant On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Beginning of a Ruby extension available
On 9/6/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Wow, extensions galore:-) The extension enabling work that Pete and Sebastien did seems to be working well :-)
[jira] Updated: (TUSCANY-697) [C++ for SDO] Add remaining methods taking SDOString args rather than char*
[ http://issues.apache.org/jira/browse/TUSCANY-697?page=all ] Attachment: TUSCANY-697.patch [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 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] Commented: (TUSCANY-697) [C++ for SDO] Add remaining methods taking SDOString args rather than char*
[ http://issues.apache.org/jira/browse/TUSCANY-697?page=comments#action_12432849 ] Geoff Winn commented on TUSCANY-697: Patch file built and tested on RHEL 3 and XP with MSVC 6 and 7. [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 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]
Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
Sounds great. When Venkat is done with his port I would be interested in helping. Perhaps a sample demonstrating interopt between services with different language implementations. If we are using SDO for our data model how will SDO support be provided in these container extensions ? Robbie On 9/6/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi... I am interested in taking a look at this. I hope to get a feel of implementing container extensions through this. I shall get started with this rightaway. Ant, I might need your help for this after I do some ground work. Thanks. - Venkat On 9/6/06, ant elder [EMAIL PROTECTED] wrote: Quite a while back we had a Ruby container contributed for the Java runtime, see TUSCANY-365. Is anyone interested in looking at porting that to the new Java runtime and getting it to match what the C++ guys are doing? ...ant On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
Re: [C++] Cleaning up samples
For each sample project I think that it is a good idea to include an overview javadoc page that includes information about common setup etc. This would include essentually the same information that you outlined for the readme but provides a good means to link to external docs like specifications, traditional javadoc content such as APIs and can ( and should ) be placed on our website. This is what I did for the SDO samples and I think that worked well. If people do not like it I can change it so that the it matches the desired readme format but I prefer the overview option so that it is consistent. Robbie On 9/6/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/5/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I checked in a copy of Calculator under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/Calculator-new/ , with a number of changes trying to simplify the sample and improve the consistency of the names used in the sample: - the subprojects follow the naming convention suggested in the SCA spec and the various SCA white papers on osoa.org (sample.calculator, sample.calculator.client etc.) helping create unique project names - similar naming convention for the composite names - changed Calculator subsystem to calculator solution - the business interfaces are named Calculator and Divide instead of CalculatorService, DivideService - the components are named CalculatorComponent and DivideComponent instead of CalculatorServiceComponent, DivideServiceComponent - the services are named CalculatorService and DivideService - and a few other minor cleanup changes, renamed readme.txt to README, renamed the .cmd to .bat, changed the .bat to be consistent with the .sh, and use the same executable name on Windows and Linux. If there's no objection, I plan to replace the existing Calculator sample with this new form, and also check in an updated version of Bigbank following the same pattern tomorrow. This will make our implementation of the Bigbank sample much closer to what's described in the OSOA Recursive Assembly white paper at http://www.osoa.org/display/Main/Recursive+Assembly+Model. I'm not sure what we should put in the README for each sample. Right now the contents of the README is Windows specific and probably obsolete, I was thinking of maybe having another file besides the README called HOWTO-DEPLOY describing how to deploy the sample to Axis2C... Comments and thoughts welcome. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] All sounds good to me. The README should have a description of what the sample does, what it is trying to demonstrate, and a summary of the various different configurations and platforms on which it will run. I.e. you might want to run the local or web services client on windows or *nix. So there will necessarily be quite a number of deployment and runtime instructions for what is actually a relatively simple demo. Your idea of having separate DEPLOY files for the different configurations sounds like the way to go. It might also be useful to include screen shots of the command line showing the run commands and the expected output. Also it would be good to have some discussion of how to turn debug on and what it shows you. This shouldn't be done on a sample by sample basis but I find it quite instructive. I have come across a set of typical configuration errors when using the samples, e.g. the one that always catches me is http://issues.apache.org/jira/browse/TUSCANY-499. We should create a samples FAQ I guess. There is quite a number of environement variables and paths that need to be set before it all works. We should review the run scripts to see if we can add more checking as they already check that appropriate environment variables are set. If you want some help with these things let me know. S -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432874 ] Robbie Minshall commented on TUSCANY-153: - FYI. All very striaght forward but in order to apply the patch I had to perform the following 1. new files not versioned. - add files by hand prior to applying patch : touch sdo/impl/src/test/java/org/apache/tuscany/sdo/test/ChangeSummaryOnDataObjectTestCase.java touch sdo/impl/src/test/resources/datagraph.xsd touch sdo/impl/src/test/resources/sdoJava.xsd touch sdo/impl/src/test/resources/sdoModel.xsd touch sdo/impl/src/test/resources/sdoXML.xsd touch sdo/impl/src/test/resources/simpleWithChangeSummary.xsd 2. Adjust fuzz factor to 7 to get matches of recently changed files 3. DataObjectImpl could not match patch due to import reordering. - add imports by hand after patch applied import org.apache.tuscany.sdo.SDOFactory; import org.apache.tuscany.sdo.impl.ClassImpl; import org.apache.tuscany.sdo.impl.DataObjectImpl; 4. Delete ChangeSummaryTypeImpl as kelvin mentioned ChangeSummary on root data object not supported --- Key: TUSCANY-153 URL: http://issues.apache.org/jira/browse/TUSCANY-153 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: do_cs_2.patch, tuscany153.jar The RDB DAS intends to produce data graphs without using a DataGraph instance and this requires us to attach a change history to the root DataObject. It seems that this capability is not yet implemented. -- 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-674) DAS: Modify test framework to facilitate support for new vendors
[ http://issues.apache.org/jira/browse/TUSCANY-674?page=all ] Kevin Williams closed TUSCANY-674. -- Fix Version/s: Java-Mx Resolution: Fixed Verified with revision: 440754 DAS: Modify test framework to facilitate support for new vendors Key: TUSCANY-674 URL: http://issues.apache.org/jira/browse/TUSCANY-674 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Fix For: Java-Mx Attachments: tuscany674.txt Currently, to add support for a new database vendor in the DAS test framework, you have to write a large number of SQL queries to override the defaults. It would be easier to add support for new vendors if subclasses of DatabaseSetup only had to define what is different (eg, type names and such) rather than writing an entire query. -- 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: DataObject/DataGraph Serialization DataGraphRoot
Hi All,
I thought I'd check-in regarding the status of this request? Kevin was kind
enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670),
but I'm blocked. Any chance there is a workaround available? I'd like to
use the DAS for DB access, but would be willing to map to/from a XSD if that
would eliminate the current problem.
Thanks,
Scott
-Original Message-
From: Kevin Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 3:25 PM
To: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org
Subject: Re: DataObject/DataGraph Serialization DataGraphRoot
Hi Yang,
Comments in line ...
Yang ZHONG wrote:
You may need to serialize the generated SDO metadata. On the other
hand, I recommend the scenario design to be reconsidered.
Thank Frank for suggesting a SDOUtil helper taking a list of Types for
DAS to serialize all generated Types along with DataGraph.
If you're willing to do that, I'll implement and send it out.
Yes. Please implement this method. If I understand correctly, the function
exists today in EMF but we prefer to stay with SDO apis. Also, I am not
sure why the method should take a list of generated Types since they exist
in the graph already. So, why not a method something like
this: serializeTypes() ?
At the same time, I have some thoughts on the scenario design.
DataBase schema is unlikely changed frequently, it's inefficient for
DAS to always generate same SDO metadata over and over again on every
single query, it's also inefficient to serialize same SDO metadata
over and over again on every single invocation back to client. A
typical customer scenario is, both client and server have SDO metadata
already, therefore SDO metadata serialization isn't really necessary,
and SDO metadata generation from DAS isn't really necessary. I know an
early version of DAS (it was under different name) can accept existing
SDO metadata and generate only SDO instances. My previous product
customers actually complained about the very poor performance caused
by repeating same SDO metadata generation and serialization.
So, are you interested in trying such scenario so that you won't have
type not found problem?
Solution 2-1 (typical real scenario):
1. deploy SDO metadata to both client and server 2. instruct DAS to
accept the existing SDO metadata 3. do rest of whatever being done
right now
The DAS supports this scenario today and can accept Static Types from the
client. But, the purely dynamic scenario is an important one so we must
support both.
Thanks!
Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
do rest of whatever being done right now
On 8/25/06, Kevin Williams [EMAIL PROTECTED] wrote:
The RDB DAS creates the graph and corresponding Types dynamically
from the database query results.
Frank Budinsky wrote:
The problem seems to be that the metadata for class DataGraphRoot is
not
registered on the client. Is that the only missing metadata? What
about the metadata for the rest of the model. I can't provide any
more help without more details about how the metadata is being defined.
Frank.
Kevin Williams [EMAIL PROTECTED] wrote on 08/25/2006 03:30:15 PM:
It may be that your remote client has not initialized the SDO/EMF
environment properly and I think that we need some help from the
SDO team. I have copied this to the dev list since not everyone
has registered yet for the user list.
--Kevin
Luciano Resende wrote:
Hi Scott
So, here is a quick example from our unit testings :
/**
* Read a specific customer
*/
public void testReadSingle() throws Exception {
//Create and initialize command to read customers
DAS das = DAS.FACTORY.createDAS(getConnection());
Command readCustomers = das.createCommand(select * from
CUSTOMER where ID = 1);
//Read
DataObject root = readCustomers.executeQuery();
//Verify
assertEquals(1, root.getInt(CUSTOMER[1]/ID));
}
If you get a reference to root first, then try to access the
customer information, do you still have this problem ?
Maybe something like this :
DataObject root = readCust.executeQuery(); cust =
root.getDataObject(CUSTOMER)
Please let me know if this helps...
- Luciano
On 8/24/06, *Scott Kurinskas* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
Now that my DAS example is up and running, I'm trying to move my
example to
a client/server environment and integrate it with my product. My
use-case
is very simple, a client makes a request to the server, the
server
fetches
the result from the database and returns the DataObject back to
the client.
The server side code looks like the following:
das =
DAS Distribution Updates
With TUSCANY-674 I have finished remaining issues around DAS distribution for the next release of Tuscany DAS : distribution\das - DAS binaries and dependencies distribution\das-samples - DAS samples shipped in a ready-to-deploy war file with all dependencies and sources included. Please let me know if anyone have any questions or comments on this final structure. -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Test coverage, was: Process and content for next release?
I've used Clover in the past and Cobertura since Dan mentioned it here a while ago. Cobertura is really really easy and works today, just use mvn cobertura:cobertura and it generates coverage reports in target\site\cobertura. Thats so easy I'd really prefer this over Clover unless Clover can also be done that easily. There's nothing stopping anyone who prefers Clover to also use that themselves. 75% coverage (or even quite a bit higher for a 1.0 release) is a fine goal but I think its a bit early to start excluding things from the next releases for not reaching that percentage. I'd much prefer we focus things like getting functional and integration testing frameworks in place first. ...ant On 9/5/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Clover sounds good to me and I have tried it before. +1 on the 75% test coverage. Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, September 05, 2006 8:48 AM Subject: Re: Test coverage, was: Process and content for next release? On Sep 5, 2006, at 8:14 AM, Jeremy Boynes wrote: On Aug 16, 2006, at 2:49 PM, Jim Marino wrote: 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I'd also like to see much better test coverage than what we have. This is hard to quantify, but while code coverage does not guarantee good tests, it is an indicator. So, to have a metric, I'd like to see core (and other extensions) at 75% coverage when run through Clover. I picked Clover since it is a decent tool and license-friendly but if someone would like to suggest an alternative we could look at it as well. I think this goal is worth pursuing and would add that as a criteria for the next release. Apache has a license for Clover so we can all use it, Cobertura would be another alternative - any preference here? Whatever we use, I don't think this should be part of the build right now (although that could change later) but that the tool should be run periodically and the results published somewhere (e.g. on our site). I prefer Clover as it also has nice IDE integration. I also think test coverage should be run as part of an integration build and published since it is a general indication of areas that need work. Now Jim here only mentioned the core but this would apply to other extensions as well - I would be inclined to extend this requirement to any extension we consider baseline - any objections? For extensions considered baseline, I think respectable code coverage (~75%) is definitely a worthy goal. For baseline extensions, I would also add that we should also have a minimum bar in terms of what assembly features they support (e.g. state management, non- blocking, etc.). -- Jeremy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Should we merge the databinding-framework into spi/core?
Hi, I'm in the middle of integrating databinding framework with core/spi and it's time to make a decision on the packaging. There are two options for the databinding-framework. 1) Merge with core/spi: Move the interfaces/base classes into spi and implementation into core. 2) Keep databinding-framework as an extension. Individual databinding technology modules will stay as extensions. Please let me know your opions. Thanks, Raymond
Re: Should we merge the databinding-framework into spi/core?
If there are no external dependencies on databinding, my preference would be for the extension pieces to be merged with SPI and the impl to be placed in core under /services. Before that happens, though, I'd also like to see a lot more test coverage in place, particularly unit testing. Integration testing could be done whenever we get to an integration build. Jim On Sep 6, 2006, at 10:13 AM, Raymond Feng wrote: Hi, I'm in the middle of integrating databinding framework with core/ spi and it's time to make a decision on the packaging. There are two options for the databinding-framework. 1) Merge with core/spi: Move the interfaces/base classes into spi and implementation into core. 2) Keep databinding-framework as an extension. Individual databinding technology modules will stay as extensions. Please let me know your opions. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage, was: Process and content for next release?
On Sep 6, 2006, at 9:49 AM, ant elder wrote: I've used Clover in the past and Cobertura since Dan mentioned it here a while ago. Cobertura is really really easy and works today, just use mvn cobertura:cobertura and it generates coverage reports in target\site\cobertura. Thats so easy I'd really prefer this over Clover unless Clover can also be done that easily. There's nothing stopping anyone who prefers Clover to also use that themselves. Clover integrates really nicely and also has great IDE integration, including a visual display of non-covered code inline. Does Cobertura do that? 75% coverage (or even quite a bit higher for a 1.0 release) is a fine goal but I think its a bit early to start excluding things from the next releases for not reaching that percentage. I'd much prefer we focus things like getting functional and integration testing frameworks in place first. Could we make it a requirement that we also have functional and integration testing in place prior to any release? I don't see how we can realistically get quality without unit testing and while code coverage is not a guarantee, it is a good quantitative indication of where we stand. Currently, we have many half-completed and untested extensions and I don't think they should be released in their current state lest we risk gaining a reputation of shipping poor code. If we can't get acceptable coverage, I think we should hold off shipping the extensions and just ship kernel as that offers useful functionality (assuming we reach at least 75% which is definitely achievable given the current amount of coverage). Jim ...ant On 9/5/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Clover sounds good to me and I have tried it before. +1 on the 75% test coverage. Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, September 05, 2006 8:48 AM Subject: Re: Test coverage, was: Process and content for next release? On Sep 5, 2006, at 8:14 AM, Jeremy Boynes wrote: On Aug 16, 2006, at 2:49 PM, Jim Marino wrote: 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I'd also like to see much better test coverage than what we have. This is hard to quantify, but while code coverage does not guarantee good tests, it is an indicator. So, to have a metric, I'd like to see core (and other extensions) at 75% coverage when run through Clover. I picked Clover since it is a decent tool and license-friendly but if someone would like to suggest an alternative we could look at it as well. I think this goal is worth pursuing and would add that as a criteria for the next release. Apache has a license for Clover so we can all use it, Cobertura would be another alternative - any preference here? Whatever we use, I don't think this should be part of the build right now (although that could change later) but that the tool should be run periodically and the results published somewhere (e.g. on our site). I prefer Clover as it also has nice IDE integration. I also think test coverage should be run as part of an integration build and published since it is a general indication of areas that need work. Now Jim here only mentioned the core but this would apply to other extensions as well - I would be inclined to extend this requirement to any extension we consider baseline - any objections? For extensions considered baseline, I think respectable code coverage (~75%) is definitely a worthy goal. For baseline extensions, I would also add that we should also have a minimum bar in terms of what assembly features they support (e.g. state management, non- blocking, etc.). -- Jeremy - 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] - 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]
Re: Locating SCDL for include and other usages
Maybe we can broaden relative path semantics therefore it may not necessarily be mandatory any longer to introduce scdlResource. e.g. the ClassPath is dir1, dir2, jar1, jar2. Even if a resolved relative path is dir1/com/example/included.scdl, we can also search for dir2/com/example/included.scdl and jar2!/com/example/included.scdl. Similarly evev if a resolved relative path is jar2!/org/tuscant/system.scdl, we can search for jar1!/org/tuscant/system.scdl and dir2/org/tuscant/system.scdl On 9/6/06, Jeremy Boynes [EMAIL PROTECTED] wrote: The spec says that include takes the name of the composite to be included but does not say how it should be located. We currently support a scdlLocation attribute that takes a URL, with relative URLs being resolved against the location of the containing scdl. However, it would be nice to allow users to place SCDL somewhere on the composite's classpath. I think we should also support a scdlResource attribute that takes the name of a Java resource that will be located using the same classpath as we use for Java classes (i.e. the same classpath used to locate the class in a implementation.java or interface.java). One thing this would let us do is publish scdl fragments in the kernel for things like the set of loader components (the current loader.scdl) that can then be reused by the various hosts; this would get rid of the duplicates and the need to maintain them. This will help with the webapp host I am working on so I plan to add the scdlResouce attribute soon. The same would also apply to things like implementation.composite -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
[jira] Closed: (TUSCANY-694) Update DAS sample distribution
[ http://issues.apache.org/jira/browse/TUSCANY-694?page=all ] Kevin Williams closed TUSCANY-694. -- Resolution: Fixed Verified with revision: 440808 Update DAS sample distribution -- Key: TUSCANY-694 URL: http://issues.apache.org/jira/browse/TUSCANY-694 Project: Tuscany Issue Type: Improvement Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Attachments: lresende.tuscany694.20060905.txt Will address the following issues in this jira: - Make das sample war files to include source code - Make das sample files to have dependencies in WEB-INF\lib - Remove access to das-sample using file set structure in the assembly distribution plugin. - Make distribution retrieve das sample based on dependency on the war file containing the java source -- 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: Tuscany war plugin
Jeremy, 1 4 are done. I am scratching my head around understanding the usage of ArtifactResolver.resolveTransitively() from the Maven artifact API. Do you have any idea? Also any pointers to the required servlet context listener, filter and servlet (if they exist) will be highly appreciated. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 05:43 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Jeremy/Chris, Following the thread between you two, these are the changes I plan to make, 1. Support exploded deployment 2. Support transitive dependencies for boot libs (do we do the same for extensions?) 3. Enrich the web xml with the context listener, filter and servlet 4. Use web-app-host as the default for bootLibs Have I missed anything (it is still early morning, I need to have my coffee :-)) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. If we decide to use Maven for resolving the extension dependencies, wouldn't this work the same way as that for bootLibs (Most of the stuff in the plugin is factored out from the Maven dependency plugin) Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Date: Tue, 5 Sep 2006 19:41:13 -0700 On Sep 5, 2006, at 6:03 PM, Chris Wall wrote: Some more questions :-) 1.) I suppose I don't understand extensions. If an application uses implementation.spring and binding.ws, should the Spring container and Celtix binding jars be bootLibs or extensions? Both extend the core, so my initial guess was that they both were extensions. Configuring them as such each produce MissingResourceException during Tuscany bootstrapping. As bootLibs both resources are found. They should be extensions but the extension mechanism is not working yet for webapps (WIP). 2.) Maybe this is WIP, but transitive dependencies are not pulled into the webapp. For example, the Celtix binding requires many additional jars, but are not included in the WAR - NoClassDefFoundError: javax/wsdl/WSDLException. They are not - I hope Meeraj is working on support for that for bootLibs. For extension, we need to do a couple of things: 1) find out what the dependencies for an extension are - this was the discussion Jim and I had a while ago about using OSGi dependencies vs. using Maven meta-data either read from the jar or by using dependency elements in the scdl. 2) use the ArtifactRepository to resolve those dependencies (e.g. from a local maven repo) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. As a work around, you can always use Class-Path entries in the extensions' manifests to include the dependencies. 3.) How does the plugin and bootstrap handle the scenario where a bootLib and/or extension lib share a dependency with the application? Will the plugin and bootstrap mechanism default to WEB-INF/lib/shared-jar? The host's classloader (for a webapp this is the TCCL) is a parent classloader for all the runtime classloaders. So extensions are children of the runtime boot loader which is a child of the webapp loader. Putting things in WEB-INF/lib should make them available to everything. Having said that I am not convinced we are following this structure everywhere and I am in the process of going back through and checking how we set them all up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead
[jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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: [jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
Jeremy/Andy, Would this overlap with the war plugin stuff? Ta Meeraj -Original Message- From: Andy Piper (JIRA) [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 19:05 To: tuscany-dev@ws.apache.org Subject: [jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432924 ] Robbie Minshall commented on TUSCANY-696: - I will take a look at this later this afternoon. XMLStreamHelper usage - Key: TUSCANY-696 URL: http://issues.apache.org/jira/browse/TUSCANY-696 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Environment: Windows XP, java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) Reporter: Scott Boag Attachments: SimpleRun2.java, XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml Not sure if this is a bug or user problem or both. I am trying to work on a generic lossless adapter from SDO to a XML data model, without intervening serialization. I'm running the following code: XMLHelper xmlHelper = XMLHelper.INSTANCE; XSDHelper xsdHelper = XSDHelper.INSTANCE; TypeHelper typeHelper = TypeHelper.INSTANCE; URL url = SimpleRun2.class.getClassLoader().getResource( NNS_SCHEMA_LOCATION); List xsdTypes = xsdHelper .define(url.openStream(), url.toExternalForm()); // InputStream is = new FileInputStream(TEST_XML_DOCUMENT); URL testxmlURL = SimpleRun2.class.getClassLoader().getResource( TEST_XML_DOCUMENT); XMLDocument doc = xmlHelper.load(testxmlURL.openStream()); DataObject rootobj = doc.getRootObject(); // typeHelper.define(xsdTypes); XMLStreamHelper xmlStreamHelper = SDOUtil .createXMLStreamHelper(typeHelper); XMLStreamReader streamReader = xmlStreamHelper .createXMLStreamReader(rootobj); xmlStreamReader2XmlText(streamReader, System.out); (xmlStreamReader2XmlText is just a utility method I lifted from somewhere) Raymond told me in a private exchange that I needed to do TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation); (though that implies that I know ahead of time the schema). Since TypeHelper doesn't have a define that takes the schema, I assume the above is what he meant. If I pass the result of the xsdHelper.define to typeHelper.define, it crashes in spectacular ways. When I run this code, the result is: p0:AnyTypeDataObject Which is clearly wrong. I've included the complete program. -- 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: Locating SCDL for include and other usages
You lost me. On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote: Maybe we can broaden relative path semantics therefore it may not necessarily be mandatory any longer to introduce scdlResource. e.g. the ClassPath is dir1, dir2, jar1, jar2. Even if a resolved relative path is dir1/com/example/included.scdl, we can also search for dir2/com/example/included.scdl and jar2!/com/example/included.scdl. Similarly evev if a resolved relative path is jar2!/org/tuscant/ system.scdl, we can search for jar1!/org/tuscant/system.scdl and dir2/org/tuscant/system.scdl If the classpath is [dir1, dir2, jar1, jar2], ClassLoader.getResource () would look in all of those anyway. The difference between scdLocation and scdlResource is between resolving on the classpath vs. resolving relative to the current scdl (which may not be on the classpath at all). What are you proposing to avoid that? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
On Sep 6, 2006, at 10:57 AM, Meeraj Kunnumpurath wrote: Jeremy, 1 4 are done. I am scratching my head around understanding the usage of ArtifactResolver.resolveTransitively() from the Maven artifact API. Do you have any idea? Sorry, not really. Also any pointers to the required servlet context listener, filter and servlet (if they exist) will be highly appreciated. Best I have is Chris's post here: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/% [EMAIL PROTECTED] Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 05:43 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Jeremy/Chris, Following the thread between you two, these are the changes I plan to make, 1. Support exploded deployment 2. Support transitive dependencies for boot libs (do we do the same for extensions?) 3. Enrich the web xml with the context listener, filter and servlet 4. Use web-app-host as the default for bootLibs Have I missed anything (it is still early morning, I need to have my coffee :-)) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. If we decide to use Maven for resolving the extension dependencies, wouldn't this work the same way as that for bootLibs (Most of the stuff in the plugin is factored out from the Maven dependency plugin) Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Date: Tue, 5 Sep 2006 19:41:13 -0700 On Sep 5, 2006, at 6:03 PM, Chris Wall wrote: Some more questions :-) 1.) I suppose I don't understand extensions. If an application uses implementation.spring and binding.ws, should the Spring container and Celtix binding jars be bootLibs or extensions? Both extend the core, so my initial guess was that they both were extensions. Configuring them as such each produce MissingResourceException during Tuscany bootstrapping. As bootLibs both resources are found. They should be extensions but the extension mechanism is not working yet for webapps (WIP). 2.) Maybe this is WIP, but transitive dependencies are not pulled into the webapp. For example, the Celtix binding requires many additional jars, but are not included in the WAR - NoClassDefFoundError: javax/wsdl/WSDLException. They are not - I hope Meeraj is working on support for that for bootLibs. For extension, we need to do a couple of things: 1) find out what the dependencies for an extension are - this was the discussion Jim and I had a while ago about using OSGi dependencies vs. using Maven meta-data either read from the jar or by using dependency elements in the scdl. 2) use the ArtifactRepository to resolve those dependencies (e.g. from a local maven repo) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. As a work around, you can always use Class-Path entries in the extensions' manifests to include the dependencies. 3.) How does the plugin and bootstrap handle the scenario where a bootLib and/or extension lib share a dependency with the application? Will the plugin and bootstrap mechanism default to WEB-INF/lib/shared-jar? The host's classloader (for a webapp this is the TCCL) is a parent classloader for all the runtime classloaders. So extensions are children of the runtime boot loader which is a child of the webapp loader. Putting things in WEB-INF/lib should make them available to everything. Having said that I am not convinced we are following this structure everywhere and I am in the process of going back through and checking how we set them all up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its
Re: [jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
Maybe, although this might also be relevant for a pure Spring host (i.e. no webapp). I think we need to get more info from Andy on what he has in mind (e.g. the patch :-) ) -- Jeremy On Sep 6, 2006, at 11:17 AM, Meeraj Kunnumpurath wrote: Jeremy/Andy, Would this overlap with the war plugin stuff? Ta Meeraj -Original Message- From: Andy Piper (JIRA) [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 19:05 To: tuscany-dev@ws.apache.org Subject: [jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ] Andy Piper updated TUSCANY-699: --- Attachment: springlaunch.patch Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=comments#action_12432929 ] Jeremy Boynes commented on TUSCANY-699: --- I would (strongly) prefer we do not introduce a dependency on clogging. Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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: Locating SCDL for include and other usages
I assumed with relative URLs being resolved against the location of the containing scdl resolves against the full path/URL of the containing scdl. Never mind if the assumption was wrong. The response sounds applying relative path directly to classLoader.getResource, I wonder if that's the true intention. e.g. com/example/a.scdl includes included.scdl normally people assume com/example/included.scdl because that's normally relative means. Direct classLoader.getResource(included.scdl) does *not* meet normal expectation. Anyway, the reason I've been trying to help is, it would be nice to keep scdl business intact, other info such as search path, repository config and so on, might need another host. On 9/6/06, Jeremy Boynes [EMAIL PROTECTED] wrote: You lost me. On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote: Maybe we can broaden relative path semantics therefore it may not necessarily be mandatory any longer to introduce scdlResource. e.g. the ClassPath is dir1, dir2, jar1, jar2. Even if a resolved relative path is dir1/com/example/included.scdl, we can also search for dir2/com/example/included.scdl and jar2!/com/example/included.scdl. Similarly evev if a resolved relative path is jar2!/org/tuscant/ system.scdl, we can search for jar1!/org/tuscant/system.scdl and dir2/org/tuscant/system.scdl If the classpath is [dir1, dir2, jar1, jar2], ClassLoader.getResource () would look in all of those anyway. The difference between scdLocation and scdlResource is between resolving on the classpath vs. resolving relative to the current scdl (which may not be on the classpath at all). What are you proposing to avoid that? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
RE: Tuscany war plugin
Ok, no worries :-) I will prod through the Maven source. I think Chris's post has got all I need. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 19:28 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin On Sep 6, 2006, at 10:57 AM, Meeraj Kunnumpurath wrote: Jeremy, 1 4 are done. I am scratching my head around understanding the usage of ArtifactResolver.resolveTransitively() from the Maven artifact API. Do you have any idea? Sorry, not really. Also any pointers to the required servlet context listener, filter and servlet (if they exist) will be highly appreciated. Best I have is Chris's post here: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/% [EMAIL PROTECTED] Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 05:43 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Jeremy/Chris, Following the thread between you two, these are the changes I plan to make, 1. Support exploded deployment 2. Support transitive dependencies for boot libs (do we do the same for extensions?) 3. Enrich the web xml with the context listener, filter and servlet 4. Use web-app-host as the default for bootLibs Have I missed anything (it is still early morning, I need to have my coffee :-)) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. If we decide to use Maven for resolving the extension dependencies, wouldn't this work the same way as that for bootLibs (Most of the stuff in the plugin is factored out from the Maven dependency plugin) Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Date: Tue, 5 Sep 2006 19:41:13 -0700 On Sep 5, 2006, at 6:03 PM, Chris Wall wrote: Some more questions :-) 1.) I suppose I don't understand extensions. If an application uses implementation.spring and binding.ws, should the Spring container and Celtix binding jars be bootLibs or extensions? Both extend the core, so my initial guess was that they both were extensions. Configuring them as such each produce MissingResourceException during Tuscany bootstrapping. As bootLibs both resources are found. They should be extensions but the extension mechanism is not working yet for webapps (WIP). 2.) Maybe this is WIP, but transitive dependencies are not pulled into the webapp. For example, the Celtix binding requires many additional jars, but are not included in the WAR - NoClassDefFoundError: javax/wsdl/WSDLException. They are not - I hope Meeraj is working on support for that for bootLibs. For extension, we need to do a couple of things: 1) find out what the dependencies for an extension are - this was the discussion Jim and I had a while ago about using OSGi dependencies vs. using Maven meta-data either read from the jar or by using dependency elements in the scdl. 2) use the ArtifactRepository to resolve those dependencies (e.g. from a local maven repo) I like the idea of reusing all of this function from Maven (given the number of easily available artifacts plus its support for intranet configurations) but we need to chat to the Maven folks to see how easy it would be to extract that function. Any help here would be appreciated. As a work around, you can always use Class-Path entries in the extensions' manifests to include the dependencies. 3.) How does the plugin and bootstrap handle the scenario where a bootLib and/or extension lib share a dependency with the application? Will the plugin and bootstrap mechanism default to WEB-INF/lib/shared-jar? The host's classloader (for a webapp this is the TCCL) is a parent classloader for all the runtime classloaders. So extensions are children of the runtime boot loader which is a child of the webapp loader. Putting things in WEB-INF/lib should make them available to everything. Having said that I am not convinced we are following this structure everywhere and I am in the process of going back through and checking how we set them all up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
[jira] Created: (TUSCANY-700) NPE in TuscanySessionListener.sessionDestroyed when Tomcat session expires
NPE in TuscanySessionListener.sessionDestroyed when Tomcat session expires -- Key: TUSCANY-700 URL: http://issues.apache.org/jira/browse/TUSCANY-700 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Chris Wall ERROR [12:10:42] (org.apache.catalina.session.StandardSession:expire:699) - Session event listener threw exception java.lang.NullPointerException at org.apache.tuscany.runtime.webapp.TuscanySessionListener.sessionDestroyed(TuscanySessionListener.java:49) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:579) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1284) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1569) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1558) at java.lang.Thread.run(Thread.java:595) web.xml: context-param param-namesystemScdlPath/param-name param-value/META-INF/sca/webapp.system.scdl/param-value /context-param context-param param-nameapplicationScdlPath/param-name param-value/META-INF/sca/default.scdl/param-value /context-param context-param param-namecurrentCompositePath/param-name param-valueSpringSample/param-value /context-param filter filter-nameTuscanyFilter/filter-name filter-classorg.apache.tuscany.runtime.webapp.TuscanyFilter/filter-class /filter filter-mapping filter-nameTuscanyFilter/filter-name url-pattern/*/url-pattern /filter-mapping listener listener-classorg.apache.tuscany.runtime.webapp.TuscanyContextListener/listener-class /listener listener listener-classorg.apache.tuscany.runtime.webapp.TuscanySessionListener/listener-class /listener servlet servlet-nameTuscanyServlet/servlet-name display-nameTuscany Servlet/display-name servlet-classorg.apache.tuscany.runtime.webapp.TuscanyServlet/servlet-class /servlet servlet-mapping servlet-nameTuscanyServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping -- 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-701) Conversion to date types which do not include month can give incorrect results
Conversion to date types which do not include month can give incorrect results -- Key: TUSCANY-701 URL: http://issues.apache.org/jira/browse/TUSCANY-701 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Environment: Problem exists when running Sun JVM (is not seen on IBM JVM) Reporter: Brian Murray Priority: Minor DateConversionTestCase.java made evident an issue corrected in Tuscany-582. However, when it was introduced into the Tuscany stream an additional error was seen sporadically (repeatedly for a given individual, but for a set of individuals only a subset would see the problem). This JIRA will address the additional error. The reason the problem is seen only by a subset of people is that it is JVM specific. When it is seen (as it is with the Sun JVM), the nature of the problem is to report Day, Hour, and even Year values as X - 1, where X is the correct value. The problem occurs when the requested date format does not include a month (e.g. toYear, toDay). The truncated month is assigned a value of January, and the Sun JVM may then (depending on the TimeZone, northern versus southern hemisphere, and the month in which the test is run) change the time to reflect the change to or from daylight savings time. The reason it can have an impact on toYear is that toYear() for an input date of Wednesday September 6, 2006 03:16:20.382 would result in an interim value of Sunday January 1, 2006 00:00:00.000. In the case where an error is seen, an adjustment is made for daylight savings time to Saturday December 31, 2005 23:00:00.000. As such, toYear erroneously returns a value of 2005 for the input date (in the error case). Would a committer please assign this issue to me?. -- 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: Locating SCDL for include and other usages
On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote: I assumed with relative URLs being resolved against the location of the containing scdl resolves against the full path/URL of the containing scdl. Never mind if the assumption was wrong. I think that's the difference - relative URLs are resolved against the URL (using new URL(current, scdlLocation)) so there is no path to search. The response sounds applying relative path directly to classLoader.getResource, I wonder if that's the true intention. e.g. com/example/a.scdl includes included.scdl normally people assume com/example/included.scdl because that's normally relative means. Direct classLoader.getResource(included.scdl) does *not* meet normal expectation. For scdlResource, the value is resolved using the classpath using ClassLoader.getResource() - the value supplied is absolute as that is all that method takes. Anyway, the reason I've been trying to help is, it would be nice to keep scdl business intact, other info such as search path, repository config and so on, might need another host. Could you clarify what you mean here? I'd also add that both these mechanisms override the use of the repository. If you wanted to use that you would not use either of these but would instead supply repository metadata e.g. include name=included group=com.example version=1.0/ I see that as the norm - the scdlLocation and scdlResource variants would only be used in atypical circumstances (like when we are loading the system scdl and don't have the repo bootstrapped yet). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432954 ] Robbie Minshall commented on TUSCANY-153: - COMPANY WITH CHANGE SUMMARY PROPERTY Rather than using a new type to wrap an existing type with a changeSummary I have simply added a changeSummary property into the sequence of an existing Type. Perhaps I did this incorrectly I have put the xsd and the xml below and then some questions below that. * * * XSD * * * ?xml version=1.0 encoding=UTF-8? xsd:schema xmlns:company=changeSummary_company.xsd xmlns:sdo=commonj.sdo xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; targetNamespace=changeSummary_company.xsd xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/ xsd:element name=company type=company:CompanyTypeCS/ xsd:complexType name=CompanyTypeCS xsd:sequence xsd:element maxOccurs=unbounded name=departments type=company:DepartmentType/ xsd:element name=changes type=sdo:ChangeSummaryType/ /xsd:sequence xsd:attribute name=name type=xsd:string/ xsd:attribute name=employeeOfTheMonth type=xsd:string/ /xsd:complexType xsd:complexType name=DepartmentType xsd:sequence xsd:element maxOccurs=unbounded name=employees type=company:EmployeeType/ /xsd:sequence xsd:attribute name=name type=xsd:string/ xsd:attribute name=location type=xsd:string/ xsd:attribute name=number type=xsd:int/ /xsd:complexType xsd:complexType name=EmployeeType xsd:attribute name=name type=xsd:string/ xsd:attribute name=SN type=xsd:ID/ xsd:attribute name=manager type=xsd:boolean/ /xsd:complexType /xsd:schema * * * XML * * * ?xml version=1.0 encoding=ASCII? company:company xmlns:company=changeSummary_company.xsd employeeOfTheMonth=E0001 name=ACME departments location=NY name=Advanced Technologies number=123 employees name=John Jones SN=E0001/ employees name=Jane Doe SN=E0003/ employees manager=true name=F Varone SN=E0004/ /departments changes logging=true /changes /company:company * * * Questions and issues * * * 1. Type for changes property should be ChangeSummaryType but was Object. I obtained the name of the type using DataObject.getProperty(changes).getType().getName() junit.framework.ComparisonFailure: Asserting that the type for the changes property is ChangeSummaryType expected:ChangeSummaryType but was:Object 2. Obtaining ChangeSummary. DataObject.get(changes) returns a null String DataObject.getChangeSummary returns null where it should return a ChangeSummary 3. Obtaining Sequence I am unable to get the sequence ( which is making me think the xml may be incorrect ). .getSequence() is returning null. ChangeSummary on root data object not supported --- Key: TUSCANY-153 URL: http://issues.apache.org/jira/browse/TUSCANY-153 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: do_cs_2.patch, tuscany153.jar The RDB DAS intends to produce data graphs without using a DataGraph instance and this requires us to attach a change history to the root DataObject. It seems that this capability is not yet implemented. -- 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-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432955 ] Robbie Minshall commented on TUSCANY-153: - LOADING SIMPLE CHANGE SUMMARY When I attempt to load the simple change summary contained within the fix I get an exception when loading the XML. I will look into the causes tomorrow when I have more time but if you have any insights that would be great. public static final String CHANGESUMMARY_SIMPLE_XSD = /simpleWithChangeSummary.xsd; public static final String CHANGESUMMARY_SIMPLE_XML = /simplechangesummary.xml; . . . . // define simple Type XSDHelper.INSTANCE.define(getClass().getResourceAsStream( CHANGESUMMARY_SIMPLE_XSD), null); // get a DataObject DataObject simple = XMLHelper.INSTANCE.load( getClass().getResourceAsStream(CHANGESUMMARY_SIMPLE_XML)) .getRootObject(); --- java.lang.ExceptionInInitializerError at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDocumentRoot(ModelFactoryImpl.java:313) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createGen(ModelFactoryImpl.java:106) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.create(ModelFactoryImpl.java:120) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:784) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:1938) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(XMLHandler.java:1214) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1152) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1234) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:872) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:854) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:626) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:264) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:235) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:213) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:72) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:66) at org.apache.tuscany.sdo.test.DataObjectChangeSummaryTestCase.testObtainChangeSummaryFromSimple(DataObjectChangeSummaryTestCase.java:174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at
[jira] Updated: (TUSCANY-670) SDO spi to cause serialization of dynamically created Types
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ] Yang ZHONG updated TUSCANY-670: --- Attachment: SerializeTypes.670 See following attachment for a Test Case SDO spi to cause serialization of dynamically created Types --- Key: TUSCANY-670 URL: http://issues.apache.org/jira/browse/TUSCANY-670 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Kevin Williams Attachments: SerializeTypes.670, SerializeTypesTestCase.java The RDB DAS needs an SPI to indicate that the Types generated by the DAS will be serialized along with the data graph -- 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-670) SDO spi to cause serialization of dynamically created Types
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ] Yang ZHONG updated TUSCANY-670: --- Attachment: SerializeTypesTestCase.java Please add into the version control: tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test SDO spi to cause serialization of dynamically created Types --- Key: TUSCANY-670 URL: http://issues.apache.org/jira/browse/TUSCANY-670 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Kevin Williams Attachments: SerializeTypes.670, SerializeTypesTestCase.java The RDB DAS needs an SPI to indicate that the Types generated by the DAS will be serialized along with the data graph -- 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-702) Provide updated contents for DAS website page and create new DAS Java Overview website page
Provide updated contents for DAS website page and create new DAS Java Overview website page --- Key: TUSCANY-702 URL: http://issues.apache.org/jira/browse/TUSCANY-702 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-Mx Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Critical Fix For: Java-Mx Provide updated contents for DAS overview page Create DAS Java page with detailed contents aiming application developer interested in DAS/SDO -- 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-702) Provide updated contents for DAS website page and create new DAS Java Overview website page
[ http://issues.apache.org/jira/browse/TUSCANY-702?page=all ] Luciano Resende updated TUSCANY-702: Attachment: lresende.tuscany702.20060906.zip Updated xml files containing contents for site-author\das_index.xml and site-author\java_das_overview.xml. Please replace these files and run build to get the necessary files generated/updated in site-publish directory. Provide updated contents for DAS website page and create new DAS Java Overview website page --- Key: TUSCANY-702 URL: http://issues.apache.org/jira/browse/TUSCANY-702 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-Mx Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Critical Fix For: Java-Mx Attachments: lresende.tuscany702.20060906.zip Provide updated contents for DAS overview page Create DAS Java page with detailed contents aiming application developer interested in DAS/SDO -- 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]
DAS Website updates
I have uploaded a zip file to TUSCANY-702 where I updated the DAS overview and also create a Java DAS page contents targeting application developers with the following items : - DAS references/articles/etc - DAS key features, project structure and high level class diagram - DAS build instructions and dependencies I'd appreciate if a commiter could take a look at that and commit those changes to the website project. NOTE: The zip file on the JIRA is a replacement for the current files, and not a patch. Thanks in Advance -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Locating SCDL for include and other usages
My concrete proposal as one of the alternatives to scdlResource (pro and con varies of course), is to enhance from new URL(current, scdlLocation) // thank Jeremy for clarifying to trying other resources with the same relative path in ClassPath after the new URL fails. For other programming languages hosted by OS other than Java, native paths can be used, such as execution path for Windows and library path for UNIX. e.g. the ClassPath is dir1, dir2, jar1, jar2. and the new URL is dir1/com/example/included.scdl, we can also search for dir2/com/example/included.scdl and jar2!/com/example/included.scdl. Similarly if the new URL is jar2!/org/tuscant/system.scdl, we can search for jar1!/org/tuscant/system.scdl and dir2/org/tuscant/system.scdl too. My philosophy is to separate Business Logic from configuration such as search path and artifact repository, it would be nice if a scdl contains only contracts without any configuration which may vary on different user hosts. On 9/6/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote: I assumed with relative URLs being resolved against the location of the containing scdl resolves against the full path/URL of the containing scdl. Never mind if the assumption was wrong. I think that's the difference - relative URLs are resolved against the URL (using new URL(current, scdlLocation)) so there is no path to search. The response sounds applying relative path directly to classLoader.getResource, I wonder if that's the true intention. e.g. com/example/a.scdl includes included.scdl normally people assume com/example/included.scdl because that's normally relative means. Direct classLoader.getResource(included.scdl) does *not* meet normal expectation. For scdlResource, the value is resolved using the classpath using ClassLoader.getResource() - the value supplied is absolute as that is all that method takes. Anyway, the reason I've been trying to help is, it would be nice to keep scdl business intact, other info such as search path, repository config and so on, might need another host. Could you clarify what you mean here? I'd also add that both these mechanisms override the use of the repository. If you wanted to use that you would not use either of these but would instead supply repository metadata e.g. include name=included group=com.example version=1.0/ I see that as the norm - the scdlLocation and scdlResource variants would only be used in atypical circumstances (like when we are loading the system scdl and don't have the repo bootstrapped yet). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: Locating SCDL for include and other usages
I think Raymond and I have the same concern over this is that we basically take away from the user any control over where artifacts come from. They don't get portability because different runtimes/ hosts may interpret the attribute differently and we can't specify behaviour because the concepts may not port from one environment to another (e.g. what does classpath mean in a C++ environment). I agree that we do want to support declarative contracts but I think the way to do that is to allow a clear specification of that contract which can be ported between environments. To do that the contract must define what the user wants rather than how it is located. The parameters to the Artifact API are intended to do that, capturing name, type, version etc. all of which clearly define what artifact is needed. For things like scdlLocation and scdlResource that explicitly define how I think its important to clearly define the mechanism being used rather than conflate mechanisms (by e.g. taking a string value and then trying various mechanisms with it). Right now we only allow one to be specified. I would be OK if we allowed more than one, taking each in turn until the resource was found. However, that may be more confusing than helpful. -- Jeremy On Sep 6, 2006, at 2:30 PM, Yang ZHONG wrote: My concrete proposal as one of the alternatives to scdlResource (pro and con varies of course), is to enhance from new URL(current, scdlLocation) // thank Jeremy for clarifying to trying other resources with the same relative path in ClassPath after the new URL fails. For other programming languages hosted by OS other than Java, native paths can be used, such as execution path for Windows and library path for UNIX. e.g. the ClassPath is dir1, dir2, jar1, jar2. and the new URL is dir1/com/example/included.scdl, we can also search for dir2/com/example/included.scdl and jar2!/com/example/included.scdl. Similarly if the new URL is jar2!/org/tuscant/system.scdl, we can search for jar1!/org/tuscant/system.scdl and dir2/org/tuscant/system.scdl too. My philosophy is to separate Business Logic from configuration such as search path and artifact repository, it would be nice if a scdl contains only contracts without any configuration which may vary on different user hosts. On 9/6/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote: I assumed with relative URLs being resolved against the location of the containing scdl resolves against the full path/URL of the containing scdl. Never mind if the assumption was wrong. I think that's the difference - relative URLs are resolved against the URL (using new URL(current, scdlLocation)) so there is no path to search. The response sounds applying relative path directly to classLoader.getResource, I wonder if that's the true intention. e.g. com/example/a.scdl includes included.scdl normally people assume com/example/included.scdl because that's normally relative means. Direct classLoader.getResource(included.scdl) does *not* meet normal expectation. For scdlResource, the value is resolved using the classpath using ClassLoader.getResource() - the value supplied is absolute as that is all that method takes. Anyway, the reason I've been trying to help is, it would be nice to keep scdl business intact, other info such as search path, repository config and so on, might need another host. Could you clarify what you mean here? I'd also add that both these mechanisms override the use of the repository. If you wanted to use that you would not use either of these but would instead supply repository metadata e.g. include name=included group=com.example version=1.0/ I see that as the norm - the scdlLocation and scdlResource variants would only be used in atypical circumstances (like when we are loading the system scdl and don't have the repo bootstrapped yet). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432980
]
Robbie Minshall commented on TUSCANY-696:
-
I just wrote a quick junit test that essentially does what you do with the
company xsd and xml files as well as with the ones you originally used.
public void testXMLStreamHelper(String xsd, String xml) {
try {
URL testxmlURLx = getClass().getResource(xml);
XMLStreamReader streamReaderx =
XMLInputFactory.newInstance()
.createXMLStreamReader(testxmlURLx.openStream());
xmlStreamReader2XmlText(streamReaderx, System.out);
System.out.println();
System.out.println(=);
System.out
.println(Now run the same file with
SDO to StaX adapter (XMLStreamHelper): );
XMLHelper xmlHelper = XMLHelper.INSTANCE;
XSDHelper xsdHelper = XSDHelper.INSTANCE;
TypeHelper typeHelper = TypeHelper.INSTANCE;
// define types
List xsdTypes = xsdHelper.define(getClass()
.getResourceAsStream(xsd), null);
// obtain dataobject
DataObject rootobj = XMLHelper.INSTANCE.load(
getClass().getResourceAsStream(xml)).getRootObject();
System.out.println(Type of rootObject +
rootobj.getType().getName() );
// obtain an xml stream helper
XMLStreamHelper xmlStreamHelper = SDOUtil
.createXMLStreamHelper(typeHelper);
XMLStreamReader streamReader = xmlStreamHelper
.createXMLStreamReader(rootobj);
xmlStreamReader2XmlText(streamReader, System.out);
System.out.println();
} catch (Exception e) {
System.out.println(Exception : + e.toString());
e.printStackTrace();
fail(e.toString());
}
}
With the company xsd/xml file it ran without errors though I am unsure of the
quality of the output ( do you know where is the p0: is from )
p0:CompanyType employeeOfTheMonth=E0001 name=ACMEdepartments
number=123 location=NY name=Advanced Technologies xmlns=employees
SN=E0001 name=John Jones /employees SN=E0003 name=Jane Doe
/employees manager=true SN=E0004 name=A Varone //departments
With the XMLDocumentNoNamespaceSchemaLocation.xsd and XMLDocumentTestCase.xml I
got a java.lang.NullPointerException calling xsr.getEventType() in the switch
statement.The rootObject is getting returned as AnyTypeDataObject.
I hate xml so will need to read study the NoNameSpace xsd some more ( might get
to it tomorrow afternoon some time ) . . . are you wanting to pursue using
this xsd and xml or make some progress using another schema and data ?
Robbie
XMLStreamHelper usage
-
Key: TUSCANY-696
URL: http://issues.apache.org/jira/browse/TUSCANY-696
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Environment: Windows XP, java version 1.5.0_07 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
Reporter: Scott Boag
Attachments: SimpleRun2.java,
XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml
Not sure if this is a bug or user problem or both. I am trying to work on a
generic lossless adapter from SDO to a XML data model, without intervening
serialization.
I'm running the following code:
XMLHelper xmlHelper = XMLHelper.INSTANCE;
XSDHelper xsdHelper = XSDHelper.INSTANCE;
TypeHelper typeHelper = TypeHelper.INSTANCE;
URL url = SimpleRun2.class.getClassLoader().getResource(
NNS_SCHEMA_LOCATION);
List xsdTypes = xsdHelper
.define(url.openStream(), url.toExternalForm());
// InputStream is = new FileInputStream(TEST_XML_DOCUMENT);
URL testxmlURL = SimpleRun2.class.getClassLoader().getResource(
TEST_XML_DOCUMENT);
XMLDocument doc = xmlHelper.load(testxmlURL.openStream());
DataObject rootobj = doc.getRootObject();
// typeHelper.define(xsdTypes);
XMLStreamHelper xmlStreamHelper = SDOUtil
[jira] Updated: (TUSCANY-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=all ] Robbie Minshall updated TUSCANY-696: Attachment: robbieResults_1.txt attached junit update for initial test run that I executed. XMLStreamHelper usage - Key: TUSCANY-696 URL: http://issues.apache.org/jira/browse/TUSCANY-696 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Environment: Windows XP, java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) Reporter: Scott Boag Attachments: robbieResults_1.txt, SimpleRun2.java, XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml Not sure if this is a bug or user problem or both. I am trying to work on a generic lossless adapter from SDO to a XML data model, without intervening serialization. I'm running the following code: XMLHelper xmlHelper = XMLHelper.INSTANCE; XSDHelper xsdHelper = XSDHelper.INSTANCE; TypeHelper typeHelper = TypeHelper.INSTANCE; URL url = SimpleRun2.class.getClassLoader().getResource( NNS_SCHEMA_LOCATION); List xsdTypes = xsdHelper .define(url.openStream(), url.toExternalForm()); // InputStream is = new FileInputStream(TEST_XML_DOCUMENT); URL testxmlURL = SimpleRun2.class.getClassLoader().getResource( TEST_XML_DOCUMENT); XMLDocument doc = xmlHelper.load(testxmlURL.openStream()); DataObject rootobj = doc.getRootObject(); // typeHelper.define(xsdTypes); XMLStreamHelper xmlStreamHelper = SDOUtil .createXMLStreamHelper(typeHelper); XMLStreamReader streamReader = xmlStreamHelper .createXMLStreamReader(rootobj); xmlStreamReader2XmlText(streamReader, System.out); (xmlStreamReader2XmlText is just a utility method I lifted from somewhere) Raymond told me in a private exchange that I needed to do TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation); (though that implies that I know ahead of time the schema). Since TypeHelper doesn't have a define that takes the schema, I assume the above is what he meant. If I pass the result of the xsdHelper.define to typeHelper.define, it crashes in spectacular ways. When I run this code, the result is: p0:AnyTypeDataObject Which is clearly wrong. I've included the complete program. -- 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]
[SDO] TypeHelper.define returning DocumentRoot Type
TypeHelper.define is returning the DocumentRoot Type within the List of defined Types. I am assuming that it should not do so but should rather just return a list of the SDO Types defined in the xsd. Please correct me if I am wrong here but otherwise I will open a JIRA and put in a fix tomorrow sometime. Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Updated: (TUSCANY-670) SDO spi to cause serialization of dynamically created Types
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ] Yang ZHONG updated TUSCANY-670: --- Attachment: SerializeTypes.670 The full path version of the patch SDO spi to cause serialization of dynamically created Types --- Key: TUSCANY-670 URL: http://issues.apache.org/jira/browse/TUSCANY-670 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Kevin Williams Attachments: SerializeTypes.670, SerializeTypes.670, SerializeTypesTestCase.java The RDB DAS needs an SPI to indicate that the Types generated by the DAS will be serialized along with the data graph -- 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-703) Update to website
Update to website - Key: TUSCANY-703 URL: http://issues.apache.org/jira/browse/TUSCANY-703 Project: Tuscany Issue Type: Improvement Components: Website Reporter: David Wheeler Fixes: Title backgrounds in IE now display properly. Removed red background from top bar when loading. New: Tabs now change to reflect what are of the site you are viewing. Added web site editing guide. Added Tuscany C++ Setup guide. -- 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: Should we merge the databinding-framework into spi/core?
Hi, I think I'm going to leave databinding-framework as an extension for now. It won't impact the integration effort this stage. When the code becomes more mature (in terms of test coverage and functions), I'll merge it into the core/spi and the work should be very trivial. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, September 06, 2006 10:22 AM Subject: Re: Should we merge the databinding-framework into spi/core? If there are no external dependencies on databinding, my preference would be for the extension pieces to be merged with SPI and the impl to be placed in core under /services. Before that happens, though, I'd also like to see a lot more test coverage in place, particularly unit testing. Integration testing could be done whenever we get to an integration build. Jim On Sep 6, 2006, at 10:13 AM, Raymond Feng wrote: Hi, I'm in the middle of integrating databinding framework with core/ spi and it's time to make a decision on the packaging. There are two options for the databinding-framework. 1) Merge with core/spi: Move the interfaces/base classes into spi and implementation into core. 2) Keep databinding-framework as an extension. Individual databinding technology modules will stay as extensions. Please let me know your opions. Thanks, Raymond - 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]
Re: [SDO] TypeHelper.define returning DocumentRoot Type
I'm not sure about this. The DocumentRoot contains the global properties, but the current SDO spec doesn't say how they are handled. So, for now, I think it's best to leave the DocumentRoot in the list. Maybe a JIRA to track it would be good. Frank. Robbie Minshall [EMAIL PROTECTED] wrote on 09/06/2006 06:27:34 PM: TypeHelper.define is returning the DocumentRoot Type within the List of defined Types. I am assuming that it should not do so but should rather just return a list of the SDO Types defined in the xsd. Please correct me if I am wrong here but otherwise I will open a JIRA and put in a fix tomorrow sometime. Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Moving to Axis2C 0.93
Hi, I tested our C++ Web Service support with Axis2C 0.93 on Linux and it works with no code change. The only thing you need to do, after you install Axis2C 0.93 and point your AXIS2C_HOME to it, is to turn the MTOM (the SOAP Message Transmission Optimization Mechanism) support off in axis2.xml. In $AXIS2C_HOME/axis2.xml, change: parameter name=enableMTOM locked=falsetrue/parameter to parameter name=enableMTOM locked=falsefalse/parameter If you don't change that setting Axis2C will send your SOAP messages in binary form in a Mime Multipart/Related XOP package and the external Web Services that we're using in Bigbank and other samples do not like that at all :) I suggest that we switch to Axis2C 0.93 now since (1) 0.92 is not on the download mirrors anymore and (2) 0.93 brings us support for REST / HTTP GET. Could one of you running Visual Studio 6 or 7 please give it a try on Windows? I can help test on Windows as well, but only once we get the Visual Studio Express 2005 build working... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12433000
]
Scott Boag commented on TUSCANY-696:
do you know where is the p0: is from
It's a manufactured prefix, 'cause the SDO lost the prefix info I think, which
would be sortof OK (maybe not for some applications) if it put in a namespace
binding for p0.
I ran your code on company.xml and am still just getting:
p0:AnyTypeDataObject
(same as with my code).
so my configuration must be off or different from yours. I downloaded the head
yesterday, and am running in Eclipse, following the instructions at
http://wiki.apache.org/ws/Tuscany/TuscanyJava/GetTuscany.
Any ideas?
I got a java.lang.NullPointerException calling xsr.getEventType() in the
switch statement.
I had to add the TEXT_STATE event to get past this:
public int getEventType() {
if (state == START_ELEMENT_STATE) {
return START_ELEMENT;
} else if (state == END_ELEMENT_STATE) {
return END_ELEMENT;
} else if (state == TEXT_STATE) {
return CHARACTERS;
} else { // this is the delegated state
return childReader.getEventType();
}
}
are you wanting to pursue using this xsd and xml or make some progress using
another schema and data ?
I care not a nit about the particular xsd and xml, except if it fails on any
valid XML it's a problem. I'm trying to work on a generic DataObject to XML
data model adapter for XSLT, for use in BPEL. I first want to see how the
XMLStreamHelper does when the source is XML, then I want to see what it does
with non-XML sources. Then at some point, I have to investigate the other end,
going from SAX events to SDO.
If I can get started on what's going on, I may be able to help on some of the
issues with XMLStreamHelper. Right now I want to make sure I don't have any
configuration issues and I'm not doing anything stupid in regards to my test
code.
-scott
XMLStreamHelper usage
-
Key: TUSCANY-696
URL: http://issues.apache.org/jira/browse/TUSCANY-696
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Environment: Windows XP, java version 1.5.0_07 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
Reporter: Scott Boag
Attachments: robbieResults_1.txt, SimpleRun2.java,
XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml
Not sure if this is a bug or user problem or both. I am trying to work on a
generic lossless adapter from SDO to a XML data model, without intervening
serialization.
I'm running the following code:
XMLHelper xmlHelper = XMLHelper.INSTANCE;
XSDHelper xsdHelper = XSDHelper.INSTANCE;
TypeHelper typeHelper = TypeHelper.INSTANCE;
URL url = SimpleRun2.class.getClassLoader().getResource(
NNS_SCHEMA_LOCATION);
List xsdTypes = xsdHelper
.define(url.openStream(), url.toExternalForm());
// InputStream is = new FileInputStream(TEST_XML_DOCUMENT);
URL testxmlURL = SimpleRun2.class.getClassLoader().getResource(
TEST_XML_DOCUMENT);
XMLDocument doc = xmlHelper.load(testxmlURL.openStream());
DataObject rootobj = doc.getRootObject();
// typeHelper.define(xsdTypes);
XMLStreamHelper xmlStreamHelper = SDOUtil
.createXMLStreamHelper(typeHelper);
XMLStreamReader streamReader = xmlStreamHelper
.createXMLStreamReader(rootobj);
xmlStreamReader2XmlText(streamReader, System.out);
(xmlStreamReader2XmlText is just a utility method I lifted from somewhere)
Raymond told me in a private exchange that I needed to do
TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation);
(though that implies that I know ahead of time the schema). Since TypeHelper
doesn't have a define that takes the schema, I assume the above is what he
meant. If I pass the result of the xsdHelper.define to typeHelper.define, it
crashes in spectacular ways.
When I run this code, the result is:
p0:AnyTypeDataObject
Which is clearly wrong. I've included the complete program.
--
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
Re: Should we merge the databinding-framework into spi/core?
On Sep 6, 2006, at 3:51 PM, Raymond Feng wrote: Hi, I think I'm going to leave databinding-framework as an extension for now. It won't impact the integration effort this stage. When the code becomes more mature (in terms of test coverage and functions), I'll merge it into the core/spi and the work should be very trivial. O.K let me know if I can help with anything. Jim Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, September 06, 2006 10:22 AM Subject: Re: Should we merge the databinding-framework into spi/core? If there are no external dependencies on databinding, my preference would be for the extension pieces to be merged with SPI and the impl to be placed in core under /services. Before that happens, though, I'd also like to see a lot more test coverage in place, particularly unit testing. Integration testing could be done whenever we get to an integration build. Jim On Sep 6, 2006, at 10:13 AM, Raymond Feng wrote: Hi, I'm in the middle of integrating databinding framework with core/ spi and it's time to make a decision on the packaging. There are two options for the databinding-framework. 1) Merge with core/spi: Move the interfaces/base classes into spi and implementation into core. 2) Keep databinding-framework as an extension. Individual databinding technology modules will stay as extensions. Please let me know your opions. Thanks, Raymond - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-670) SDO spi to cause serialization of dynamically created Types
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ] Frank Budinsky resolved TUSCANY-670. Resolution: Fixed Fixed in revision 440915. SDO spi to cause serialization of dynamically created Types --- Key: TUSCANY-670 URL: http://issues.apache.org/jira/browse/TUSCANY-670 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Kevin Williams Attachments: SerializeTypes.670, SerializeTypes.670, SerializeTypesTestCase.java The RDB DAS needs an SPI to indicate that the Types generated by the DAS will be serialized along with the data graph -- 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]
Yet another eclipse problem, was: svn commit: r440909...
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=revrev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
rant
Specifically, Eclipse can't handle it - some other IDEs (cough) don't
have that problem. The result of this is that we end up with version
information referenced in many files rather than one which is not
very pleasant.
We made a decision early in the project that we would not tie
ourselves to one IDE but we continue to work around issues/defects
with Eclipse. These workarounds are not maintainable in an open
project where people are free to use different development tools as a
developer has no way of knowing if a change may break someone else's
tool.
Rather than continue down this path I would like to suggest that we
allow IDE configurations to be checked into SVN on the understanding
that they are not part of the project and that changes to the Maven
build or project structure may break them at any time and that it is
down to some committer using that particular IDE to make it work again.
Alternatively, if we want to keep the policy of no-IDE-specific
artifacts at all, then we should bite the bullet on workarounds and
say that the Maven build is definitive and that IDE setup is the
responsibility of each developer - i.e. they need to set their IDE to
work with the environment as defined by the Maven build.
/rant
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[C++] SDO can't load an XML doc with no namespace
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]
[jira] Assigned: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ] Jeremy Boynes reassigned TUSCANY-699: - Assignee: Jeremy Boynes Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Assigned To: Jeremy Boynes Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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++] Initial REST support
With the few minor changes that I just checked in, and thanks to Axis2C 0.93, any SCA component deployed to Axis2 can now be invoked directly from your Web browser using REST / HTTP GET style. Here is how to do it with the Calculator sample (the steps are for Linux, should be very similar on Windows). - Install Axis2C 0.93 and point your $AXIS2C_HOME to axis2c and LD_LIBRARY_PATH to axis2c/lib. - Configure axis2c/axis2.xml as follows: parameter name=enableMTOM locked=falsefalse/parameter parameter name=enableREST locked=falsetrue/parameter - Build SDO, SCA and the samples as usual. - Deploy the Calculator and the BigBank samples to axis2c as usual (create directories for Calculator and BigBank under axis2c/services, containing the services.xml and the shared library for each sample). - Start axis2c/bin/axis2_http_server. - Point your Web browser to http://localhost:9090/axis2/services/CalculatorService/add?param1=10param2=20. You should receive an XML response: result xsi:type=result data3.000e+01/data /result That's it... you've invoked an SCA program the REST way, just from your Web browser. This initial REST support only works on the server side for now, but it allows you to use SCA to publish REST services/resources. If anybody has time to work on REST, it shouldn't be difficult to add the client side support using the new options in Axis2C 0.93 and nice new samples to demonstrate more real REST patterns as we discussed on this list last week. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=revrev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
rant
Specifically, Eclipse can't handle it - some other IDEs (cough)
don't have that problem. The result of this is that we end up with
version information referenced in many files rather than one which
is not very pleasant.
We made a decision early in the project that we would not tie
ourselves to one IDE but we continue to work around issues/defects
with Eclipse. These workarounds are not maintainable in an open
project where people are free to use different development tools as
a developer has no way of knowing if a change may break someone
else's tool.
Rather than continue down this path I would like to suggest that we
allow IDE configurations to be checked into SVN on the
understanding that they are not part of the project and that
changes to the Maven build or project structure may break them at
any time and that it is down to some committer using that
particular IDE to make it work again.
I think this is asking for trouble for several reasons. We really
should have one definitive source for the build. These artifacts are
bound to break and there is no realistic way to verify that they work
short of loading them in the tool they were intended for.
Alternatively, if we want to keep the policy of no-IDE-specific
artifacts at all, then we should bite the bullet on workarounds and
say that the Maven build is definitive and that IDE setup is the
responsibility of each developer - i.e. they need to set their IDE
to work with the environment as defined by the Maven build.
I prefer the current policy of having Maven categorically determine
the state of the build. My opinion is we should not allow checkins of
unverifiable artifacts.
Jim
/rant
--
Jeremy
-
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]
Mac OS X port, was [C++] Build instructions on Web site
Oisin Hurley wrote: [snip] BTW - has anyone done a port to MacOS X 10.4.7 ppc? If not I will get a start on it - not vital for the roadmap, but it is my machine of choice and I'll get nothing done if it doesn't work there ;) Hi Oisin, Did you get a chance to look into the MacOS X port? I have an iBook with 10.4.7 ppc Mac OS X here and was wondering if you had a patch to the Makefiles that I could try. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet another eclipse problem, was: svn commit: r440909...
On Sep 6, 2006, at 8:18 PM, Jim Marino wrote:
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=revrev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
rant
Specifically, Eclipse can't handle it - some other IDEs (cough)
don't have that problem. The result of this is that we end up with
version information referenced in many files rather than one which
is not very pleasant.
We made a decision early in the project that we would not tie
ourselves to one IDE but we continue to work around issues/defects
with Eclipse. These workarounds are not maintainable in an open
project where people are free to use different development tools
as a developer has no way of knowing if a change may break someone
else's tool.
Rather than continue down this path I would like to suggest that
we allow IDE configurations to be checked into SVN on the
understanding that they are not part of the project and that
changes to the Maven build or project structure may break them at
any time and that it is down to some committer using that
particular IDE to make it work again.
I think this is asking for trouble for several reasons. We really
should have one definitive source for the build. These artifacts
are bound to break and there is no realistic way to verify that
they work short of loading them in the tool they were intended for.
There is still only one definitive build - the Maven one. All the
others are just (unverifiable) artifacts that may work for some
developers. The compensating factor here is that presumably some
active developers are using them and will keep them current and working.
Alternatively, if we want to keep the policy of no-IDE-specific
artifacts at all, then we should bite the bullet on workarounds
and say that the Maven build is definitive and that IDE setup is
the responsibility of each developer - i.e. they need to set their
IDE to work with the environment as defined by the Maven build.
I prefer the current policy of having Maven categorically determine
the state of the build. My opinion is we should not allow checkins
of unverifiable artifacts.
The problem is that we have requirements on checked in artifacts (the
Maven POM's) that are not verifiable using the Maven build -
requirements such as we can't use Maven's resource filtering because
Eclipse also copies resources and does not filter them, or Eclipse
cannot support the resource paths that Maven uses. There may be
others (for example, I don't know how or if Eclipse recognizes code
generated as part of the Maven build).
This means people can make improvements to the build or project
layout that are fine with Maven and the definitive build but which,
for some reason, make Eclipse unhappy.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Exception in SDO runtime on Windows, was: [C++] windows build system
Jean-Sebastien Delfino wrote:
[snip]
I just tried it and was able to import our VC7 solution into it. I ran
into two issues:
- A minor issue, I had to remove the ODBC libraries from the link
configuration
- A more serious issue, the SDO runtime breaks with exceptions
complaining about incompatible list iterators in
DataObjectImpl::~DataObjectImpl()
This is probably easy to fix - although I have no idea how to fix it :)
Geoff,
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...
Could you please take a look and see if there's a quick fix for this?
Thanks.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-698) First pass PHP extension for C++ SCA
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ] Jean-Sebastien Delfino resolved TUSCANY-698. Resolution: Fixed Assignee: Jean-Sebastien Delfino Committed the patch, Thanks! I guess we can close this one we'll create many other JIRAs for build integration, further improvements etc. 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]
Re: Yet another eclipse problem, was: svn commit: r440909...
I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for. There is still only one definitive build - the Maven one. All the others are just (unverifiable) artifacts that may work for some developers. The compensating factor here is that presumably some active developers are using them and will keep them current and working. I'm not sure it's definitive anymore due to all of the hidden requirements you mentioned below...Hoping people keep artifacts up to date is what I don't like as they will invariably break since they are not verifiable. Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build. I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts. The problem is that we have requirements on checked in artifacts (the Maven POM's) that are not verifiable using the Maven build - requirements such as we can't use Maven's resource filtering because Eclipse also copies resources and does not filter them, or Eclipse cannot support the resource paths that Maven uses. There may be others (for example, I don't know how or if Eclipse recognizes code generated as part of the Maven build). That to me just seems wrong. We chose Maven to be our build system and we should use its features. If a particular IDE can't handle a basic thing thing such as resource filtering we shouldn't be restricted by that limitation as long as there are reasonable alternatives (and there are, e.g. IntelliJ; I switched exactly because of these types of issues :-) ). Besides, checkins have to be run through the mvn command line build process, not through an IDE. Jim This means people can make improvements to the build or project layout that are fine with Maven and the definitive build but which, for some reason, make Eclipse unhappy. -- Jeremy - 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]
Re: [jira] Updated: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
Thanks for the patch Andy. I do have a few comments that I hope you can address :-) Would it be possible to break this down a little - there are changes in there to the startup code and to the Spring container - is it possible to separate those so that there is less to tackle in one go? For example, are the startup changes really coupled to renaming the SpringSCA XSD? Some of the changes seem cosmetic (e.g. JavaDoc changes) and these really are easier to review if kept separate. Also some of the changes don't seem to fit our coding style guidelines. I know we're often lax about that but I felt I should mention it as we're actively trying to improve. You can check this fairly easily using the sourcecheck profile in Maven (mvn -o - Psourcecheck). On a legal front, please can you make sure new files have the correct header block on them (the new one without a (c) statement). Apache also prefers that files do not contain @author tags we are following that guideline. We've tried real hard to avoid a dependency on a particular logging framework, clogging in particular due to the conflicts that occur between different projects (for example, you're including 1.1 but some of our other dependencies are using older versions). Getting to the technical stuff, the big question I have is about passing in a Map of properties. This seems to go against the IoC principles of SCA, Tuscany and Spring. Did you consider extending RuntimeInfo e.g. as SpringRuntimeInfo, adding in something like getApplicationContext() ? Or perhaps better, adding the ApplicationContext as a component in the runtime that could be directly used as a dependency? Once again, thanks for the patch. If you do get a chance to look at a couple of these things I'll be online tomorrow and able to help get the changes in. -- Jeremy On Sep 6, 2006, at 11:28 AM, Andy Piper (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ] Andy Piper updated TUSCANY-699: --- Attachment: springlaunch.patch Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
