Derby
  1. Derby
  2. DERBY-2739

Use DOM interfaces to implement XML operators

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: 10.8.1.2
    • Component/s: SQL
    • Labels:
      None
    • Issue & fix info:
      Release Note Needed

      Description

      Sun's Java 1.5.0 and higher includes Xalan, but Derby doesn't find it because it has been moved to a non-standard package. Derby should be able to detect and use these classes if it cannot find Xalan in the standard package on the classpath. This would make it easier for many users to start using Derby's XML features.

      See also the discussion in this thread: <URL:http://mail-archives.apache.org/mod_mbox/db-derby-dev/200705.mbox/%3c465F015C.9070404@gmail.com%3e>

      1. xml-interfaces-3.diff
        38 kB
        Knut Anders Hatlen
      2. xml-interfaces-2.diff
        38 kB
        Knut Anders Hatlen
      3. xml-interfaces.diff
        33 kB
        Knut Anders Hatlen
      4. stricter-assertions.diff
        21 kB
        Knut Anders Hatlen
      5. remove-xalan-jars.diff
        3 kB
        Knut Anders Hatlen
      6. releaseNote.html
        5 kB
        Knut Anders Hatlen
      7. releaseNote.html
        5 kB
        Rick Hillegas
      8. numeric-tests.diff
        2 kB
        Knut Anders Hatlen
      9. ns-npe.diff
        2 kB
        Knut Anders Hatlen
      10. infinity-NaN.diff
        0.7 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          I've experimented with making changes to the SqlXmlUtil class so that
          it uses the JAXP/DOM interfaces instead of the Xalan implementation
          classes to make it independent of the actual underlying implementation.

          The attached patch (xml-interfaces.diff) is just for testing. It needs
          more polishing before it can be committed, but in its current state it
          successfully runs all the XML tests on Oracle's Java 6, without
          separate Xalan jars on the classpath.

          In short, the patch changes from the following implementation classes
          to these interfaces:

          org.apache.xalan.serialize.Serializer -> javax.xml.transform.Transformer
          org.apache.xpath.XPath -> org.w3c.dom.xpath.XPathEvaluator

          The javax.xml.transform.Transformer interface is part of JDK 1.4.2,
          but org.w3c.dom.xpath.XPathEvaluator isn't, so this change means we'll
          have to reintroduce the xml-apis.jar file (part of Xalan) that we
          removed in DERBY-3702. But only as a build dependency. On the bright
          side, we shouldn't need xalan.jar, xercesImpl.jar or serializer.jar in
          the build anymore.

          There are interfaces that provide support for XPath in JDK 1.4.2 too,
          but those interfaces require us to know up front what the return type
          of an XPath query is, and we don't have that information when we
          compile the query. org.w3c.dom.xpath.XPathEvaluator doesn't have this
          restriction.

          To test the patch, get xml-apis.jar from the Subversion history with
          this command:

          svn copy https://svn.apache.org/repos/asf/db/derby/code/trunk/tools/java/xml-apis.jar@588374 tools/java

          Some missing parts that need to be worked out before the patch is
          ready are:

          1) Formatting of floating point numbers is done differently. The
          current code uses org.apache.xpath.objects.XNumber.str() to format the
          numbers, and the patch uses Double.toString(). Double.toString() uses
          exponents/scientific notation to make the result string more compact,
          whereas XNumber.str() doesn't use exponents. There are currently no
          tests that expose this difference.

          2) The original code uses an instance of
          org.apache.xml.utils.PrefixResolverDefault to resolve prefixes when
          evaluating XPath queries. According to the comments, this is needed in
          order to prevent NPEs in some queries. However, none of the XML tests
          failed when tried to replace the resolver with null in the original
          code. So some more investigation is needed in order to find out what
          problem this code is supposed to fix, and if something special is
          needed to handle that in the new code.

          Here are some more details about what the patch does:

          M java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java

          Remove code that's not used anymore

          M tools/ant/properties/extrapath.properties
          M java/engine/org/apache/derby/iapi/types/build.xml

          Compile SqlXmlUtil.java against xml-apis.jar instead of xercesImpl.jar.

          M java/engine/org/apache/derby/iapi/types/XML.java

          Stop looking for Xalan implementation classes, and instead see if we
          have the JAXP interfaces and check that the DOM implementation
          supports the required XPath functionality.

          M java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java

          Use the interfaces as described above.

          M java/testing/org/apache/derbyTesting/junit/XML.java

          Check for JAXP interfaces and DOM level instead of a specific Xalan
          version, and rename methods accordingly.

          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/XMLMissingClassesTest.java
          M java/testing/org/apache/derbyTesting/junit/EnvTest.java

          Use the new helper methods that check if the XML operators are
          supported.

          Show
          Knut Anders Hatlen added a comment - I've experimented with making changes to the SqlXmlUtil class so that it uses the JAXP/DOM interfaces instead of the Xalan implementation classes to make it independent of the actual underlying implementation. The attached patch (xml-interfaces.diff) is just for testing. It needs more polishing before it can be committed, but in its current state it successfully runs all the XML tests on Oracle's Java 6, without separate Xalan jars on the classpath. In short, the patch changes from the following implementation classes to these interfaces: org.apache.xalan.serialize.Serializer -> javax.xml.transform.Transformer org.apache.xpath.XPath -> org.w3c.dom.xpath.XPathEvaluator The javax.xml.transform.Transformer interface is part of JDK 1.4.2, but org.w3c.dom.xpath.XPathEvaluator isn't, so this change means we'll have to reintroduce the xml-apis.jar file (part of Xalan) that we removed in DERBY-3702 . But only as a build dependency. On the bright side, we shouldn't need xalan.jar, xercesImpl.jar or serializer.jar in the build anymore. There are interfaces that provide support for XPath in JDK 1.4.2 too, but those interfaces require us to know up front what the return type of an XPath query is, and we don't have that information when we compile the query. org.w3c.dom.xpath.XPathEvaluator doesn't have this restriction. To test the patch, get xml-apis.jar from the Subversion history with this command: svn copy https://svn.apache.org/repos/asf/db/derby/code/trunk/tools/java/xml-apis.jar@588374 tools/java Some missing parts that need to be worked out before the patch is ready are: 1) Formatting of floating point numbers is done differently. The current code uses org.apache.xpath.objects.XNumber.str() to format the numbers, and the patch uses Double.toString(). Double.toString() uses exponents/scientific notation to make the result string more compact, whereas XNumber.str() doesn't use exponents. There are currently no tests that expose this difference. 2) The original code uses an instance of org.apache.xml.utils.PrefixResolverDefault to resolve prefixes when evaluating XPath queries. According to the comments, this is needed in order to prevent NPEs in some queries. However, none of the XML tests failed when tried to replace the resolver with null in the original code. So some more investigation is needed in order to find out what problem this code is supposed to fix, and if something special is needed to handle that in the new code. Here are some more details about what the patch does: M java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java Remove code that's not used anymore M tools/ant/properties/extrapath.properties M java/engine/org/apache/derby/iapi/types/build.xml Compile SqlXmlUtil.java against xml-apis.jar instead of xercesImpl.jar. M java/engine/org/apache/derby/iapi/types/XML.java Stop looking for Xalan implementation classes, and instead see if we have the JAXP interfaces and check that the DOM implementation supports the required XPath functionality. M java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java Use the interfaces as described above. M java/testing/org/apache/derbyTesting/junit/XML.java Check for JAXP interfaces and DOM level instead of a specific Xalan version, and rename methods accordingly. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/XMLMissingClassesTest.java M java/testing/org/apache/derbyTesting/junit/EnvTest.java Use the new helper methods that check if the XML operators are supported.
          Hide
          Knut Anders Hatlen added a comment -

          I added testing of numeric return values to XMLTypeAndOpsTest. These tests fail if the xml-interfaces.diff patch is applied, partly because the patched code returns numbers with higher precision than what the current code does (probably a good thing), and partly because the patched code returns floating point numbers in scientific notation (should probably be changed).

          Committed numeric-tests.diff to trunk with revision 1054962.

          Show
          Knut Anders Hatlen added a comment - I added testing of numeric return values to XMLTypeAndOpsTest. These tests fail if the xml-interfaces.diff patch is applied, partly because the patched code returns numbers with higher precision than what the current code does (probably a good thing), and partly because the patched code returns floating point numbers in scientific notation (should probably be changed). Committed numeric-tests.diff to trunk with revision 1054962.
          Hide
          Knut Anders Hatlen added a comment -

          Also added test cases for XPath queries that return NaN and positive/negative infinity.

          Committed infinity-NaN.diff to trunk with revision 1054968.

          Show
          Knut Anders Hatlen added a comment - Also added test cases for XPath queries that return NaN and positive/negative infinity. Committed infinity-NaN.diff to trunk with revision 1054968.
          Hide
          Knut Anders Hatlen added a comment -

          Here's a test case for the previously mentioned issue with PrefixResolverDefault. The comments in the code mentioned that we'd get NPEs if we didn't have a prefix resolver, but none of the tests failed if the resolver was removed. The attached patch (ns-npe.diff) exposes this problem by executing an XPath query that contains a function call prefixed by a namespace.

          The expected result in the test case is a failure during compilation of the query, and that's exactly what we see. If the PrefixResolverDefault object isn't provided, though, the query is compiled successfully. Instead, it fails during execution with a NullPointerException hidden deep down in its exception chain.

          The changes in the xml-interfaces.diff patch don't make this test case fail, even though it doesn't explicitly provide a resolver, so it looks like we don't need any special handling of this problem in the new code.

          Committed the new test case to trunk with revision 1054991.

          Show
          Knut Anders Hatlen added a comment - Here's a test case for the previously mentioned issue with PrefixResolverDefault. The comments in the code mentioned that we'd get NPEs if we didn't have a prefix resolver, but none of the tests failed if the resolver was removed. The attached patch (ns-npe.diff) exposes this problem by executing an XPath query that contains a function call prefixed by a namespace. The expected result in the test case is a failure during compilation of the query, and that's exactly what we see. If the PrefixResolverDefault object isn't provided, though, the query is compiled successfully. Instead, it fails during execution with a NullPointerException hidden deep down in its exception chain. The changes in the xml-interfaces.diff patch don't make this test case fail, even though it doesn't explicitly provide a resolver, so it looks like we don't need any special handling of this problem in the new code. Committed the new test case to trunk with revision 1054991.
          Hide
          Knut Anders Hatlen added a comment -

          XMLTypeAndOpsTest has many negative test cases that expect compile-time errors. However, these tests use assertStatementError(), which doesn't care whether the error happens at compile-time or during execution. The attached patch (stricter-assertions.diff) changes many calls from assertStatementError() to assertCompileError() so that we'll detect if a change moves the error from compile-time to run-time.

          Committed revision 1055031.

          Show
          Knut Anders Hatlen added a comment - XMLTypeAndOpsTest has many negative test cases that expect compile-time errors. However, these tests use assertStatementError(), which doesn't care whether the error happens at compile-time or during execution. The attached patch (stricter-assertions.diff) changes many calls from assertStatementError() to assertCompileError() so that we'll detect if a change moves the error from compile-time to run-time. Committed revision 1055031.
          Hide
          Knut Anders Hatlen added a comment -

          I'm changing the issue summary so that it's not tied to one particular vendor/version of the JVM.

          Show
          Knut Anders Hatlen added a comment - I'm changing the issue summary so that it's not tied to one particular vendor/version of the JVM.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a new patch, xml-interfaces-2.diff, which supersedes the
          xml-interfaces.diff patch. There aren't many differences between the
          two patches, so the description in the comment from 03/Jan/11 is still
          accurate. Also note the svn magic mentioned in that comment to
          reintroduce tools/java/xml-apis.jar for the build.

          The new patch adds some more comments, and it addresses the only known
          outstanding issue with the previous patch, that is, formatting of
          numbers returned by XPath queries had changed from the original
          implementation.

          In short, the problem was that the previous patch used
          Double.toString() to format the numbers, which caused these
          differences:

          • scientific notation was used for sufficiently small or big
            numbers, for instance "1.23E-5" instead of "0.0000123"
          • trailing zeros after the decimal point weren't removed, so we'd
            get "14.0" instead of "14"

          Especially this latter difference caused problems, for example when
          inserting results from XPath queries into columns of type INT, since
          the former string ("14.0") couldn't be cast to INT. The XPath
          libraries return all numbers as double values, so there's no way to
          know whether the query actually returned the integer 14 or the
          floating point number 14.0.

          In this patch, the formatting of numbers is changed back to how it
          used to be. The original implementation would format numbers the same
          way as the XPath string function, as described here:
          http://www.w3.org/TR/xpath/#function-string

          I didn't find any method in the Java class library that formatted the
          numbers exactly that way, but I found that BigDecimal.toPlainString()
          was very close, and if we manually removed trailing zeros (including
          the decimal point if the entire fraction part is zero), the results
          seemed to be identical to the old results, and the tests passed.

          Now the problem was that toPlainString() was a new method in Java 5,
          so it's not avaialble on Java 1.4 or CDC Foundation Profile 1.1, which
          we still need to support. Luckily, on those older platforms,
          BigDecimal.toString() is defined the same way as toPlainString() on
          newer platforms. The definition of toString() was changed in Java 5,
          so we cannot use that method on all platforms, but using
          toPlainString() when available and falling back to toString()
          otherwise, seems to give consistent results across the platforms
          (tested with 1.4.2, 1.5.0 and 1.6.0).

          The resulting code in SqlXmlUtil.numberToString() is a bit ugly, using
          reflection to call the correct method, but I thought that doing it
          this way was less error-prone than writing our own code to format the
          numbers manually.

          Show
          Knut Anders Hatlen added a comment - Attaching a new patch, xml-interfaces-2.diff, which supersedes the xml-interfaces.diff patch. There aren't many differences between the two patches, so the description in the comment from 03/Jan/11 is still accurate. Also note the svn magic mentioned in that comment to reintroduce tools/java/xml-apis.jar for the build. The new patch adds some more comments, and it addresses the only known outstanding issue with the previous patch, that is, formatting of numbers returned by XPath queries had changed from the original implementation. In short, the problem was that the previous patch used Double.toString() to format the numbers, which caused these differences: scientific notation was used for sufficiently small or big numbers, for instance "1.23E-5" instead of "0.0000123" trailing zeros after the decimal point weren't removed, so we'd get "14.0" instead of "14" Especially this latter difference caused problems, for example when inserting results from XPath queries into columns of type INT, since the former string ("14.0") couldn't be cast to INT. The XPath libraries return all numbers as double values, so there's no way to know whether the query actually returned the integer 14 or the floating point number 14.0. In this patch, the formatting of numbers is changed back to how it used to be. The original implementation would format numbers the same way as the XPath string function, as described here: http://www.w3.org/TR/xpath/#function-string I didn't find any method in the Java class library that formatted the numbers exactly that way, but I found that BigDecimal.toPlainString() was very close, and if we manually removed trailing zeros (including the decimal point if the entire fraction part is zero), the results seemed to be identical to the old results, and the tests passed. Now the problem was that toPlainString() was a new method in Java 5, so it's not avaialble on Java 1.4 or CDC Foundation Profile 1.1, which we still need to support. Luckily, on those older platforms, BigDecimal.toString() is defined the same way as toPlainString() on newer platforms. The definition of toString() was changed in Java 5, so we cannot use that method on all platforms, but using toPlainString() when available and falling back to toString() otherwise, seems to give consistent results across the platforms (tested with 1.4.2, 1.5.0 and 1.6.0). The resulting code in SqlXmlUtil.numberToString() is a bit ugly, using reflection to call the correct method, but I thought that doing it this way was less error-prone than writing our own code to format the numbers manually.
          Hide
          Knut Anders Hatlen added a comment -

          All the regression tests ran cleanly with Sun's Java 6. I've also verified that the XML tests pass with 1.4.2 and 1.5.0. Setting the "Patch Available" flag.

          Show
          Knut Anders Hatlen added a comment - All the regression tests ran cleanly with Sun's Java 6. I've also verified that the XML tests pass with 1.4.2 and 1.5.0. Setting the "Patch Available" flag.
          Hide
          Knut Anders Hatlen added a comment -

          Uploading version 3 of the patch, with these minor changes:

          1) Removed some debug code that I'd forgotten in the test framework.

          2) Improved the checking of XPath requirements by using DOMImplementation.getFeature() instead of DOMImplementation.hasFeature(). The problem solved by this change is when a recent and fully capable Xalan is on the classpath with a Java 1.4.2 implementation, but not in an endorsed directory. In that case, the Xalan implementation satisfies the requirements, but the interfaces don't (because xml-apis.jar doesn't override the old interfaces that come with the JVM unless it's in an endorsed directory).

          Since hasFeature() is a DOM Level 2 method available in Java 1.4.2, whereas getFeature() is DOM Level 3, we could have the situation where hasFeature() exists and says that XPath level 3 is supported by the implementation (which is true), but when we try to use it by calling getFeature(), we get a NoSuchMethodError because the interface is too old.

          By using the getFeature() method to check the level of support, we'll detect this lack of supporting interfaces earlier so that we don't attempt to call methods that don't exist on the platform.

          Show
          Knut Anders Hatlen added a comment - Uploading version 3 of the patch, with these minor changes: 1) Removed some debug code that I'd forgotten in the test framework. 2) Improved the checking of XPath requirements by using DOMImplementation.getFeature() instead of DOMImplementation.hasFeature(). The problem solved by this change is when a recent and fully capable Xalan is on the classpath with a Java 1.4.2 implementation, but not in an endorsed directory. In that case, the Xalan implementation satisfies the requirements, but the interfaces don't (because xml-apis.jar doesn't override the old interfaces that come with the JVM unless it's in an endorsed directory). Since hasFeature() is a DOM Level 2 method available in Java 1.4.2, whereas getFeature() is DOM Level 3, we could have the situation where hasFeature() exists and says that XPath level 3 is supported by the implementation (which is true), but when we try to use it by calling getFeature(), we get a NoSuchMethodError because the interface is too old. By using the getFeature() method to check the level of support, we'll detect this lack of supporting interfaces earlier so that we don't attempt to call methods that don't exist on the platform.
          Hide
          Knut Anders Hatlen added a comment -

          I've done some more testing with the xml-interfaces-3.diff patch on
          various JVMs to see if it causes any problems. The one problem I did
          find, was that on IBM 1.4.2 the XML operators work out of the box with
          the original code, whereas with the patch they don't because the XML
          interfaces in that JVM are too old. Following the instructions at
          http://db.apache.org/derby/docs/dev/devguide/cdevstandardsxml.html and
          pointing java.endorsed.dirs to a recent Xalan version makes them work
          again.

          I suppose we could have two implementations of SqlXmlUtil so that
          every configuration that worked with the old implementation would work
          with no configuration changes after the upgrade. However, since this
          only affects one rather old platform, I'm leaning towards just adding
          a release note saying that those who need XML support on that platform
          should install a more recent Xalan. Any opinions?

          Here's the full list of JVMs tested with the patch and how the
          behaviour changed:

          • phoneME Advanced: No change. Xalan must be added to the classpath in
            order to get the XML operators working. (I assume the same is true
            for weme, but I haven't tested that configuration.)
          • Sun 1.4.2: No change. Xalan must be added to an endorsed directory,
            as specified in the developers guide.
          • IBM 1.4.2: CHANGED Xalan must be added to an endorsed directory,
            whereas it used to work out of the box with the old implementation.
          • Sun 1.5.0: No change. Xalan must be added to the classpath.
          • IBM 1.5.0: No change. XML operators work out of the box.
          • Sun 1.6.0: CHANGED XML operators now work out of the box, whereas
            Xalan would have to be added to the classpath in the old
            implementation.
          • IBM 1.6.0: No change. XML operators work out of the box.
          • Oracle 1.7.0 early access: CHANGED XML operators now work out of
            the box, whereas Xalan would have to be added to the classpath in
            the old implementation.
          Show
          Knut Anders Hatlen added a comment - I've done some more testing with the xml-interfaces-3.diff patch on various JVMs to see if it causes any problems. The one problem I did find, was that on IBM 1.4.2 the XML operators work out of the box with the original code, whereas with the patch they don't because the XML interfaces in that JVM are too old. Following the instructions at http://db.apache.org/derby/docs/dev/devguide/cdevstandardsxml.html and pointing java.endorsed.dirs to a recent Xalan version makes them work again. I suppose we could have two implementations of SqlXmlUtil so that every configuration that worked with the old implementation would work with no configuration changes after the upgrade. However, since this only affects one rather old platform, I'm leaning towards just adding a release note saying that those who need XML support on that platform should install a more recent Xalan. Any opinions? Here's the full list of JVMs tested with the patch and how the behaviour changed: phoneME Advanced: No change. Xalan must be added to the classpath in order to get the XML operators working. (I assume the same is true for weme, but I haven't tested that configuration.) Sun 1.4.2: No change. Xalan must be added to an endorsed directory, as specified in the developers guide. IBM 1.4.2: CHANGED Xalan must be added to an endorsed directory, whereas it used to work out of the box with the old implementation. Sun 1.5.0: No change. Xalan must be added to the classpath. IBM 1.5.0: No change. XML operators work out of the box. Sun 1.6.0: CHANGED XML operators now work out of the box, whereas Xalan would have to be added to the classpath in the old implementation. IBM 1.6.0: No change. XML operators work out of the box. Oracle 1.7.0 early access: CHANGED XML operators now work out of the box, whereas Xalan would have to be added to the classpath in the old implementation.
          Hide
          Knut Anders Hatlen added a comment -

          I've committed xml-interfaces-3.diff to trunk with revision 1073874.

          Leaving the issue open until a release note has been attached. I'll also see if some of the jar files under tools/java can be removed now. I think xalan.jar, serializer.jar and xercesImpl.jar aren't used in the build anymore.

          Show
          Knut Anders Hatlen added a comment - I've committed xml-interfaces-3.diff to trunk with revision 1073874. Leaving the issue open until a release note has been attached. I'll also see if some of the jar files under tools/java can be removed now. I think xalan.jar, serializer.jar and xercesImpl.jar aren't used in the build anymore.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a release note for this issue.

          Show
          Knut Anders Hatlen added a comment - Attaching a release note for this issue.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a patch that removes the references to xercesImpl.jar, xalan.jar and serializer.jar from the build scripts and build instructions.

          Show
          Knut Anders Hatlen added a comment - Attaching a patch that removes the references to xercesImpl.jar, xalan.jar and serializer.jar from the build scripts and build instructions.
          Hide
          Knut Anders Hatlen added a comment -

          Removed the unused jar files and committed revision 1075360.

          Resolving the issue so that the issue shows up in the release notes.

          Show
          Knut Anders Hatlen added a comment - Removed the unused jar files and committed revision 1075360. Resolving the issue so that the issue shows up in the release notes.
          Hide
          Dave Brosius added a comment -

          >> Sun's Java 1.5.0 and higher includes Xalan, but Derby doesn't find it because it has been moved to a non-standard package. Derby should be able to detect and use these classes if it cannot find Xalan in the standard package on the classpath.

          Why wouldn't derby use the xml factories so that the choice of transformer can be done at runtime?

          Show
          Dave Brosius added a comment - >> Sun's Java 1.5.0 and higher includes Xalan, but Derby doesn't find it because it has been moved to a non-standard package. Derby should be able to detect and use these classes if it cannot find Xalan in the standard package on the classpath. Why wouldn't derby use the xml factories so that the choice of transformer can be done at runtime?
          Hide
          Knut Anders Hatlen added a comment -

          > Why wouldn't derby use the xml factories so that the choice of transformer can be done at runtime?

          Hi Dave,

          That's exactly what it does after the changes made in this issue. The transformer is now created by calling TransformerFactory.newInstance().newTransformer().

          Show
          Knut Anders Hatlen added a comment - > Why wouldn't derby use the xml factories so that the choice of transformer can be done at runtime? Hi Dave, That's exactly what it does after the changes made in this issue. The transformer is now created by calling TransformerFactory.newInstance().newTransformer().
          Hide
          Dave Brosius added a comment -

          ah ok, good. sorry for the spam.

          Show
          Dave Brosius added a comment - ah ok, good. sorry for the spam.
          Hide
          Rick Hillegas added a comment -

          Adjusted the release note.

          Show
          Rick Hillegas added a comment - Adjusted the release note.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development