[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Murphy updated TUSCANY-1048: Attachment: TUSCANY-1048-20070131-dm.patch Right - this was generated with eclipse, so has the new files also (the previous one generated from cmd line only had old files) SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Fix For: Java-SDO-Mx Attachments: patch070129.txt, patch20070124.txt, TUSCANY-1048-20070131-dm.patch, TUSCANY-1048-dm-20073001.patch, TUSCANY-1048-gmw.patch, tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] scagen question
I don't I'm afraid, SCAGEN works fine on the CppCalculator sample on both my Windows and Linux boxes (IBM JRE 1.5.0 and IBM JRE 1.4.2 respectively). I remember having some troubles when I tried IBM JRE 1.5.0 on Linux a while back - but I can't really remember the details, and I don't think it was SCAGEN specific. Cheers Andy. On 1/30/07, Simon Laws [EMAIL PROTECTED] wrote: Any idea what is wrong with my installation when I get java -jar /usr/local/tuscany/cpp/sca/deploy/bin/scagen.jar -dir . -output . java.lang.NullPointerException at java.io.File.init(File.java:303) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.processComponentNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown Source)at org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.Scagen.main(Unknown Source) Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] scagen question
We used to get an NPE when running scagen against one sample. It did not affect the output though! It may have been down to invalid scdl?? Cheers, On 31/01/07, Andrew Borley [EMAIL PROTECTED] wrote: I don't I'm afraid, SCAGEN works fine on the CppCalculator sample on both my Windows and Linux boxes (IBM JRE 1.5.0 and IBM JRE 1.4.2 respectively). I remember having some troubles when I tried IBM JRE 1.5.0 on Linux a while back - but I can't really remember the details, and I don't think it was SCAGEN specific. Cheers Andy. On 1/30/07, Simon Laws [EMAIL PROTECTED] wrote: Any idea what is wrong with my installation when I get java -jar /usr/local/tuscany/cpp/sca/deploy/bin/scagen.jar -dir . -output . java.lang.NullPointerException at java.io.File.init(File.java:303) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.processComponentNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown Source)at org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.Scagen.main(Unknown Source) Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
[jira] Updated: (TUSCANY-1081) SDO CTS - Tuscany specific project
[ https://issues.apache.org/jira/browse/TUSCANY-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Murphy updated TUSCANY-1081: Attachment: TUSCANY-1081-20070131.patch Updated patch to include svn properties... use this one and ignore the others SDO CTS - Tuscany specific project -- Key: TUSCANY-1081 URL: https://issues.apache.org/jira/browse/TUSCANY-1081 Project: Tuscany Issue Type: New Feature Components: Java SDO Community Test Suite Affects Versions: Java-SDO-Mx Reporter: Dan Murphy Priority: Critical Attachments: TUSCANY-1081-20070131.patch, TUSCANY-1081.patch, TUSCANY-1081.zip The SDO 2.1 CTS project is implementation independent. This project will contain a test execution environment for Tuscany and any implementation dependent resources (eg. statically generated SDOs required by the test suite). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] scagen question
On 1/31/07, Pete Robbins [EMAIL PROTECTED] wrote: We used to get an NPE when running scagen against one sample. It did not affect the output though! It may have been down to invalid scdl?? Cheers, On 31/01/07, Andrew Borley [EMAIL PROTECTED] wrote: I don't I'm afraid, SCAGEN works fine on the CppCalculator sample on both my Windows and Linux boxes (IBM JRE 1.5.0 and IBM JRE 1.4.2 respectively). I remember having some troubles when I tried IBM JRE 1.5.0 on Linux a while back - but I can't really remember the details, and I don't think it was SCAGEN specific. Cheers Andy. On 1/30/07, Simon Laws [EMAIL PROTECTED] wrote: Any idea what is wrong with my installation when I get java -jar /usr/local/tuscany/cpp/sca/deploy/bin/scagen.jar -dir . -output . java.lang.NullPointerException at java.io.File.init(File.java:303) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.processComponentNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown Source)at org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree (Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.Scagen.main (Unknown Source) Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete Ok, thanks for looking guys. I'll investigate further. Simon
[jira] Resolved: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn resolved TUSCANY-1048. - Resolution: Fixed Patch applied SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Fix For: Java-SDO-Mx Attachments: patch070129.txt, patch20070124.txt, TUSCANY-1048-20070131-dm.patch, TUSCANY-1048-dm-20073001.patch, TUSCANY-1048-gmw.patch, tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build failure in sca/services/persistence
Looks like this test case hasn't been updated and still tries to use BoundReferenceDefinition --- T E S T S --- Running org.apache.tuscany.persistence.datasource.ProviderObjectFactoryTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec Running org.apache.tuscany.persistence.datasource.integration.ProviderBootstrapT estCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.221 sec FA ILURE! testBoot( org.apache.tuscany.persistence.datasource.integration.ProviderBootstrap TestCase) Time elapsed: 1.211 sec ERROR! java.lang.NoClassDefFoundError: org/apache/tuscany/spi/model/BoundReferenceDefin ition at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.getDeclaredMethods(Class.java:1763) at org.apache.tuscany.core.util.JavaIntrospectionHelper.getAllUniqueMeth ods(JavaIntrospectionHelper.java:92) at org.apache.tuscany.core.util.JavaIntrospectionHelper.getAllUniquePubl icProtectedMethods(JavaIntrospectionHelper.java:81) at org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.intr ospect(IntrospectionRegistryImpl.java:87) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:93) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.load(SystemComponentTypeLoader.java:74) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.load(SystemComponentTypeLoader.java:46) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L oaderRegistryImpl.java:156) at org.apache.tuscany.core.implementation.system.loader.SystemImplementa tionLoader.load(SystemImplementationLoader.java:60) at org.apache.tuscany.core.implementation.system.loader.SystemImplementa tionLoader.load(SystemImplementationLoader.java:43) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation (Com ponentLoader.java:176) at org.apache.tuscany.core.loader.ComponentLoader.load( ComponentLoader.j ava:111) at org.apache.tuscany.core.loader.ComponentLoader.load( ComponentLoader.j ava:80) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:64) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:102) at org.apache.tuscany.core.loader.IncludeLoader.loadFromSidefile (Include Loader.java:109) at org.apache.tuscany.core.loader.IncludeLoader.load( IncludeLoader.java: 92) at org.apache.tuscany.core.loader.IncludeLoader.load( IncludeLoader.java: 50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:64) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:102) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeC omponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java :68) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeC omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeC omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L oaderRegistryImpl.java:156) at org.apache.tuscany.core.deployer.DeployerImpl.load( DeployerImpl.java: 127) at org.apache.tuscany.core.deployer.DeployerImpl.deploy( DeployerImpl.jav a:92) at org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime (LauncherImp l.java:115) at org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime (LauncherImp l.java:180) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:75) at org.apache.tuscany.persistence.datasource.integration.ProviderBootstr apTestCase.setUp(ProviderBootstrapTestCase.java:47)
[jira] Resolved: (TUSCANY-1081) SDO CTS - Tuscany specific project
[ https://issues.apache.org/jira/browse/TUSCANY-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn resolved TUSCANY-1081. - Resolution: Fixed Patch applied SDO CTS - Tuscany specific project -- Key: TUSCANY-1081 URL: https://issues.apache.org/jira/browse/TUSCANY-1081 Project: Tuscany Issue Type: New Feature Components: Java SDO Community Test Suite Affects Versions: Java-SDO-Mx Reporter: Dan Murphy Priority: Critical Attachments: TUSCANY-1081-20070131.patch, TUSCANY-1081.patch, TUSCANY-1081.zip The SDO 2.1 CTS project is implementation independent. This project will contain a test execution environment for Tuscany and any implementation dependent resources (eg. statically generated SDOs required by the test suite). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure in sca/services/persistence
Same for this test case in sca/extensions/javascript --- T E S T S --- Running org.apache.tuscany.container.javascript.utils.xmlfromxsd.XMLfromXSDGener atorTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.132 sec Running org.apache.tuscany.container.javascript.rhino.RhinoScriptTestCase Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.251 sec Running org.apache.tuscany.container.javascript.function.ScopeTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.19 sec FAI LURE! testStateless(org.apache.tuscany.container.javascript.function.ScopeTestCase) T ime elapsed: 0.17 sec ERROR! java.lang.NoClassDefFoundError: org/apache/tuscany/spi/model/BoundReferenceDefin ition at org.apache.tuscany.core.bootstrap.DefaultBootstrapper.createLoader(De faultBootstrapper.java:194) at org.apache.tuscany.core.bootstrap.DefaultBootstrapper.createDeployer( DefaultBootstrapper.java:146) at org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime (LauncherImp l.java:85) at org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime (LauncherImp l.java:180) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:75) at org.apache.tuscany.container.javascript.function.ScopeTestCase.setUp( ScopeTestCase.java:40) On 1/31/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Looks like this test case hasn't been updated and still tries to use BoundReferenceDefinition --- T E S T S --- Running org.apache.tuscany.persistence.datasource.ProviderObjectFactoryTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec Running org.apache.tuscany.persistence.datasource.integration.ProviderBootstrapT estCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.221 sec FA ILURE! testBoot( org.apache.tuscany.persistence.datasource.integration.ProviderBootstrap TestCase) Time elapsed: 1.211 sec ERROR! java.lang.NoClassDefFoundError: org/apache/tuscany/spi/model/BoundReferenceDefin ition at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.getDeclaredMethods(Class.java:1763) at org.apache.tuscany.core.util.JavaIntrospectionHelper.getAllUniqueMeth ods(JavaIntrospectionHelper.java:92) at org.apache.tuscany.core.util.JavaIntrospectionHelper.getAllUniquePubl icProtectedMethods(JavaIntrospectionHelper.java :81) at org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.intr ospect(IntrospectionRegistryImpl.java:87) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:93) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.load(SystemComponentTypeLoader.java:74) at org.apache.tuscany.core.implementation.system.loader.SystemComponentT ypeLoader.load(SystemComponentTypeLoader.java:46) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L oaderRegistryImpl.java:156) at org.apache.tuscany.core.implementation.system.loader.SystemImplementa tionLoader.load(SystemImplementationLoader.java:60) at org.apache.tuscany.core.implementation.system.loader.SystemImplementa tionLoader.load(SystemImplementationLoader.java:43) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:84) at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com ponentLoader.java:176) at org.apache.tuscany.core.loader.ComponentLoader.load( ComponentLoader.j ava:111) at org.apache.tuscany.core.loader.ComponentLoader.load( ComponentLoader.j ava:80) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:64) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:102) at org.apache.tuscany.core.loader.IncludeLoader.loadFromSidefile(Include Loader.java:109) at org.apache.tuscany.core.loader.IncludeLoader.load( IncludeLoader.java: 92) at org.apache.tuscany.core.loader.IncludeLoader.load( IncludeLoader.java: 50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load (LoaderRegistry Impl.java:84) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:90) at
Re: Moving modules around in trunk
Are you still planning on do anything like this? I would help but its not clear to me what you want to move where? ...ant On 1/27/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Rick pinged me tonight about problems building from the sca directory. It turns out modules that build on their own can fail if run as part of a reactor run as mvn gets confused over whether it should be using the pre-spec tree or trunk. Unless someone beats me to it, I intend to fix that tomorrow by moving some of the modules around so there is a clear distinction between kernel, runtime and runtime services, and extensions. The first two will be the same modules currently in pre-spec and the extensions will depend on those (so its easy for an extension to choose if it depends on trunk or pre-spec). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up, snapshot of kernel
No comments on this so I've added idl.wsdl to the pre-spec-changes branch and published it to the snapshot repo. ...ant On 1/25/07, ant elder [EMAIL PROTECTED] wrote: Should idl/wsdl be included in the pre-spec snapshot or should it be using the pre-spec snapshots? ...ant On 1/24/07, Jim Marino [EMAIL PROTECTED] wrote: All, I have begun the process of modularizing the build by creating and publishing the kernel snapshot extensions will reference. The snapshot source has been branched under /pre-spec-changes. I will update the extensions to point to the snapshot. After this is done, we can reorganize the build tree to group extensions by distribution. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up, snapshot of kernel
This is fixed now, Rick's fixed the code and republished it to the snapshot repo. ...ant On 1/25/07, ant elder [EMAIL PROTECTED] wrote: Another issue is that the 0.1-pre-spec-SNAPSHOT version of the tuscany-war-plugin is hardcoded to use the 1.0-incubator-SNAPSHOT of webapp-host. Looks like there is a similar issue with our M2 release using 1.0-incubator-M2-SNAPSHOT . ...ant On 1/25/07, ant elder [EMAIL PROTECTED] wrote: Should idl/wsdl be included in the pre-spec snapshot or should it be using the pre-spec snapshots? ...ant On 1/24/07, Jim Marino [EMAIL PROTECTED] wrote: All, I have begun the process of modularizing the build by creating and publishing the kernel snapshot extensions will reference. The snapshot source has been branched under /pre-spec-changes. I will update the extensions to point to the snapshot. After this is done, we can reorganize the build tree to group extensions by distribution. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1021) CopyHelper and EqualityHelper should handle ChangeSummary
[ https://issues.apache.org/jira/browse/TUSCANY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469105 ] Kelvin Goodson commented on TUSCANY-1021: - The commit made 11th Jan (see Subversion Commits tab) is a partial fix, awaiting completion of the serialization/deserialization work in TUSCANY-153. CopyHelper and EqualityHelper should handle ChangeSummary - Key: TUSCANY-1021 URL: https://issues.apache.org/jira/browse/TUSCANY-1021 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx ChangeSummary can now be any DataObject attribute, and it's stale through EMF API. Currently, CopyHelper and EqualityHelper heavily depend on EMF. That needs to be patched to support ChangeSummary at any DataObject depth and its summarization if necessary. FYI, 859 has introduced an effort to make ChangeSummary never stale through *SDO* API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-547) Discriminated types
[ https://issues.apache.org/jira/browse/TUSCANY-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn updated TUSCANY-547: --- Attachment: TUSCANY-SDOValue.patch The attached patch is a first draft of a sizeable revision of SDO to eliminate a good deal of macro code. This particular patch will not be applied to the repository (since it hasn't been tried on Linux yet, for example) but if anyone would like to try it then I'd appreciate the feedback. In theory the external behaviour of SDO hasn't changed. in practice there are bound to be a few places where things hav ealtered a bit, the areas most at risk are a) Exceptions thrown in case of problems may occur at different points, so from a users point of view may be thrown sooner or later than expected. b) Data conversions may not be identical. I'll fix any of these that we find. Discriminated types --- Key: TUSCANY-547 URL: https://issues.apache.org/jira/browse/TUSCANY-547 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: all Reporter: Ed Slattery Fix For: Cpp-M3 Attachments: TUSCANY-SDOValue.patch There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object. One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter. Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type. This would reduce the codebase, make it cleaner. Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1074) Using DataFactory to create a generic data object
[ https://issues.apache.org/jira/browse/TUSCANY-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1074. - Resolution: Won't Fix I believe that this was an attempt to provide a standard way to create a generic DataObject that could be used to wrap a DataType value - for example when serializling an XML document where the root element is a simpleType. But, since DataObject is abstract, this isn't an acceptable solution. SDOUtil.createDataTypeWrapper() is the Tuscany-specific way to do this. If the SDO spec introduces a new type for this in the future, then we can use it instead of SDOUtil. Using DataFactory to create a generic data object - Key: TUSCANY-1074 URL: https://issues.apache.org/jira/browse/TUSCANY-1074 Project: Tuscany Issue Type: Task Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-Mx Before the last regeneration of ModelPackageImpl there was a use case which was supported that permitted a call to DataFactory.INSTANCE.create(commonj.sdo,DataObject); which resulted in the creation of an instance of AnyTypeDataObject in the namespace http://www.apache.org/tuscany/2005/SDO;. This was a manual fix up to the generated ModelFactoryImpl class which didn't get transferred to the new version. TUSCANY-1055 drew our attention to this, because it blocks the creation of abstract types, such as commonj.sdo,DataObject, which is the correct thing to do according to the spec. This task is to attempt to rediscover the use case that required this behaviour and rethink how to support it. A possibility is to introduce into the SDO spec the concept of a concrete type of commonj.sdo,GenericDataObject, which would be open and mixed etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP DAS
I'm looking at creating the maven project for the das interfaces right now. I think groupId: org.apache.tuscany artifactId:das makes sense for the interfaces project. Then groupId: org.apache.tuscany artifactId:das.rdb artifactId:das.ldap for the datasource specific implementations. Thoughts? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, this would be the first step and you are on the right track, if we identify others, we could continue moving them gradatively... Another think to have in mind, and I don't think I have an answer right now, is around the config model, and where is the best place for it : API project, a common impl project , or each particular backend impl. Probably API, if the models don't defer much. Any Toughts ? -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: OK - I think this is the trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb And I think these are the interfaces: -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 ConfigHelper.java -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 DASFactory.java -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java Am I on the righ track? If so, I'll move the package containing the interfaces to another maven project and submit it via JIRA? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Trunk DAS is pretty stable, unless you find any problems with it, I'd recommend staying with trunk. On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! === message truncated === 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
[jira] Created: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
Java Serialization: The Type definition is overwritten in the registry within the same scope Key: TUSCANY-1084 URL: https://issues.apache.org/jira/browse/TUSCANY-1084 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 When a DataObject is serialized using the java serialization ( ObjectOutputStream.writeObject) and deserialized back using ObjectInputStream.readObject, the types of the two dataobjects do not match, even though this all in the same scope ( global in this case ). During deserialization, it seems that the type of the dataobject cannot be found, and it is creating the type again and simply overwrites the previously registered type. This results in the dataobjects getting different types and the test case fails. There is another issue here, which is that currently there seems to be no way to provide a scope when using these java serialization methods. For instance, when using XMLHelper, you can get a scope defined XMLHelper. But how do you do this when you are using the java serialization methods ? If you want me to open another Jira for this i will. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Muhammad updated TUSCANY-1084: Attachment: JavaSerializeDeserializeTestCase.java I have attached a JUnit test case which basically creates the DataObject dynamically and then serializes it to a temp file. Then the DataObject is retrieved during the deserialization and the types of the two objects are compared resulting in the error. Java Serialization: The Type definition is overwritten in the registry within the same scope Key: TUSCANY-1084 URL: https://issues.apache.org/jira/browse/TUSCANY-1084 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 Attachments: JavaSerializeDeserializeTestCase.java When a DataObject is serialized using the java serialization ( ObjectOutputStream.writeObject) and deserialized back using ObjectInputStream.readObject, the types of the two dataobjects do not match, even though this all in the same scope ( global in this case ). During deserialization, it seems that the type of the dataobject cannot be found, and it is creating the type again and simply overwrites the previously registered type. This results in the dataobjects getting different types and the test case fails. There is another issue here, which is that currently there seems to be no way to provide a scope when using these java serialization methods. For instance, when using XMLHelper, you can get a scope defined XMLHelper. But how do you do this when you are using the java serialization methods ? If you want me to open another Jira for this i will. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1085) schemaLocation attribute in the xsd:import should be only a hint
schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Cpp-M3 Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the xsd:import should be only a hint
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1085: Attachment: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt SimpleDynamicTestCase.java simple2.xsd Oops, I specified the wrong affect version. schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Cpp-M3 Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, SimpleDynamicTestCase.java Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving modules around in trunk
I was watching what you were doing with axsi2 etc. I think you've done everything that I planned. Thanks for picking it up. -- Jeremy On Jan 31, 2007, at 7:08 AM, ant elder wrote: Are you still planning on do anything like this? I would help but its not clear to me what you want to move where? ...ant On 1/27/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Rick pinged me tonight about problems building from the sca directory. It turns out modules that build on their own can fail if run as part of a reactor run as mvn gets confused over whether it should be using the pre-spec tree or trunk. Unless someone beats me to it, I intend to fix that tomorrow by moving some of the modules around so there is a clear distinction between kernel, runtime and runtime services, and extensions. The first two will be the same modules currently in pre-spec and the extensions will depend on those (so its easy for an extension to choose if it depends on trunk or pre-spec). -- 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]
[jira] Commented: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469188 ] Frank Budinsky commented on TUSCANY-1084: - It seems like the problem is because you're passing the metadata in the DataGraph - i.e., you called SDOUtil.registerDataGraphTypes(). If you don't do that, does it work? If you pass the metadata, it would seem that you are asking it to replace it with the new version. Frank. Java Serialization: The Type definition is overwritten in the registry within the same scope Key: TUSCANY-1084 URL: https://issues.apache.org/jira/browse/TUSCANY-1084 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 Attachments: JavaSerializeDeserializeTestCase.java When a DataObject is serialized using the java serialization ( ObjectOutputStream.writeObject) and deserialized back using ObjectInputStream.readObject, the types of the two dataobjects do not match, even though this all in the same scope ( global in this case ). During deserialization, it seems that the type of the dataobject cannot be found, and it is creating the type again and simply overwrites the previously registered type. This results in the dataobjects getting different types and the test case fails. There is another issue here, which is that currently there seems to be no way to provide a scope when using these java serialization methods. For instance, when using XMLHelper, you can get a scope defined XMLHelper. But how do you do this when you are using the java serialization methods ? If you want me to open another Jira for this i will. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469196 ] Hasan Muhammad commented on TUSCANY-1084: - Yup.. That was it. I commented it out and it works now. So what about the second issue ? Is there a way to define a scope if we do serialization/deserialization through Output and InputStreams ? Java Serialization: The Type definition is overwritten in the registry within the same scope Key: TUSCANY-1084 URL: https://issues.apache.org/jira/browse/TUSCANY-1084 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 Attachments: JavaSerializeDeserializeTestCase.java When a DataObject is serialized using the java serialization ( ObjectOutputStream.writeObject) and deserialized back using ObjectInputStream.readObject, the types of the two dataobjects do not match, even though this all in the same scope ( global in this case ). During deserialization, it seems that the type of the dataobject cannot be found, and it is creating the type again and simply overwrites the previously registered type. This results in the dataobjects getting different types and the test case fails. There is another issue here, which is that currently there seems to be no way to provide a scope when using these java serialization methods. For instance, when using XMLHelper, you can get a scope defined XMLHelper. But how do you do this when you are using the java serialization methods ? If you want me to open another Jira for this i will. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469197 ] Frank Budinsky commented on TUSCANY-1084: - Re: the point about serialization/deserialization only working in the global/default scope. That's a current limitation. I guess you should open a JIRA for it. Maybe you want to implement it and also provide a patch? It's simply a matter of adding an SDOUtil.createObjectInputStream(HelperContext) method that returns a stream that also stores the context that was provided Then ResolvableImpl.readDataObject() should be changed to use the XMLHelper from that streams context, instead of the default one. The test program would be changed to get the input stream from the new SDOUtil method. Frank. Java Serialization: The Type definition is overwritten in the registry within the same scope Key: TUSCANY-1084 URL: https://issues.apache.org/jira/browse/TUSCANY-1084 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 Attachments: JavaSerializeDeserializeTestCase.java When a DataObject is serialized using the java serialization ( ObjectOutputStream.writeObject) and deserialized back using ObjectInputStream.readObject, the types of the two dataobjects do not match, even though this all in the same scope ( global in this case ). During deserialization, it seems that the type of the dataobject cannot be found, and it is creating the type again and simply overwrites the previously registered type. This results in the dataobjects getting different types and the test case fails. There is another issue here, which is that currently there seems to be no way to provide a scope when using these java serialization methods. For instance, when using XMLHelper, you can get a scope defined XMLHelper. But how do you do this when you are using the java serialization methods ? If you want me to open another Jira for this i will. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-928) Define Tuscany SDO options for XMLHelper load and save operations
[ https://issues.apache.org/jira/browse/TUSCANY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-928: --- Attachment: SDOXMLResourceImpl.java options.928 Attaching prototype. SDOXMLResourceImpl.java is also pending in http://issues.apache.org/jira/browse/TUSCANY-1082 (and 1049), so the whole file is attached instead of the patch. Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: https://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-Mx Attachments: options.928, SDOXMLResourceImpl.java XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spec api changes
In my sandbox there is a strawman API relating to proposals to the spec group for changes to the Java APIs for the spec. Some of these have been accepted by the group and so I think it is time to move this into the trunk so we can start work on implementations. I plan to rename the existing spec module to sca-api-r0.95 inline with the version it relates to and move the new code in as sca-api-r1.0 For clarity, I'll restate this is not final code as some proposals are still under consideration. Also, some parts of the API were left as implementation-defined which means there is no spec API but implementors need to provide something for users to use. To do this, I'll be adding some of that function to the tuscany-api module. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chat summary on the SCA deployment story in Tuscany
Hi, I had an offline chat with Jeremy to help myself glue a few pieces (basically a sequence of actions and participants) together so that I can see the whole picture of the SCA deployment story in Tuscany. We feel it's useful to share the information with the community. I put together a summary at http://cwiki.apache.org/confluence/display/TUSCANY/Deployment. Please review and comment. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Interface descriptions and type conversions
Simon Laws wrote: I notice in implementing the PHP extension (yes - believe it or not I'm nearly ready to make a patch for the next version ;-) that, given the way that I have implemented the PHP extension there is insufficient information available in the SCA runtime in order to do correct type conversions when passing messages between components. I imagine this has been raised before but I looked at the archive and couldn't find a relevant thread. Imagine the scenario: C++ Component (ComponentA) ---WireA--- PHP Component (ComponentB) ---WireB C++ Component (ComponentC) Currently the build process looks at the header files described in the component type files and generates wrappers and proxies for the C++ components. I have currently implemented the PHP Extension to use generic wrappers and proxies, i.e. it doesn't use those generated based on the interface descriptions, so they need to dynamically manage the type conversions for data coming in and going out of a PHP component. WireA. This is OK because the C++ SCA operation object that appears at Component B has a set of data/types based on the generated proxy. The PHP extension can look at this and effect the right type conversions. WireB This is problematic. The dynamic PHP proxy has to generate an operation object to pass to the the wrapper of ComponentC. The issue is that there is, as far as I can tell, no dynamic way of getting at the list of types that are expected for any particular operation. There is of course a static C++ proxy/wrapper combination that has been generated but I can't inspect it at runtime. I'm not keen on generating PHP specific interface classes. PHP is a dynamic environment and it's a whole stack of extra files we could do without having to manage particularly if we have to adapt the generator for every extension that's constructed. Can we extend the wrapper/proxy mechanism to encapsulate a runtime list of required types alongside the static method descriptions that are already generated? We would need this to work for script to script calls as well as for the script/C++ combination so maybe we need something that hangs off the interface description part of the model. I'm not that familiar with how that part of the model is used so a little investigation is required. Thoughts? Simon Simon, It's an interesting issue. To explore it let's walk through the wiring scenario you describe and assume the following: - ComponentA (C++) - WireA - ComponentB (PHP) - WireB - ComponentC (C++) - ComponentA (C++) passes a short int to ComponentB (PHP) - ComponentB executes a PHP script which in turn passes a number to ComponentC (C++) - ComponentC expects that number to be given as a long int. Here's what I think should happen in the runtime: 1. At the source of WireA, a generated C++ CPPServiceProxy adds to our Operation object a Parameter of a type decided by the C++ client code: a C++ short int, with type == ParameterType::SHORT. 2. At the end of WireA, a PHPServiceWrapper converts that parameter to what the PHP script expects, for the sake of simplicity now I am going to assume that it needs to convert it to a C++ std::string. 3. The PHP script executes, now passes an std::string containing a number to the PHPServiceProxy at the source of WireB. 4. The PHPServiceProxy does not have much type info about that std::string parameter and can only add it to the Operation object as a std::string with type == ParameterType::STRING. 5. The CPPServiceWrapper at the end of WireB (actually the C++ ServiceWrapper generated for ComponentC) receives the std::string and should convert it to what ComponentC expects: a long int. The general idea is that a ServiceProxy sends what it is given (or picks the most natural type out of the ParameterTypes that we have defined and converts the data to it). A ServiceWrapper converts what it receives to the type expected by the code it wraps. I think that the CPPServiceWrapper code and the generated C++ ServiceWrappers are simply missing the logic to convert data to what the target expects. At the moment this limitation also prevents a C++ method getCustomer(long customerID) to be exposed as a REST service for example, as the generated C++ ServiceWrapper is missing the logic to convert the customerID received in string form from the REST query string to the expected C++ long int. So we just need to add the missing type conversion logic to the C++ ServiceWrappers :) Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chat summary on the SCA deployment story in Tuscany
Couple of comments. I'd say they're not really phases - contributing something is independent of making changes to the assembly. The contribution process is about adding Types to the domain (composites, classes, XSD complexTypes, etc.) whereas the assembly is about creating/modifying/ removing instances of things (primarily components). Contributions are not just about SCA applications themselves but about anything that contributes function to the domain. The caching is about storing the introspection results for production artifacts that are basically versioned and immutable. This is similar in concept to the way Maven caches artifacts locally and never needs to go back to an online repo once they have been downloaded. Given some introspections are likely to be expensive (e.g. scanning an EAR to look for EJBs and then processsing the class files for annotations) it would be good to avoid redoing that when its not necessary. The idea of portable builders is about separating the node responsible for domain assembly from the nodes running component implementations. In a heterogeneous federation, it could be the assembly node(s) are running C++ but the user wants to add a Java component that will actually run on a Java node. If the introspection results for the Java contribution are portable, it would be possible for the C++ to set up the physical configuration for the Java builder; alternatively, it could delegate that to a service running in a native Java environment. Similarly, if the component was in some portable language (like Ruby or XSLT), then the configuration could be done on a Java node and passed to a C++ runtime node. -- Jeremy On Jan 31, 2007, at 5:23 PM, Raymond Feng wrote: Hi, I had an offline chat with Jeremy to help myself glue a few pieces (basically a sequence of actions and participants) together so that I can see the whole picture of the SCA deployment story in Tuscany. We feel it's useful to share the information with the community. I put together a summary at http://cwiki.apache.org/confluence/ display/TUSCANY/Deployment. Please review and comment. 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]
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the xsd:import should be only a hint
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1085: Affects Version/s: (was: Cpp-M3) Java-SDO-Mx schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, SimpleDynamicTestCase.java Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the xsd:import should be only a hint
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1085: Attachment: simple2.xsd schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the xsd:import should be only a hint
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1085: Attachment: patch-1085.1 I have attached a new copy of simple2.xsd and patch-1085.1 as my first try of fixing this problem. I have left FHL in the patch to indicate what I have changed. Basically, I changed SDOXSDEcoreBuilder.java to look up types with their namespaces against extendedMetaData instead from XSD information. Also, createFeature() was changed to return the property with correct containment value if the XSD type cannot be resolved which becomes XSDSimpleTypeDefinition. This fix has passed all the SDO impl test cases. Unfortunately, there is more work to do because the serialization doesn't serialize the correct namespace prefix and uri. Please feel free to review my code and jump in to help. Thanks. schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ https://issues.apache.org/jira/browse/TUSCANY-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-713: --- Attachment: ProcessSchemaLocations.713 SchemaLocationTestCase.java Use the option from http://issues.apache.org/jira/browse/TUSCANY-928. Please keep the SchemaLocationTestCase.xml replace the SchemaLocationTestCase.java and discard the SDOUtil.java Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: https://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Attachments: ProcessSchemaLocations.713, SchemaLocationTestCase.java, SchemaLocationTestCase.java, SchemaLocationTestCase.xml, SDOUtil.java Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
