[jira] Closed: (TUSCANY-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
[ https://issues.apache.org/jira/browse/TUSCANY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1062. > DataGraph.createRootObject implementation does not match 2.1 spec and also is > not helpful when given bad parameters > --- > > Key: TUSCANY-1062 > URL: https://issues.apache.org/jira/browse/TUSCANY-1062 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SCA-M2 >Reporter: Paul Golick > Fix For: Java-SDO-beta1 > > Attachments: DataGraphImpl_patch.txt, DataGraphTestCase.jar > > > When createRootObject is called and a root object has already been created, > the SDO 2.1 spec calls for an IllegalStateException but the current > implementation replaces the existing root. > Also, when either a type is not provided or when a type cannot be determined > from the URI and typeName provided, a NullPointerException is thrown from > org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user > who is not literate in emf utilities: an exception with a helpful error > message should be provided. > Attached are: > a) a jar containing a new test case file for DataGraph > (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) > b) a patch that corrects these problems in > sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
[ https://issues.apache.org/jira/browse/TUSCANY-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1099. > fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java > 1.4.2 users > --- > > Key: TUSCANY-1099 > URL: https://issues.apache.org/jira/browse/TUSCANY-1099 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next > Environment: Java 1.4.2 >Reporter: Paul Golick > Fix For: Java-SDO-beta1 > > Attachments: SDOXSDEcoreBuilder.1099 > > > mvn build ends with message: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS > DEcoreBuilder.java:[71,50] cannot resolve symbol > symbol : method lookupPrefix (java.lang.String) > location: interface org.w3c.dom.Element -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1100. > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-beta1 > > Attachments: 1100.patch, dynamicTypesFromSchema.jar, > dynamicTypesFromSchemaCTS.jar, dynamicTypesFromSchemaCTS_patch.txt > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1105. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Next > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Next > > Attachments: pom.xml.1105 > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1172) plugin LICENSE.txt file has spurious
[ https://issues.apache.org/jira/browse/TUSCANY-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1172. > plugin LICENSE.txt file has spurious > > > Key: TUSCANY-1172 > URL: https://issues.apache.org/jira/browse/TUSCANY-1172 > Project: Tuscany > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Java-SDO-beta1 > Environment: Java 1.4.2 >Reporter: Paul Golick >Priority: Minor > Fix For: Java-SDO-beta1 > > Attachments: 1172.patch > > > The java\sdo\plugin\src\main\resources\META-INF\LICENSE.txt file has > unnecessary references to Mozilla Public License 1.1 (MPL) and to Common > Development and Distribution License 1.0 (CDDL). These should be removed > since these references may unnecessarily deter use of this component by users > that avoid code licensed with MPL or CDDL. This LICENSE.txt file is also not > consistent with the NOTICE.txt file of the same directory. > A patch removing these unnecessary license references will be submitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1193) unable to create data objects from dynamic metadata that match data objects created from XSD metadata
[ https://issues.apache.org/jira/browse/TUSCANY-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick closed TUSCANY-1193. > unable to create data objects from dynamic metadata that match data objects > created from XSD metadata > - > > Key: TUSCANY-1193 > URL: https://issues.apache.org/jira/browse/TUSCANY-1193 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-M2 > Environment: Java 1.4.2 >Reporter: Paul Golick > Fix For: Java-SDO-beta1 > > Attachments: DynamicTypesComparisonTestCase.jar > > > I have been unable to create data objects using dynamic metadata with the > same information content as data objects created from XSD metadata. The > problem is apparent for XSD elements that have maxOccurs greater than one > when the element has repeated values. > Frank Budinsky responded to my posting on tuscany-dev with this statement: > "It seems that the dynamic API is creating properties with EMF's > EStructuralFeature.isUnique == true, while XSDEcoreBuilder sets it to > false. > I guess we should always set it to false (for DataTypes), to be > consistent. > " > I believe that both should be false for consistency and so that data objects > can accurately represent the content of XML files. > I will attach a test case that demonstrates the problem and can verify its > correction. -- 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-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518779
]
Paul Golick commented on TUSCANY-1328:
--
What svn revision includes the fix?
> can not locate service from a component whose implementation is composite
> -
>
> Key: TUSCANY-1328
> URL: https://issues.apache.org/jira/browse/TUSCANY-1328
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-0.90
> Environment: Windows XP
>Reporter: Yang Lei
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> default.composite:
>local="true"
> name="Iteration3Composite"
> policySets="sns:secure" requires="cns:confidentiality"
> targetNamespace="http://foo";
> xmlns:foo="http://foo";
> xmlns="http://www.osoa.org/xmlns/sca/1.0";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0
> http://www.osoa.org/xmlns/sca/1.0 ">
>
> name="foo:MySimpleService"/>
>
>
> MySimpleService.composite:
>local="true"
> name="MySimpleService"
> policySets="sns:secure" requires="cns:confidentiality"
> targetNamespace="http://foo";
> xmlns:foo="http://foo";
> xmlns="http://www.osoa.org/xmlns/sca/1.0";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0
> http://www.osoa.org/xmlns/sca/1.0 ">
>promote="MyServiceComponentOrig/MyService">
> interface="mysca.test.myservice.MyService"/>
>
>
> class="mysca.test.myservice.impl.MyServiceImpl"/>
>
>
> MyServiceImpl
> @Service(interfaces={MyService.class, MyServiceByDate.class,
> MyListService.class, MyListServiceByYear.class})
> public class MyServiceImpl implements MyService, MyServiceByDate,
> MyListService, MyListServiceByYear{
> ...
> }
> When I try to locateService of "MySimpleServiceInRecursive/MyServiceOrig1",
> got the following exception
> org.osoa.sca.ServiceRuntimeException: Service not found:
> MySimpleServiceInRecursive/MyServiceOrig1 at
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
> at
> org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
> at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke
> Thanks.
--
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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: sca_itest_echoService.jar The attached version of the test case code has been modified as suggested by Jean-Sebastien's comment. This version now fails with a NPE in RuntimeSCABindingInvoker with this stack trace: test_asyncEchoService(org.apache.tuscany.sca.test.echoService.EchoServiceTestCase) Time elapsed: 0.07 sec <<< ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy4.echoResults(Unknown Source) at org.apache.tuscany.sca.test.echoService.AsyncEchoServiceImpl.echo(AsyncEchoServiceImpl.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy3.echo(Unknown Source) at org.apache.tuscany.sca.test.echoService.EchoServiceImpl.asyncEcho(EchoServiceImpl.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy2.asyncEcho(Unknown Source) at org.apache.tuscany.sca.test.echoService.RelayServiceImpl.asyncEcho(RelayServiceImpl.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy2.asyncEcho(Unknown Source) at org.apache.tuscany.sca.test.echoService.EchoServiceTestCase.test_asyncEchoService(EchoServiceTestCase.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.Test
[jira] Updated: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: (was: sca_itest_echoService.jar) > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams >Assignee: Simon Nash > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1237) DAS should support JDK 1.4 runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511813 ] Paul Golick commented on TUSCANY-1237: -- When you compile with the JDK 5 compiler, even though you specify that the class files use the 1.4 format, your users can get runtime errors with a 1.4.2 compiler because a class file can refer to methods or classes that are not available in a 1.4.2 class library. At least occasional compilation with a 1.4.2 compiler is necessary to ensure that only features available in a 1.4.2 class library are referenced in the generated class files. > DAS should support JDK 1.4 runtime > -- > > Key: TUSCANY-1237 > URL: https://issues.apache.org/jira/browse/TUSCANY-1237 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB > Environment: Windows, Sun JDK 1.4.2_11 >Reporter: Ron Gavlin > Fix For: Java-DAS-Next > > Attachments: das-TUSCANY-1237.2.patch, das-TUSCANY-1237.patch > > > Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would > seem to make sense for the DAS > JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany > SDO currently supports JDK 1.4+. After browsing the DAS source code, there > appear to be only a few places that leverage JDK 1.5 features. These could > easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 > until SDO 3 is released at which time I presume SDO will require JDK 1.5. -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: (was: sca_itest_echoService.jar) > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: sca_itest_echoService.jar corrected some comments in the test case code > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: (was: 1347part2.patch) > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: (was: sca_itest_echoService.jar) > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: 1347part2.patch The 1347part2.patch file adds echoService to the list of itest modules to prevent regression of the fix that is in 1347.patch > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: 1347part2.patch and granted license > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: sca_itest_echoService.jar Test case is updated because org.osoa.sca.ServiceRuntimeException is now expected. After patch is applied, both test cases now pass. > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, sca_itest_echoService.jar, > sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: 1347.patch The 1347.patch file contains the fix to the reported problem. After applying this fix, the test case submitted in the previous attachment no longer throws an IndexOutOfBoundsException but throws the correct "org.osoa.sca.ServiceRuntimeException: Service not found" exception. > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: 1347.patch, sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: sca_itest_echoService.jar The attached file contains two sca itest test cases: one that works and one that demonstrates the problem reported with this JIRA > IndexOutOfBoundsException thrown when trying to locate a service that > includes a callback > - > > Key: TUSCANY-1347 > URL: https://issues.apache.org/jira/browse/TUSCANY-1347 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Embedded Runtime >Affects Versions: Java-SCA-Next >Reporter: Kevin Williams > Fix For: Java-SCA-Next > > Attachments: sca_itest_echoService.jar > > > More complete description and test case to follow > Here is the exception thrown... > [6/14/07 17:59:55:187 MDT] 0020 SystemErr R > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:572) > at java.util.ArrayList.get(ArrayList.java:347) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) > at > org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) > at > org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) > at > org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) > at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1354) SCADomain. getService () should follow CompositeContext.getService() conventions for "service-name"
[
https://issues.apache.org/jira/browse/TUSCANY-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507945
]
Paul Golick commented on TUSCANY-1354:
--
>From reading the code that is common to DefaultSCADomain.java and
>EmbeddedSCADomain.java (both in package
>org.apache.tuscany.sca.host.embedded.impl), it appears that the "serviceName =
>null" assignment is used as a flag to note that the caller provided only a
>component-name and did not provide a service-name.
This flag is local to the getServiceReference method and is used to select
which createSelfReference method of ComponentContext to choose:
createSelfReference(businessInterface) when no service-name was specified by
caller
createSelfReference(businessInterface, serviceName) when caller specified the
serviceName
In section 1.6.3 of SCA_JavaAnnotationsAndAPIs_V100.pdf (lines 435 and 436) it
is stated: "The second variant, which takes an additional 'serviceName'
parameter, must be used if the component implements multiple services."
So, the current implementation of getService allows the string parameter to
specify only the component name when the component implements one service and
does not require that service name to match "the name of the serviceType sans
package name" as required previously.
In SCA_AssemblyModel_V100.pdf section 1.6.4 (lines 1617-1618 and 1627-1629) it
is stated: "The specification of the service name is optional if the target
component only has one service with a compatible interface"
Additionally, I could find no constraint on service names relating to a service
type in the V100 specifications.
> SCADomain. getService () should follow CompositeContext.getService()
> conventions for "service-name"
> ---
>
> Key: TUSCANY-1354
> URL: https://issues.apache.org/jira/browse/TUSCANY-1354
> Project: Tuscany
> Issue Type: Bug
>Affects Versions: Java-SCA-M2
>Reporter: Kevin Williams
> Fix For: Java-SCA-Next
>
>
> The current SCADomain method
> "public abstract B getService(Class businessInterface, String
> serviceName);"
> is similar in purpose to the .95 specification for
> CompositeContext.locateService API. For this reason, the new API should
> follow the conventions established of the old API.
> This is from the .95 specification:
> public interface CompositeContext {
> ...
> T locateService(Class serviceType, String serviceName);
> }
> "serviceName" can take on one of the following forms:
> /
> If the service-name is not provided, the name of the serviceType sans package
> name will be used as the service-name
> The current implementation getService ends up in the following code:
> public ServiceReference getServiceReference(Class
> businessInterface, String name) {
> // Extract the component name
> String componentName;
> String serviceName;
> int i = name.indexOf('/');
> if (i != -1) {
> componentName = name.substring(0, i);
> serviceName = name.substring(i + 1);
> } else {
> componentName = name;
> serviceName = null;
> }
> It seems that the "else" should default serviceName to
> businessInterface.getSimpleName() in order to follow the existing convention.
> A test case will follow shortly.
--
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-1193) unable to create data objects from dynamic metadata that match data objects created from XSD metadata
[ https://issues.apache.org/jira/browse/TUSCANY-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1193: - Attachment: DynamicTypesComparisonTestCase.jar This jar is intended to be extracted from the Tuscany\java directory. The content is a test case for demonstrating the problem or verifying its correction. > unable to create data objects from dynamic metadata that match data objects > created from XSD metadata > - > > Key: TUSCANY-1193 > URL: https://issues.apache.org/jira/browse/TUSCANY-1193 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-M2 > Environment: Java 1.4.2 >Reporter: Paul Golick > Fix For: Java-SDO-M2 > > Attachments: DynamicTypesComparisonTestCase.jar > > > I have been unable to create data objects using dynamic metadata with the > same information content as data objects created from XSD metadata. The > problem is apparent for XSD elements that have maxOccurs greater than one > when the element has repeated values. > Frank Budinsky responded to my posting on tuscany-dev with this statement: > "It seems that the dynamic API is creating properties with EMF's > EStructuralFeature.isUnique == true, while XSDEcoreBuilder sets it to > false. > I guess we should always set it to false (for DataTypes), to be > consistent. > " > I believe that both should be false for consistency and so that data objects > can accurately represent the content of XML files. > I will attach a test case that demonstrates the problem and can verify its > correction. -- 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-1193) unable to create data objects from dynamic metadata that match data objects created from XSD metadata
unable to create data objects from dynamic metadata that match data objects created from XSD metadata - Key: TUSCANY-1193 URL: https://issues.apache.org/jira/browse/TUSCANY-1193 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-M2 I have been unable to create data objects using dynamic metadata with the same information content as data objects created from XSD metadata. The problem is apparent for XSD elements that have maxOccurs greater than one when the element has repeated values. Frank Budinsky responded to my posting on tuscany-dev with this statement: "It seems that the dynamic API is creating properties with EMF's EStructuralFeature.isUnique == true, while XSDEcoreBuilder sets it to false. I guess we should always set it to false (for DataTypes), to be consistent. " I believe that both should be false for consistency and so that data objects can accurately represent the content of XML files. I will attach a test case that demonstrates the problem and can verify its correction. -- 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-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()
[ https://issues.apache.org/jira/browse/TUSCANY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1177: - Attachment: 1177.patch Patch removes the test for DocumentRoot and is intended to be applied from Tuscany\java directory. The Tuscany implementation also requires that the patch for JIRA 1176 be applied before it successfully passes the DynamicTypesFromSchemaTestCase. > CTS should not expect DocumentRoot to be included in results from > XSDHelper.define() > > > Key: TUSCANY-1177 > URL: https://issues.apache.org/jira/browse/TUSCANY-1177 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: 1177.patch > > > DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML > documents without an XSD. All mentioned of DocumentRoot were removed from SDO > 2.1 and the CTS should not be expecting DocumentRoot to be returned by > XSDHelper.define(). -- 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-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()
[ https://issues.apache.org/jira/browse/TUSCANY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481300 ] Paul Golick commented on TUSCANY-1177: -- Andy, I could supply a patch for this JIRA (1177) that is separate from the patch for JIRA 1176. > CTS should not expect DocumentRoot to be included in results from > XSDHelper.define() > > > Key: TUSCANY-1177 > URL: https://issues.apache.org/jira/browse/TUSCANY-1177 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > > DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML > documents without an XSD. All mentioned of DocumentRoot were removed from SDO > 2.1 and the CTS should not be expecting DocumentRoot to be returned by > XSDHelper.define(). -- 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-1176) DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties
[ https://issues.apache.org/jira/browse/TUSCANY-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1176: - Attachment: 1176.patch patch removes tests for "any", "mixed", and "text" properties and is intended to be applied from Tuscany\java directory > DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties > -- > > Key: TUSCANY-1176 > URL: https://issues.apache.org/jira/browse/TUSCANY-1176 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: 1176.patch > > > DynamicTypesFromSchemaTestCase currently fails if a call to > getInstanceProperties does not return "mixed" or "text" properties. I see no > mention of these properties in the SDO for Java 2.1 specification. The "text" > property was mentioned in SDO 2.0.1 but then removed for SDO 2.1. -- 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-1176) DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties
[ https://issues.apache.org/jira/browse/TUSCANY-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481232 ] Paul Golick commented on TUSCANY-1176: -- Recent changes have not only removed the "mixed" and "text" properties, but have also removed the "any" property. The Tuscany implementation fails the tests for all three of these properties. Is the test for the "any" property also invalid? > DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties > -- > > Key: TUSCANY-1176 > URL: https://issues.apache.org/jira/browse/TUSCANY-1176 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > > DynamicTypesFromSchemaTestCase currently fails if a call to > getInstanceProperties does not return "mixed" or "text" properties. I see no > mention of these properties in the SDO for Java 2.1 specification. The "text" > property was mentioned in SDO 2.0.1 but then removed for SDO 2.1. -- 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-1176) DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties
[ https://issues.apache.org/jira/browse/TUSCANY-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481208 ] Paul Golick commented on TUSCANY-1176: -- I plan to contribute a patch to fix DynamicTypesFromSchemaTestCase > DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties > -- > > Key: TUSCANY-1176 > URL: https://issues.apache.org/jira/browse/TUSCANY-1176 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > > DynamicTypesFromSchemaTestCase currently fails if a call to > getInstanceProperties does not return "mixed" or "text" properties. I see no > mention of these properties in the SDO for Java 2.1 specification. The "text" > property was mentioned in SDO 2.0.1 but then removed for SDO 2.1. -- 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-1172) plugin LICENSE.txt file has spurious
[ https://issues.apache.org/jira/browse/TUSCANY-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1172: - Attachment: 1172.patch This patch is intended to be applied from the Tuscany\java directory > plugin LICENSE.txt file has spurious > > > Key: TUSCANY-1172 > URL: https://issues.apache.org/jira/browse/TUSCANY-1172 > Project: Tuscany > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Java-SDO-M3 > Environment: Java 1.4.2 >Reporter: Paul Golick >Priority: Minor > Fix For: Java-SDO-M3 > > Attachments: 1172.patch > > > The java\sdo\plugin\src\main\resources\META-INF\LICENSE.txt file has > unnecessary references to Mozilla Public License 1.1 (MPL) and to Common > Development and Distribution License 1.0 (CDDL). These should be removed > since these references may unnecessarily deter use of this component by users > that avoid code licensed with MPL or CDDL. This LICENSE.txt file is also not > consistent with the NOTICE.txt file of the same directory. > A patch removing these unnecessary license references will be submitted. -- 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-1172) plugin LICENSE.txt file has spurious
plugin LICENSE.txt file has spurious Key: TUSCANY-1172 URL: https://issues.apache.org/jira/browse/TUSCANY-1172 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-SDO-M3 Environment: Java 1.4.2 Reporter: Paul Golick Priority: Minor Fix For: Java-SDO-M3 The java\sdo\plugin\src\main\resources\META-INF\LICENSE.txt file has unnecessary references to Mozilla Public License 1.1 (MPL) and to Common Development and Distribution License 1.0 (CDDL). These should be removed since these references may unnecessarily deter use of this component by users that avoid code licensed with MPL or CDDL. This LICENSE.txt file is also not consistent with the NOTICE.txt file of the same directory. A patch removing these unnecessary license references will be submitted. -- 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-1122) TypeConversionTestCase fails for JDK 1.4.2
[ https://issues.apache.org/jira/browse/TUSCANY-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477085 ] Paul Golick commented on TUSCANY-1122: -- There were several BigDecimal bug fixes listed in the release notes for 1.5.0_08. The links to the bug database no longer work but the release notes say the BigDecimal implementation inappropriately rounded some values. To test 1.4.2 compilation, I use a patch to comment out the body of the testTuscany_836 method of TypeConversionTestCase.java. > TypeConversionTestCase fails for JDK 1.4.2 > -- > > Key: TUSCANY-1122 > URL: https://issues.apache.org/jira/browse/TUSCANY-1122 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: IBM JDK 1.4.2 build cn1420-20040626 on Windows > also observed on a 1.4.2 linux build > svn revision level = 509212 >Reporter: Kelvin Goodson > > Just discovered this, not having build with 1.4.2 for a while. > junit.framework.AssertionFailedError : expected:<-9223372036854775808> but > was:<9223372036854775807> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals (Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:136) > at junit.framework.Assert.assertEquals(Assert.java:142) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java > :887) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java:887) > This looks similar to the closed JIRA TUSCANY-712 -- 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-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
[ https://issues.apache.org/jira/browse/TUSCANY-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474559 ] Paul Golick commented on TUSCANY-1099: -- I have verified this issue is fixed in revision 509219. Please close this issue. > fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java > 1.4.2 users > --- > > Key: TUSCANY-1099 > URL: https://issues.apache.org/jira/browse/TUSCANY-1099 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: SDOXSDEcoreBuilder.1099 > > > mvn build ends with message: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS > DEcoreBuilder.java:[71,50] cannot resolve symbol > symbol : method lookupPrefix (java.lang.String) > location: interface org.w3c.dom.Element -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474563 ] Paul Golick commented on TUSCANY-1105: -- I have verified this issue is fixed in revision 509219. Please close this issue. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: pom.xml.1105 > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474560 ] Paul Golick commented on TUSCANY-1100: -- I have verified this issue is fixed in revision 509219. Please close this issue. > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: 1100.patch, dynamicTypesFromSchema.jar, > dynamicTypesFromSchemaCTS.jar, dynamicTypesFromSchemaCTS_patch.txt > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- 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-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
[ https://issues.apache.org/jira/browse/TUSCANY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474556 ] Paul Golick commented on TUSCANY-1062: -- I have verified this issue is fixed in revision 509219. Please close this issue > DataGraph.createRootObject implementation does not match 2.1 spec and also is > not helpful when given bad parameters > --- > > Key: TUSCANY-1062 > URL: https://issues.apache.org/jira/browse/TUSCANY-1062 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: DataGraphImpl_patch.txt, DataGraphTestCase.jar > > > When createRootObject is called and a root object has already been created, > the SDO 2.1 spec calls for an IllegalStateException but the current > implementation replaces the existing root. > Also, when either a type is not provided or when a type cannot be determined > from the URI and typeName provided, a NullPointerException is thrown from > org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user > who is not literate in emf utilities: an exception with a helpful error > message should be provided. > Attached are: > a) a jar containing a new test case file for DataGraph > (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) > b) a patch that corrects these problems in > sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- 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-1122) TypeConversionTestCase fails for JDK 1.4.2
[ https://issues.apache.org/jira/browse/TUSCANY-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474202 ] Paul Golick commented on TUSCANY-1122: -- I should have noted the Java JDK builds that I used: Sun 1.4.2: Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) IBM 1.4.2: Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20061124 (SR7) (JIT enabled: jitc)) Sun 1.5: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b02) Java HotSpot(TM) Client VM (build 1.5.0_10-b02, mixed mode, sharing) IBM 1.5: IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20061001 (JIT enabled) J9VM - 20060915_08260_lHdSMR JIT - 20060908_1811_r8 GC - 20060906_AA) JCL - 20061002 > TypeConversionTestCase fails for JDK 1.4.2 > -- > > Key: TUSCANY-1122 > URL: https://issues.apache.org/jira/browse/TUSCANY-1122 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: IBM JDK 1.4.2 build cn1420-20040626 on Windows > also observed on a 1.4.2 linux build > svn revision level = 509212 >Reporter: Kelvin Goodson > > Just discovered this, not having build with 1.4.2 for a while. > junit.framework.AssertionFailedError : expected:<-9223372036854775808> but > was:<9223372036854775807> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals (Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:136) > at junit.framework.Assert.assertEquals(Assert.java:142) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java > :887) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java:887) > This looks similar to the closed JIRA TUSCANY-712 -- 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-1122) TypeConversionTestCase fails for JDK 1.4.2
[ https://issues.apache.org/jira/browse/TUSCANY-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474198 ] Paul Golick commented on TUSCANY-1122: -- The testTuscany_836 method of TypeConversionTestCase.java fails when run by the IBM 1.4.2 JRE or by the Sun 1.4.2 JRE but works when run by either IBM or Sun version 5 JREs: the reason is that in the Java 1.4.2 libraries BigDecimal does not preserve the value of Long.MAX_VALUE or nearby values but change these values to Long.MIN_VALUE. This is a Java problem and occurs in the most recent releases of 1.4.2 from both Sun and IBM. > TypeConversionTestCase fails for JDK 1.4.2 > -- > > Key: TUSCANY-1122 > URL: https://issues.apache.org/jira/browse/TUSCANY-1122 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: IBM JDK 1.4.2 build cn1420-20040626 on Windows > also observed on a 1.4.2 linux build > svn revision level = 509212 >Reporter: Kelvin Goodson > > Just discovered this, not having build with 1.4.2 for a while. > junit.framework.AssertionFailedError : expected:<-9223372036854775808> but > was:<9223372036854775807> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals (Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:136) > at junit.framework.Assert.assertEquals(Assert.java:142) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java > :887) > at > org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java:887) > This looks similar to the closed JIRA TUSCANY-712 -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1105: - Attachment: pom.xml.1105 The attached file contains a patch to cts\sdo2.1-tuscany\pom.xml to add a dependency on the stax api (the same version used by SDO). The patch is intended to be applied from the Tuscany\java directory. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: pom.xml.1105 > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472896 ] Paul Golick commented on TUSCANY-1105: -- The SDO version 2.1 specification requires that Java 1.4.2 users are supported. Adding something from Java 6 is not appropriate. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
[ https://issues.apache.org/jira/browse/TUSCANY-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472743 ] Paul Golick commented on TUSCANY-1099: -- After applying the patch, my tests using Java 1.4.2 pass. Thank you. > fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java > 1.4.2 users > --- > > Key: TUSCANY-1099 > URL: https://issues.apache.org/jira/browse/TUSCANY-1099 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: SDOXSDEcoreBuilder.1099 > > > mvn build ends with message: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS > DEcoreBuilder.java:[71,50] cannot resolve symbol > symbol : method lookupPrefix (java.lang.String) > location: interface org.w3c.dom.Element -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472388 ] Paul Golick commented on TUSCANY-1105: -- After starting with an empty repository, after doing mvn builds of spec\sdo-api and sdo, the repository contains the following jars that include the constantPoolEntry javax/xml/stream/XMLStreamException: org\apache\tuscany\sdo\tuscany-sdo-impl\1.0-incubator-SNAPSHOT\tuscany-sdo-impl-1.0-incubator-SNAPSHOT.jar org\codehaus\woodstox\wstx-asl\3.2.0\wstx-asl-3.2.0.jar stax\stax-api\1.0.1\stax-api-1.0.1.jar > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1100: - Attachment: dynamicTypesFromSchemaCTS_patch.txt dynamicTypesFromSchemaCTS.jar Robbie had asked me to write the test cases. dynamicTypesFromSchemaCTS.jar contains new files to be added. dynamicTypesFromSchemaCTS_patch.txt cotains patch text for existing files. Both of these files are for expansion or application from the tuscany\java directory. > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: dynamicTypesFromSchema.jar, > dynamicTypesFromSchemaCTS.jar, dynamicTypesFromSchemaCTS_patch.txt > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472348 ] Paul Golick commented on TUSCANY-1105: -- The CTS is able to run when I compile and run it under Java 6. (Although I had to modify SniffTest.java to omit tests of XSDSerializationTest.class, DataObjectTest.class, TypeConversionTest.class) As I noted previously, it fails attempting to load a class that is not present in versions of Java prior to Java 6. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471819 ] Paul Golick commented on TUSCANY-1105: -- The javax.xml.stream.XMLStreamException class was added in Java 6. The error is occurring while org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl is creating an instance that is a subclass of org.eclipse.emf.ecore.xmi.impl.SAXXMLHandler that comes from ecore-xmi. > CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException > while reading XML stream > -- > > Key: TUSCANY-1105 > URL: https://issues.apache.org/jira/browse/TUSCANY-1105 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Mx > Environment: Java 5 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > > while adding a test that runs in the SDO impl test directory to the CTS, the > surefire-reports for SniffTest includes the following: > message="javax.xml.stream.XMLStreamException">java.lang.NoClassDefFoundError: > javax.xml.stream.XMLStreamException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:59) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) > at > org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) > at > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) > at > org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) > at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) > 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:238) > ... -- 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-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream -- Key: TUSCANY-1105 URL: https://issues.apache.org/jira/browse/TUSCANY-1105 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Affects Versions: Java-SDO-Mx Environment: Java 5 Reporter: Paul Golick Fix For: Java-SDO-Mx while adding a test that runs in the SDO impl test directory to the CTS, the surefire-reports for SniffTest includes the following: java.lang.NoClassDefFoundError: javax.xml.stream.XMLStreamException at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) at org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) 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:238) ... -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471782 ] Paul Golick commented on TUSCANY-1100: -- As written, this test case is Tuscany-specific since it relies on SDOUtil to obtain a new HelperContext. Would you like a version that can be put in the CTS ? > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: dynamicTypesFromSchema.jar > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471500 ] Paul Golick commented on TUSCANY-1100: -- I put them in the implementation test directories because the tests are simple and brief enough to be run as build verification tests. > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: dynamicTypesFromSchema.jar > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1100: - Attachment: dynamicTypesFromSchema.jar This jar contains test code: one java file with JUnit test cases, one xsd file with XML Schema definitions for the test cases, and three xml files for testing XML Schema primitive datatypes, derived datatypes, and assorted complex datatypes. > Dynamic Type tests are needed to ensure that all XSD datatypes are supported > > > Key: TUSCANY-1100 > URL: https://issues.apache.org/jira/browse/TUSCANY-1100 > Project: Tuscany > Issue Type: Test > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Java 1.4.2 or later >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: dynamicTypesFromSchema.jar > > > Dynamic Type tests are needed. This JIRA is used to contribute test cases > that use xsd and xml to define Type objects. Another JIRA will be used for > test cases that use DataObjects to define the Type objects. -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
Dynamic Type tests are needed to ensure that all XSD datatypes are supported Key: TUSCANY-1100 URL: https://issues.apache.org/jira/browse/TUSCANY-1100 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Java 1.4.2 or later Reporter: Paul Golick Fix For: Java-SDO-Mx Dynamic Type tests are needed. This JIRA is used to contribute test cases that use xsd and xml to define Type objects. Another JIRA will be used for test cases that use DataObjects to define the Type objects. -- 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-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users --- Key: TUSCANY-1099 URL: https://issues.apache.org/jira/browse/TUSCANY-1099 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-Mx mvn build ends with message: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS DEcoreBuilder.java:[71,50] cannot resolve symbol symbol : method lookupPrefix (java.lang.String) location: interface org.w3c.dom.Element -- 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-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
[ https://issues.apache.org/jira/browse/TUSCANY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1062: - Attachment: DataGraphTestCase.jar DataGraphImpl_patch.txt > DataGraph.createRootObject implementation does not match 2.1 spec and also is > not helpful when given bad parameters > --- > > Key: TUSCANY-1062 > URL: https://issues.apache.org/jira/browse/TUSCANY-1062 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 >Reporter: Paul Golick > Fix For: Java-M3 > > Attachments: DataGraphImpl_patch.txt, DataGraphTestCase.jar > > > When createRootObject is called and a root object has already been created, > the SDO 2.1 spec calls for an IllegalStateException but the current > implementation replaces the existing root. > Also, when either a type is not provided or when a type cannot be determined > from the URI and typeName provided, a NullPointerException is thrown from > org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user > who is not literate in emf utilities: an exception with a helpful error > message should be provided. > Attached are: > a) a jar containing a new test case file for DataGraph > (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) > b) a patch that corrects these problems in > sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters --- Key: TUSCANY-1062 URL: https://issues.apache.org/jira/browse/TUSCANY-1062 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Paul Golick Fix For: Java-M3 When createRootObject is called and a root object has already been created, the SDO 2.1 spec calls for an IllegalStateException but the current implementation replaces the existing root. Also, when either a type is not provided or when a type cannot be determined from the URI and typeName provided, a NullPointerException is thrown from org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user who is not literate in emf utilities: an exception with a helpful error message should be provided. Attached are: a) a jar containing a new test case file for DataGraph (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) b) a patch that corrects these problems in sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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-712) recently added file TypeConversionTestCase.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-712?page=comments#action_12433927 ] Paul Golick commented on TUSCANY-712: - I have verified that this issue is fixed in 442279. Please close this issue. > recently added file TypeConversionTestCase.java is not compatible with JDK 1.4 > -- > > Key: TUSCANY-712 > URL: http://issues.apache.org/jira/browse/TUSCANY-712 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: JDK 1.4 >Reporter: Paul Golick > Attachments: TypeConversionTestCase.txt > > > The recently added test cases use the valueOf methods added in Java 1.5 to > the Integer, Long, Character, Double, and Float classes. To permit users of > Java 1.4 to compile TypeConversionTestCase.java or to run the generated class > file, the corresponding constructors can be used instead of the valueOf > method that is not available in the 1.4 class library. -- 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-712) recently added file TypeConversionTestCase.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-712?page=all ] Paul Golick updated TUSCANY-712: Attachment: TypeConversionTestCase.txt The attached patch replaces the valueOf methods that are not available in Java 1.4 with equivalent code using constructors that are available in Java 1.4. > recently added file TypeConversionTestCase.java is not compatible with JDK 1.4 > -- > > Key: TUSCANY-712 > URL: http://issues.apache.org/jira/browse/TUSCANY-712 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: JDK 1.4 >Reporter: Paul Golick > Attachments: TypeConversionTestCase.txt > > > The recently added test cases use the valueOf methods added in Java 1.5 to > the Integer, Long, Character, Double, and Float classes. To permit users of > Java 1.4 to compile TypeConversionTestCase.java or to run the generated class > file, the corresponding constructors can be used instead of the valueOf > method that is not available in the 1.4 class library. -- 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-712) recently added file TypeConversionTestCase.java is not compatible with JDK 1.4
recently added file TypeConversionTestCase.java is not compatible with JDK 1.4 -- Key: TUSCANY-712 URL: http://issues.apache.org/jira/browse/TUSCANY-712 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: JDK 1.4 Reporter: Paul Golick The recently added test cases use the valueOf methods added in Java 1.5 to the Integer, Long, Character, Double, and Float classes. To permit users of Java 1.4 to compile TypeConversionTestCase.java or to run the generated class file, the corresponding constructors can be used instead of the valueOf method that is not available in the 1.4 class library. -- 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-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12433134 ] Paul Golick commented on TUSCANY-696: - The XMLDocumentTestCase.xml file is dependent on multiple schemas. The XMLDocumentSchemaLocation.xsd file is also being used and, so, is one of the files used by the application. > 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: > > 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]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12433120 ] Paul Golick commented on TUSCANY-696: - The schema located at "/XMLDocumentSchemaLocation.xsd" contains the "purchaseReport" element as was described in the "xsi:schemaLocation" attribute. > 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: > > 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]
[jira] Commented: (TUSCANY-492) recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-492?page=comments#action_12428465 ] Paul Golick commented on TUSCANY-492: - The problem reported by this issue was fixed in revision 431585. This issue can be closed. > recently added file XMLStreamHelperTestCase.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-492 > URL: http://issues.apache.org/jira/browse/TUSCANY-492 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: Windows XP >Reporter: Paul Golick > Attachments: XMLStreamHelperTestCase_patch.txt > > > In XMLStreamHelperTestCase.java there are two uses of a java.lang.String > instance method "contains(java.lang.String)". > This method was not added until Java 1.5; so, it is not found in the class > library for Java 1.4 > The attached patch changes "x.contains(y)" to the nearly equivalent > "x.indexOf(y)!=-1". -- 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-577) XSDHelperImpl.java compilation with JDK 1.4.2 - fails
[ http://issues.apache.org/jira/browse/TUSCANY-577?page=comments#action_12425553 ] Paul Golick commented on TUSCANY-577: - Please close this JIRA issue. I have confirmed that the problem it reports has been fixed. > XSDHelperImpl.java compilation with JDK 1.4.2 - fails > - > > Key: TUSCANY-577 > URL: http://issues.apache.org/jira/browse/TUSCANY-577 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: all >Reporter: Paul Golick > Attachments: XSDHelperImpl_patch.txt > > > The XSDHelperImpl.java code was recently changed by adding: > throw new IllegalArgumentException(e); > This statement fails when compiled with JDK 1.4.2 because > IllegalArgumentException does not have a constructor that takes a > java.lang.Exception argument. Such a constructor was added in Java 1.5. > The patch includes a fix to change the constructor to one that takes a String > and that is present in previous Java versions. -- 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-577) XSDHelperImpl.java compilation with JDK 1.4.2 - fails
[ http://issues.apache.org/jira/browse/TUSCANY-577?page=all ] Paul Golick updated TUSCANY-577: Attachment: XSDHelperImpl_patch.txt > XSDHelperImpl.java compilation with JDK 1.4.2 - fails > - > > Key: TUSCANY-577 > URL: http://issues.apache.org/jira/browse/TUSCANY-577 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: all >Reporter: Paul Golick > Attachments: XSDHelperImpl_patch.txt > > > The XSDHelperImpl.java code was recently changed by adding: > throw new IllegalArgumentException(e); > This statement fails when compiled with JDK 1.4.2 because > IllegalArgumentException does not have a constructor that takes a > java.lang.Exception argument. Such a constructor was added in Java 1.5. > The patch includes a fix to change the constructor to one that takes a String > and that is present in previous Java versions. -- 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-577) XSDHelperImpl.java compilation with JDK 1.4.2 - fails
XSDHelperImpl.java compilation with JDK 1.4.2 - fails - Key: TUSCANY-577 URL: http://issues.apache.org/jira/browse/TUSCANY-577 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: all Reporter: Paul Golick The XSDHelperImpl.java code was recently changed by adding: throw new IllegalArgumentException(e); This statement fails when compiled with JDK 1.4.2 because IllegalArgumentException does not have a constructor that takes a java.lang.Exception argument. Such a constructor was added in Java 1.5. The patch includes a fix to change the constructor to one that takes a String and that is present in previous Java versions. -- 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-549) DAS config.xsd file contains a URI instead of a simple identifier for its namespace prefix
[ http://issues.apache.org/jira/browse/TUSCANY-549?page=all ] Paul Golick updated TUSCANY-549: Attachment: config_xsd_patch.txt > DAS config.xsd file contains a URI instead of a simple identifier for its > namespace prefix > -- > > Key: TUSCANY-549 > URL: http://issues.apache.org/jira/browse/TUSCANY-549 > Project: Tuscany > Type: Improvement > Components: Java DAS RDB > Versions: Java-M2 > Environment: all > Reporter: Paul Golick > Priority: Minor > Attachments: config_xsd_patch.txt > > The use of a URI as a prefix is unnecessary since the prefix in the > config.xsd file is local to the schema element within the file. So, > "org.apache.tuscany.das.rdb.config" can be replaced with "config" in > config.xsd. I will attach a patch to make this change and to split some very > long lines so the file is easier to read. -- 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-549) DAS config.xsd file contains a URI instead of a simple identifier for its namespace prefix
DAS config.xsd file contains a URI instead of a simple identifier for its namespace prefix -- Key: TUSCANY-549 URL: http://issues.apache.org/jira/browse/TUSCANY-549 Project: Tuscany Type: Improvement Components: Java DAS RDB Versions: Java-M2 Environment: all Reporter: Paul Golick Priority: Minor The use of a URI as a prefix is unnecessary since the prefix in the config.xsd file is local to the schema element within the file. So, "org.apache.tuscany.das.rdb.config" can be replaced with "config" in config.xsd. I will attach a patch to make this change and to split some very long lines so the file is easier to read. -- 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-492) recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-492?page=all ] Paul Golick updated TUSCANY-492: Attachment: XMLStreamHelperTestCase_patch.txt The contains method of the Java 1.5 String class is replaced with method present in both Java 1.4 and later. > recently added file XMLStreamHelperTestCase.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-492 > URL: http://issues.apache.org/jira/browse/TUSCANY-492 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Versions: Java-M2 > Environment: Windows XP > Reporter: Paul Golick > Attachments: XMLStreamHelperTestCase_patch.txt > > In XMLStreamHelperTestCase.java there are two uses of a java.lang.String > instance method "contains(java.lang.String)". > This method was not added until Java 1.5; so, it is not found in the class > library for Java 1.4 > The attached patch changes "x.contains(y)" to the nearly equivalent > "x.indexOf(y)!=-1". -- 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-492) recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4
recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4 --- Key: TUSCANY-492 URL: http://issues.apache.org/jira/browse/TUSCANY-492 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M2 Environment: Windows XP Reporter: Paul Golick In XMLStreamHelperTestCase.java there are two uses of a java.lang.String instance method "contains(java.lang.String)". This method was not added until Java 1.5; so, it is not found in the class library for Java 1.4 The attached patch changes "x.contains(y)" to the nearly equivalent "x.indexOf(y)!=-1". -- 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-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-257?page=all ] Paul Golick updated TUSCANY-257: Attachment: newFiles.jar patchUpdated.txt attached files mentioned in previous comment. > recently added file Interface2JavaGenerator.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-257 > URL: http://issues.apache.org/jira/browse/TUSCANY-257 > Project: Tuscany > Type: Bug > Components: Java SDO Tools > Environment: all > Reporter: Paul Golick > Fix For: M1 > Attachments: newFiles.jar, patchInterface2JavaGenerator.txt, patchUpdated.txt > > Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and > java.lang.reflect.Type that were added in Java 5 for generics. It appears > that the portion of Interface2JavaGenerator that uses ParameterizedType and > Type is not needed for Java 1.4 classes. -- 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
[jira] Commented: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-257?page=comments#action_12378468 ] Paul Golick commented on TUSCANY-257: - As an alternative to the patch I previously suggested: The existing Interface2JavaGenerator.java file could be deleted so that it could be added to a new subproject such as one in a new subdirectory "Tuscany\java\sdo\java5tools" as shown by the files in the attached newFiles.jar that is intended to be extracted from "Tuscany\java". In combination with the delete of the existing Interface2JavaGenerator.java file and the addition of the new subproject, the current Tuscany\java\sdo\pom.xml file needs to be patched to add the new subproject as shown by the attached patch file, patchUpdated.txt. Of course there is nothing significant about the java5tools directory name and a more appropriate name can be used if desired, with corresponding changes in the pom.xml files. > recently added file Interface2JavaGenerator.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-257 > URL: http://issues.apache.org/jira/browse/TUSCANY-257 > Project: Tuscany > Type: Bug > Components: Java SDO Tools > Environment: all > Reporter: Paul Golick > Fix For: M1 > Attachments: patchInterface2JavaGenerator.txt > > Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and > java.lang.reflect.Type that were added in Java 5 for generics. It appears > that the portion of Interface2JavaGenerator that uses ParameterizedType and > Type is not needed for Java 1.4 classes. -- 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
[jira] Commented: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
[ http://issues.apache.org/jira/browse/TUSCANY-256?page=comments#action_12377813 ] Paul Golick commented on TUSCANY-256: - Fix verified in revision 399056. Please close this issue. > loadClass in SDOUtil receiving exception because different class loaders are > used > - > > Key: TUSCANY-256 > URL: http://issues.apache.org/jira/browse/TUSCANY-256 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: all > Reporter: Paul Golick > Attachments: patchSDOUtil.txt > > In SDOUtil.java it is necessary that the loadClass method be wrapped and done > by invoking AccessController.doPriveleged on a PrivelegedExceptionAction > object because the current class loader can be different than the one > previously used to load the class. -- 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
[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-257?page=all ] Paul Golick updated TUSCANY-257: Attachment: patchInterface2JavaGenerator.txt The attached patch makes the file compatible with Java 1.4 by removing the code that handled methods with parameterized return types, a new feature of Java 1.5. > recently added file Interface2JavaGenerator.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-257 > URL: http://issues.apache.org/jira/browse/TUSCANY-257 > Project: Tuscany > Type: Bug > Components: Java SDO Tools > Environment: all > Reporter: Paul Golick > Attachments: patchInterface2JavaGenerator.txt > > Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and > java.lang.reflect.Type that were added in Java 5 for generics. It appears > that the portion of Interface2JavaGenerator that uses ParameterizedType and > Type is not needed for Java 1.4 classes. -- 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
[jira] Created: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 --- Key: TUSCANY-257 URL: http://issues.apache.org/jira/browse/TUSCANY-257 Project: Tuscany Type: Bug Components: Java SDO Tools Environment: all Reporter: Paul Golick Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and java.lang.reflect.Type that were added in Java 5 for generics. It appears that the portion of Interface2JavaGenerator that uses ParameterizedType and Type is not needed for Java 1.4 classes. -- 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
[jira] Updated: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
[ http://issues.apache.org/jira/browse/TUSCANY-256?page=all ] Paul Golick updated TUSCANY-256: Attachment: patchSDOUtil.txt The attached patch file moves the loadClass method into a PrivelegedExceptionAction object and invokes it with a doPriveleged method. > loadClass in SDOUtil receiving exception because different class loaders are > used > - > > Key: TUSCANY-256 > URL: http://issues.apache.org/jira/browse/TUSCANY-256 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: all > Reporter: Paul Golick > Attachments: patchSDOUtil.txt > > In SDOUtil.java it is necessary that the loadClass method be wrapped and done > by invoking AccessController.doPriveleged on a PrivelegedExceptionAction > object because the current class loader can be different than the one > previously used to load the class. -- 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
[jira] Created: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
loadClass in SDOUtil receiving exception because different class loaders are used - Key: TUSCANY-256 URL: http://issues.apache.org/jira/browse/TUSCANY-256 Project: Tuscany Type: Bug Components: Java SDO Implementation Environment: all Reporter: Paul Golick In SDOUtil.java it is necessary that the loadClass method be wrapped and done by invoking AccessController.doPriveleged on a PrivelegedExceptionAction object because the current class loader can be different than the one previously used to load the class. -- 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
[jira] Commented: (TUSCANY-216) recent change to JavaFactoryImpl.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-216?page=comments#action_12376116 ] Paul Golick commented on TUSCANY-216: - I have no authority to do any workflow operations. The operations I am permitted are limited to attach file, attach screenshot, clone, comment, create sub-task, voting, and watching. I would have thought the reporter would be able to close, but I cannot. > recent change to JavaFactoryImpl.java is not compatible with JDK 1.4 > > > Key: TUSCANY-216 > URL: http://issues.apache.org/jira/browse/TUSCANY-216 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: svn version 396576 > Reporter: Paul Golick > Attachments: svn142diff.txt > > The recent change used the valueOf(char) method of the Character class that > was added in Java 1.5. That method is not available in Java 1.4. However, a > constructor is available for both Java 1.4 and Java 1.5. -- 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
[jira] Commented: (TUSCANY-216) recent change to JavaFactoryImpl.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-216?page=comments#action_12376111 ] Paul Golick commented on TUSCANY-216: - Please close this issue. I have verified it in revision 396677. > recent change to JavaFactoryImpl.java is not compatible with JDK 1.4 > > > Key: TUSCANY-216 > URL: http://issues.apache.org/jira/browse/TUSCANY-216 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: svn version 396576 > Reporter: Paul Golick > Attachments: svn142diff.txt > > The recent change used the valueOf(char) method of the Character class that > was added in Java 1.5. That method is not available in Java 1.4. However, a > constructor is available for both Java 1.4 and Java 1.5. -- 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
[jira] Commented: (TUSCANY-119) XMLDocumentImpl should implement get/setSchemaLocation and get/setNoNamespaceSchemaLocation
[
http://issues.apache.org/jira/browse/TUSCANY-119?page=comments#action_12376109
]
Paul Golick commented on TUSCANY-119:
-
Please close this issue. I had verified it in revision 391789.
> XMLDocumentImpl should implement get/setSchemaLocation and
> get/setNoNamespaceSchemaLocation
> ---
>
> Key: TUSCANY-119
> URL: http://issues.apache.org/jira/browse/TUSCANY-119
> Project: Tuscany
> Type: New Feature
> Components: Java SDO Implementation
> Reporter: Paul Golick
> Attachments: XMLDocumentImplPatch.txt
>
> A patch containing a suggested solution and its test case follows:
> Index:
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
> ===
> ---
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
>(revision 0)
> +++
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
>(revision 0)
> @@ -0,0 +1,88 @@
> +/**
> + *
> + * Copyright 2005 The Apache Software Foundation or its licensors, as
> applicable.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.tuscany.sdo.test;
> +
> +import java.io.IOException;
> +
> +import junit.framework.TestCase;
> +
> +import commonj.sdo.helper.XMLDocument;
> +import commonj.sdo.helper.XMLHelper;
> +
> +public class XMLDocumentTestCase extends TestCase {
> +
> + private final String SCHEMA_XML = "/XMLDocumentTestCase.xml";
> +
> + /**
> + * This method will load an xml document consisting of a
> xsi:schemaLocation and
> + * xsi:noNamespaceSchemaLocation defined. It will then use the
> XMLDocument API to get and
> + * set the schemaLocation property.
> + *
> + * @throws IOException
> + */
> + public void testSchemaLocation() throws IOException
> + {
> + // load the xml document which has xsi:noNamespaceSchemaLocation and
> xsi:schemaLocation defined
> + XMLDocument doc =
> XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
> +
> + // get the schemaLocation
> + assertEquals("http://www.example.org/emp emp.xsd
> http://www.example.com/Report http://www.example.com/Report.xsd";,
> doc.getSchemaLocation());
> +
> + // set the schemaLocation to another value and test to see if the
> value was set
> + doc.setSchemaLocation("namespace schemaLocation");
> + assertEquals("namespace schemaLocation", doc.getSchemaLocation());
> +
> + // remove the schemaLocation and ensure it returns null
> + doc.setSchemaLocation(null);
> + assertNull(doc.getSchemaLocation());
> +
> + // ensure changes to schemaLocation have not changed
> noNamespaceSchemaLocation
> + assertEquals("http://www.example.com/Report.xsd emp.xsd",
> doc.getNoNamespaceSchemaLocation());
> +}
> +
> + /**
> + * This method will load an xml document consisting of a
> xsi:schemaLocation and
> + * xsi:noNamespaceSchemaLocation defined. It will then use the
> XMLDocument API to get and
> + * set the noNamespaceSchemaLocation property.
> + *
> + * @throws IOException
> + */
> + public void testNoNamespaceSchemaLocation() throws IOException
> + {
> + // load the xml document which has xsi:noNamespaceSchemaLocation and
> xsi:schemaLocation defined
> + XMLDocument doc =
> XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
> +
> + // get the noNamespaceSchemaLocation
> + assertEquals("http://www.example.com/Report.xsd emp.xsd",
> doc.getNoNamespaceSchemaLocation());
> +
> + // set the noNameSpaceSchemaLocation to another value and test to see
> if the value was set
> + doc.setNoNamespaceSchemaLocation("noNamespaceSchemaLocation");
> + assertEquals("noNamespaceSchemaLocation",
> doc.getNoNamespaceSchemaLocation());
> +
> + // remove the noNameSpaceSchemaLocation and ensure it returns null
> + doc.setNoNamespaceSchemaLocation(null);
> + assertNull(doc.getNoNamespaceSchemaLocation());
> +
> + // ensure changes to noNameSpaceSchemaLocation have not changed
> schemaLocation
> + assertEquals("http://www.example.org/emp emp.xsd
> http://www.example.
[jira] Updated: (TUSCANY-216) recent change to JavaFactoryImpl.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-216?page=all ] Paul Golick updated TUSCANY-216: Attachment: svn142diff.txt The attached patch suggests a fix that replaces the Character.valueOf method with a Character constructor. > recent change to JavaFactoryImpl.java is not compatible with JDK 1.4 > > > Key: TUSCANY-216 > URL: http://issues.apache.org/jira/browse/TUSCANY-216 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: svn version 396576 > Reporter: Paul Golick > Attachments: svn142diff.txt > > The recent change used the valueOf(char) method of the Character class that > was added in Java 1.5. That method is not available in Java 1.4. However, a > constructor is available for both Java 1.4 and Java 1.5. -- 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
[jira] Created: (TUSCANY-216) recent change to JavaFactoryImpl.java is not compatible with JDK 1.4
recent change to JavaFactoryImpl.java is not compatible with JDK 1.4 Key: TUSCANY-216 URL: http://issues.apache.org/jira/browse/TUSCANY-216 Project: Tuscany Type: Bug Components: Java SDO Implementation Environment: svn version 396576 Reporter: Paul Golick The recent change used the valueOf(char) method of the Character class that was added in Java 1.5. That method is not available in Java 1.4. However, a constructor is available for both Java 1.4 and Java 1.5. -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12372331 ] Paul Golick commented on TUSCANY-137: - Frank, The patches that need to be applied are: spec.patch applied relative to Tuscany\java\spec sdo_revised.patch applied relative to Tuscany\java\sdo The sdo_revised.patch file includes the changes of sdo.patch plus the changes that I described in my comment of yesterday. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, sdo_revised.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12372159 ] Paul Golick commented on TUSCANY-137: - Thanks to Jeremy, I have a patch that works on Java 1.4 and have attached a revised version of sdo.patch. In addition to the changes in spec.patch and sdo.patch, these files needed to be changed so that a Java 1.4 JRE could load and run the code (I tested with IBM's 142 JVM): impl/src/test/java/org/apache/tuscany/sdo/test/TestUtil.java Added private static methods to replace Node.isEqualNode(Node) method. Commented out use of Node.isEqualNode(Node) and added use of replacement method. Changed Document.normalizeDocument() to Document.normalize() twice. Commented out use of Document.getXmlVersion(). impl/src/test/java/org/apache/tuscany/sdo/codegen/JavaInterfaceGeneratorTestCase.java Changed StringBuilder to StringBuffer. impl/src/main/java/org/apache/tuscany/sdo/helper/XSDHelperImpl.java Changed IllegalArgumentException(e) to IllegalArgumentException(e.getMessage()). impl\src\main\java\org\apache\tuscany\sdo\codegen\BytecodeInterfaceGenerator.java Changed from V1_5 to V1_4 in visitType method. impl/src/main/java/org/apache/tuscany/sdo/codegen/JavaInterfaceGenerator.java Added private static canonicalize method based on javadoc of Class.getName() and execution comparison with Class.getCanonicalName(). Changed property.getType().getInstanceClass().getCanonicalName() to canonicalize(property.getType().getInstanceClass().getName()). Incidentally, I also discovered the reason I had problems applying sdo.patch: apparently "svn diff" preserves whatever line ending characters it finds in the patch file it generates. The version of the "patch" command that I have (from cygwin) strips any CR characters it finds in a patch when the patched file lacks them but it refuses to add a CR character to match a line when the patch file lacks CR but the patched file has a CR and refuses to apply the patch at that location. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, sdo_revised.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12372035 ] Paul Golick commented on TUSCANY-137: - To enable a 1.4.2 JRE to load the generated code, only four files needed to be changed: impl/src/test/java/org/apache/tuscany/sdo/test/TestUtil.java Added private static functions to replace Node.isEqualNode(Node) method (this was fairly extensive but easy since the isEqualNode documentation specified how to do it). Commented out use of Node.isEqualNode(Node) and added use of replacement method. Changed Document.normalizeDocument() to Document.normalize() twice. Commented out use of Document.getXmlVersion(). impl/src/test/java/org/apache/tuscany/sdo/codegen/JavaInterfaceGeneratorTestCase.java Changed StringBuilder to StringBuffer. Although this compiles with 1.4, execution by 1.4 JRE fails in testByteArrayProperty in the assertEquals method. I will investigate this further. impl/src/main/java/org/apache/tuscany/sdo/helper/XSDHelperImpl.java Changed IllegalArgumentException(e) to IllegalArgumentException(e.getMessage()). impl/src/main/java/org/apache/tuscany/sdo/codegen/JavaInterfaceGenerator.java Changed Class.getCanonicalName() to Class.getName(). In addition to the changes I made, I ran "mvn" to check for other test breaks and found: impl/src/test/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGeneratorTestCase.java Although I made no additional changes to this file, all test cases fail execution by a 1.4 JRE with an UnsupportedClassVersionError while calling defineClass method in addclass. I will investigate this further as well. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12371807 ] Paul Golick commented on TUSCANY-137: - It is not just the use of the Xerces update that causes the problem; XSDHelperImpl uses a constructor for IllegalArgumentException that was not added until 1.5. I any case, it appears it will be reasonably easy for us to make the minor changes needed to attract 1.4.2 users. I say "minor changes" because it appears that the sdo-api, tuscany-sdo-plugin, and tuscany-sdo-tools projects are unaffected; only the tuscany-sdo-impl project needs changes and the changes hit the test cases worse than the actual implementation code. I can post the full list of affected files on Monday. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12371797 ] Paul Golick commented on TUSCANY-137: - There remain some other problems that prevent a JDK 1.4 system from loading SDO2 class files: these files have been compiled with a Java 1.5 library. As an example of this problem, org\apache\tuscany\sdo\test\TestUtil.java uses the getXmlVersion() method of the org.w3c.dom.Document class but this method was added in 1.5 and is not present in the 1.4.2 class library. I have been compiling a list of cases such as this but am not yet done. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12371793 ] Paul Golick commented on TUSCANY-137: - Please ignore my prior comment. I do not know why the patch tool failed. When I applied your changes by hand, I got good compiles and "svn diff" generated a patch file identical to the one you posted. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Commented: (TUSCANY-137) According to spec, sdo should be JDK 1.4 compatible
[ http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12371788 ] Paul Golick commented on TUSCANY-137: - I had some problems applying the sdo.patch file. When applying to checkout version 388612, patch gave me these error messages: patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOExtendedMetaDa taImpl.java Hunk #1 FAILED at 39. 1 out of 1 hunk FAILED -- saving rejects to file impl/src/main/java/org/apache/t uscany/sdo/helper/SDOExtendedMetaDataImpl.java.rej patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOXSDEcoreBuilde r.java Hunk #1 FAILED at 35. Hunk #2 FAILED at 48. Hunk #3 FAILED at 61. Hunk #4 FAILED at 70. Hunk #5 FAILED at 79. Hunk #6 FAILED at 92. Hunk #7 FAILED at 101. Hunk #8 FAILED at 194. Hunk #9 FAILED at 201. Hunk #10 FAILED at 218. 10 out of 10 hunks FAILED -- saving rejects to file impl/src/main/java/org/apach e/tuscany/sdo/helper/SDOXSDEcoreBuilder.java.rej I got no error messages on the other file changes. > According to spec, sdo should be JDK 1.4 compatible > --- > > Key: TUSCANY-137 > URL: http://issues.apache.org/jira/browse/TUSCANY-137 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Reporter: Daniel Kulp > Attachments: sdo.patch, spec.patch > > Patches to update spec/sdo and sdo to be source/target=1.4 -- 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
[jira] Updated: (TUSCANY-119) XMLDocumentImpl should implement get/setSchemaLocation and get/setNoNamespaceSchemaLocation
[ http://issues.apache.org/jira/browse/TUSCANY-119?page=all ]
Paul Golick updated TUSCANY-119:
Attachment: XMLDocumentImplPatch.txt
The patch is attached as a file, for your convenience.
> XMLDocumentImpl should implement get/setSchemaLocation and
> get/setNoNamespaceSchemaLocation
> ---
>
> Key: TUSCANY-119
> URL: http://issues.apache.org/jira/browse/TUSCANY-119
> Project: Tuscany
> Type: New Feature
> Components: Java SDO Implementation
> Reporter: Paul Golick
> Attachments: XMLDocumentImplPatch.txt
>
> A patch containing a suggested solution and its test case follows:
> Index:
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
> ===
> ---
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
>(revision 0)
> +++
> C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
>(revision 0)
> @@ -0,0 +1,88 @@
> +/**
> + *
> + * Copyright 2005 The Apache Software Foundation or its licensors, as
> applicable.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.tuscany.sdo.test;
> +
> +import java.io.IOException;
> +
> +import junit.framework.TestCase;
> +
> +import commonj.sdo.helper.XMLDocument;
> +import commonj.sdo.helper.XMLHelper;
> +
> +public class XMLDocumentTestCase extends TestCase {
> +
> + private final String SCHEMA_XML = "/XMLDocumentTestCase.xml";
> +
> + /**
> + * This method will load an xml document consisting of a
> xsi:schemaLocation and
> + * xsi:noNamespaceSchemaLocation defined. It will then use the
> XMLDocument API to get and
> + * set the schemaLocation property.
> + *
> + * @throws IOException
> + */
> + public void testSchemaLocation() throws IOException
> + {
> + // load the xml document which has xsi:noNamespaceSchemaLocation and
> xsi:schemaLocation defined
> + XMLDocument doc =
> XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
> +
> + // get the schemaLocation
> + assertEquals("http://www.example.org/emp emp.xsd
> http://www.example.com/Report http://www.example.com/Report.xsd";,
> doc.getSchemaLocation());
> +
> + // set the schemaLocation to another value and test to see if the
> value was set
> + doc.setSchemaLocation("namespace schemaLocation");
> + assertEquals("namespace schemaLocation", doc.getSchemaLocation());
> +
> + // remove the schemaLocation and ensure it returns null
> + doc.setSchemaLocation(null);
> + assertNull(doc.getSchemaLocation());
> +
> + // ensure changes to schemaLocation have not changed
> noNamespaceSchemaLocation
> + assertEquals("http://www.example.com/Report.xsd emp.xsd",
> doc.getNoNamespaceSchemaLocation());
> +}
> +
> + /**
> + * This method will load an xml document consisting of a
> xsi:schemaLocation and
> + * xsi:noNamespaceSchemaLocation defined. It will then use the
> XMLDocument API to get and
> + * set the noNamespaceSchemaLocation property.
> + *
> + * @throws IOException
> + */
> + public void testNoNamespaceSchemaLocation() throws IOException
> + {
> + // load the xml document which has xsi:noNamespaceSchemaLocation and
> xsi:schemaLocation defined
> + XMLDocument doc =
> XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
> +
> + // get the noNamespaceSchemaLocation
> + assertEquals("http://www.example.com/Report.xsd emp.xsd",
> doc.getNoNamespaceSchemaLocation());
> +
> + // set the noNameSpaceSchemaLocation to another value and test to see
> if the value was set
> + doc.setNoNamespaceSchemaLocation("noNamespaceSchemaLocation");
> + assertEquals("noNamespaceSchemaLocation",
> doc.getNoNamespaceSchemaLocation());
> +
> + // remove the noNameSpaceSchemaLocation and ensure it returns null
> + doc.setNoNamespaceSchemaLocation(null);
> + assertNull(doc.getNoNamespaceSchemaLocation());
> +
> + // ensure changes to noNameSpaceSchemaLocation have not changed
> schemaLocation
> + assertEquals("http://www.example.org/emp emp.xsd
> http://www.example.c
[jira] Created: (TUSCANY-119) XMLDocumentImpl should implement get/setSchemaLocation and get/setNoNamespaceSchemaLocation
XMLDocumentImpl should implement get/setSchemaLocation and
get/setNoNamespaceSchemaLocation
---
Key: TUSCANY-119
URL: http://issues.apache.org/jira/browse/TUSCANY-119
Project: Tuscany
Type: New Feature
Components: Java SDO Implementation
Reporter: Paul Golick
A patch containing a suggested solution and its test case follows:
Index:
C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
===
---
C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
(revision 0)
+++
C:/Tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/XMLDocumentTestCase.java
(revision 0)
@@ -0,0 +1,88 @@
+/**
+ *
+ * Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tuscany.sdo.test;
+
+import java.io.IOException;
+
+import junit.framework.TestCase;
+
+import commonj.sdo.helper.XMLDocument;
+import commonj.sdo.helper.XMLHelper;
+
+public class XMLDocumentTestCase extends TestCase {
+
+ private final String SCHEMA_XML = "/XMLDocumentTestCase.xml";
+
+ /**
+ * This method will load an xml document consisting of a xsi:schemaLocation
and
+ * xsi:noNamespaceSchemaLocation defined. It will then use the XMLDocument
API to get and
+ * set the schemaLocation property.
+ *
+ * @throws IOException
+ */
+ public void testSchemaLocation() throws IOException
+ {
+ // load the xml document which has xsi:noNamespaceSchemaLocation and
xsi:schemaLocation defined
+ XMLDocument doc =
XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
+
+ // get the schemaLocation
+ assertEquals("http://www.example.org/emp emp.xsd
http://www.example.com/Report http://www.example.com/Report.xsd";,
doc.getSchemaLocation());
+
+ // set the schemaLocation to another value and test to see if the value
was set
+ doc.setSchemaLocation("namespace schemaLocation");
+ assertEquals("namespace schemaLocation", doc.getSchemaLocation());
+
+ // remove the schemaLocation and ensure it returns null
+ doc.setSchemaLocation(null);
+ assertNull(doc.getSchemaLocation());
+
+ // ensure changes to schemaLocation have not changed
noNamespaceSchemaLocation
+ assertEquals("http://www.example.com/Report.xsd emp.xsd",
doc.getNoNamespaceSchemaLocation());
+}
+
+ /**
+ * This method will load an xml document consisting of a xsi:schemaLocation
and
+ * xsi:noNamespaceSchemaLocation defined. It will then use the XMLDocument
API to get and
+ * set the noNamespaceSchemaLocation property.
+ *
+ * @throws IOException
+ */
+ public void testNoNamespaceSchemaLocation() throws IOException
+ {
+ // load the xml document which has xsi:noNamespaceSchemaLocation and
xsi:schemaLocation defined
+ XMLDocument doc =
XMLHelper.INSTANCE.load(getClass().getResourceAsStream(SCHEMA_XML));
+
+ // get the noNamespaceSchemaLocation
+ assertEquals("http://www.example.com/Report.xsd emp.xsd",
doc.getNoNamespaceSchemaLocation());
+
+ // set the noNameSpaceSchemaLocation to another value and test to see if
the value was set
+ doc.setNoNamespaceSchemaLocation("noNamespaceSchemaLocation");
+ assertEquals("noNamespaceSchemaLocation",
doc.getNoNamespaceSchemaLocation());
+
+ // remove the noNameSpaceSchemaLocation and ensure it returns null
+ doc.setNoNamespaceSchemaLocation(null);
+ assertNull(doc.getNoNamespaceSchemaLocation());
+
+ // ensure changes to noNameSpaceSchemaLocation have not changed
schemaLocation
+ assertEquals("http://www.example.org/emp emp.xsd
http://www.example.com/Report http://www.example.com/Report.xsd";,
doc.getSchemaLocation());
+}
+
+protected void setUp() throws Exception {
+super.setUp();
+}
+
+}
Index: C:/Tuscany/java/sdo/impl/src/test/resources/XMLDocumentTestCase.xml
===
--- C:/Tuscany/java/sdo/impl/src/test/resources/XMLDocumentTestCase.xml
(revision 0)
+++ C:/Tuscany/java/sdo/impl/src/test/resources/XMLDocumentTestCase.xml
(revision 0)
@@ -0,0 +1,10 @@
+http://www.example.c
