Tuscany
  1. Tuscany
  2. TUSCANY-137

According to spec, sdo should be JDK 1.4 compatible

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Patches to update spec/sdo and sdo to be source/target=1.4

      1. spec.patch
        5 kB
        Daniel Kulp
      2. sdo.patch
        18 kB
        Daniel Kulp
      3. sdo_revised.patch
        28 kB

        Activity

        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Daniel Kulp added a comment -

        Hmm... I just tried a fresh checkout (version 388623) and the patch worked fine.

        dkulp@dilbert ~/working/tuscany/java/sdo $ svn update
        At revision 388623.
        dkulp@dilbert ~/working/tuscany/java/sdo $ svn st
        dkulp@dilbert ~/working/tuscany/java/sdo $ patch -p0 < /home/dkulp/sdo.patch
        patching file impl/src/test/java/org/apache/tuscany/sdo/test/XSDHelperTestCase.java
        patching file impl/src/test/java/org/apache/tuscany/sdo/test/TestUtil.java
        patching file impl/src/test/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGeneratorTestCase.java
        patching file impl/src/test/java/org/apache/tuscany/sdo/codegen/MockType.java
        patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOExtendedMetaDataImpl.java
        patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOXSDEcoreBuilder.java
        patching file impl/src/main/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGenerator.java
        patching file impl/src/main/java/org/apache/tuscany/sdo/util/SDOUtil.java
        patching file pom.xml
        dkulp@dilbert ~/working/tuscany/java/sdo $

        Show
        Daniel Kulp added a comment - Hmm... I just tried a fresh checkout (version 388623) and the patch worked fine. dkulp@dilbert ~/working/tuscany/java/sdo $ svn update At revision 388623. dkulp@dilbert ~/working/tuscany/java/sdo $ svn st dkulp@dilbert ~/working/tuscany/java/sdo $ patch -p0 < /home/dkulp/sdo.patch patching file impl/src/test/java/org/apache/tuscany/sdo/test/XSDHelperTestCase.java patching file impl/src/test/java/org/apache/tuscany/sdo/test/TestUtil.java patching file impl/src/test/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGeneratorTestCase.java patching file impl/src/test/java/org/apache/tuscany/sdo/codegen/MockType.java patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOExtendedMetaDataImpl.java patching file impl/src/main/java/org/apache/tuscany/sdo/helper/SDOXSDEcoreBuilder.java patching file impl/src/main/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGenerator.java patching file impl/src/main/java/org/apache/tuscany/sdo/util/SDOUtil.java patching file pom.xml dkulp@dilbert ~/working/tuscany/java/sdo $
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Daniel Kulp added a comment -

        Well, it COULD work with JDK 1.4 if the user download and adds xerces 2.8.0 to the bootstrap classpath so xerces 2.8.0 is used instead of the stuff built into the JDK. Definitely not ideal though.

        Show
        Daniel Kulp added a comment - Well, it COULD work with JDK 1.4 if the user download and adds xerces 2.8.0 to the bootstrap classpath so xerces 2.8.0 is used instead of the stuff built into the JDK. Definitely not ideal though.
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Jeremy Boynes added a comment -

        To fix the UnsupportedClassVersionError in the Bytecode tests you should change the class version supplied to ASM on line 60 of the generator:
        cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE, name, null, "java/lang/Object", interfaces);
        s/V1_5/V1_4/

        There may be other issues as well ...

        Show
        Jeremy Boynes added a comment - To fix the UnsupportedClassVersionError in the Bytecode tests you should change the class version supplied to ASM on line 60 of the generator: cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE, name, null, "java/lang/Object", interfaces); s/V1_5/V1_4/ There may be other issues as well ...
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Frank Budinsky added a comment -

        Hi Paul,

        I'm having a little trouble understanding exactly what needs to be committed to resolve this issue.

        Could you please:

        1) tell me exactly which patch files to apply (sdo_revised.patch, and spec.patch?)

        2) attach another patch file with the additional changes that need to be applied on top of those in #1 (or maybe you can just attach a merged patch file).

        Jeremy, since these are all? changes to files you added, could you please let me know if you're OK with me committing it.

        Thanks,
        Frank.

        Show
        Frank Budinsky added a comment - Hi Paul, I'm having a little trouble understanding exactly what needs to be committed to resolve this issue. Could you please: 1) tell me exactly which patch files to apply (sdo_revised.patch, and spec.patch?) 2) attach another patch file with the additional changes that need to be applied on top of those in #1 (or maybe you can just attach a merged patch file). Jeremy, since these are all? changes to files you added, could you please let me know if you're OK with me committing it. Thanks, Frank.
        Hide
        Paul Golick added a comment -

        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.

        Show
        Paul Golick added a comment - 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.
        Hide
        Frank Budinsky added a comment -

        commited patches in revision 390175

        Show
        Frank Budinsky added a comment - commited patches in revision 390175
        Hide
        Kelvin Goodson added a comment -

        Closing old resolved JIRAs that don't have a fix version and therefore cloud queries for M3 release

        Show
        Kelvin Goodson added a comment - Closing old resolved JIRAs that don't have a fix version and therefore cloud queries for M3 release

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel Kulp
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development