Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.2, 1.1.0, 1.2.1, 1.3.0, 2.0.0-M2
    • Fix Version/s: None
    • Component/s: build / infrastructure
    • Labels:
      None

      Description

      Now that I have a resolution (JDK patch) for OPENJPA-429, when I run a 1.1.0 build, I am getting some errors from the test phase of openjpa-persistence-jdbc. The following tests are failing according to the surefire report:

      Results :

      Tests in error:
      testEntityListeners(org.apache.openjpa.persistence.callbacks.TestEntityListeners)
      testGlobalListeners(org.apache.openjpa.persistence.callbacks.TestEntityListeners)
      testPersistenceUnitWithoutXSD(org.apache.openjpa.persistence.xml.TestPersistenceUnitWithoutXSD)
      testEnhancementOfAllPUsWithinAResource(org.apache.openjpa.enhance.TestEnhancementWithMultiplePUs)

      Tests run: 568, Failures: 0, Errors: 4, Skipped: 0

        Issue Links

          Activity

          Hide
          Donald Woods added a comment -

          Failed whether the schemaLocation was there or not in persistence.xml.
          Failed whether I pointed to the persistence_2_0.xsd (which is no on the Sun website yet but we include internally) or the 1_0.xsd (which is on the Sun website...)

          Show
          Donald Woods added a comment - Failed whether the schemaLocation was there or not in persistence.xml. Failed whether I pointed to the persistence_2_0.xsd (which is no on the Sun website yet but we include internally) or the 1_0.xsd (which is on the Sun website...)
          Hide
          Donald Woods added a comment -

          Confirmed that Sun 1.5.0_16 and 1.6.0_07 on MacOSX still has the parser bug, with an almost endless loop of -
          . . .
          at org.apache.xerces.impl.xs.XMLSchemaLoader.processJAXPSchemaSource(XMLSchemaLoader.java:588)
          at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:489)
          . . .

          Show
          Donald Woods added a comment - Confirmed that Sun 1.5.0_16 and 1.6.0_07 on MacOSX still has the parser bug, with an almost endless loop of - . . . at org.apache.xerces.impl.xs.XMLSchemaLoader.processJAXPSchemaSource(XMLSchemaLoader.java:588) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:489) . . .
          Hide
          Michael Dick added a comment -

          Moving to next release

          Show
          Michael Dick added a comment - Moving to next release
          Hide
          Michael Dick added a comment -

          Moving to next release

          Show
          Michael Dick added a comment - Moving to next release
          Hide
          Kevin Sutter added a comment -

          Patrick,
          The problem is still "unresolved". From an IBM JDK environment viewpoint, the problem still exists. From a Sun JDK viewpoint, the problem would still exist if we didn't have that special code in the XMLMetaDataParser initializer which bypasses validation. So, as my previous remarks indicated, we are running without validation for the Sun JDK and with validation for all other JDKs. If that Xerces parser problem would ever get resolved in the Sun JDK, then we'd be hitting the same problem with the Sun JDK.

          The testcase in question has been "disabled" since mid-Feb 2008.

          Technically, it's still an open Issue.

          Kevin

          Show
          Kevin Sutter added a comment - Patrick, The problem is still "unresolved". From an IBM JDK environment viewpoint, the problem still exists. From a Sun JDK viewpoint, the problem would still exist if we didn't have that special code in the XMLMetaDataParser initializer which bypasses validation. So, as my previous remarks indicated, we are running without validation for the Sun JDK and with validation for all other JDKs. If that Xerces parser problem would ever get resolved in the Sun JDK, then we'd be hitting the same problem with the Sun JDK. The testcase in question has been "disabled" since mid-Feb 2008. Technically, it's still an open Issue. Kevin
          Hide
          Patrick Linskey added a comment -

          Where do things stand on this issue?

          Show
          Patrick Linskey added a comment - Where do things stand on this issue?
          Hide
          Kevin Sutter added a comment -

          > I believe that a sufficient switch should be whether or not the XML document has an XSD in it. If it has an XSD, clearly the user wants validation; if not, clearly the user does not want to specify one.

          Nice idea, Patrick. I'll see if we can easily detect this and set validation appropriately. Thanks!

          Show
          Kevin Sutter added a comment - > I believe that a sufficient switch should be whether or not the XML document has an XSD in it. If it has an XSD, clearly the user wants validation; if not, clearly the user does not want to specify one. Nice idea, Patrick. I'll see if we can easily detect this and set validation appropriately. Thanks!
          Hide
          Patrick Linskey added a comment -

          I think that OpenJPA should parse XML documents that do not have an XSD.

          I believe that a sufficient switch should be whether or not the XML document has an XSD in it. If it has an XSD, clearly the user wants validation; if not, clearly the user does not want to specify one.

          Show
          Patrick Linskey added a comment - I think that OpenJPA should parse XML documents that do not have an XSD. I believe that a sufficient switch should be whether or not the XML document has an XSD in it. If it has an XSD, clearly the user wants validation; if not, clearly the user does not want to specify one.
          Hide
          Kevin Sutter added a comment -

          After a bit more digging, here's the scoop on the xml validation...

          By default, our OpenJPA code wants to validate the persistence.xml file when we read it in. In the PersistenceProductDerivation$ConfigurationParser, we set the validation to true:

          public ConfigurationParser(Map map)

          { _map = map; setCaching(false); setValidating(true); setParseText(true); }

          But, later in the static initializer for the XMLMetaDataParser, there is a check for the Sun Xerxes parser. This sets _schemaBug to true:

          static {
          try

          { // check for Xerces version 2.0.2 to see if we need to disable // schema validation, which works around the bug reported at: // http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708859 _schemaBug = "Xerces-J 2.0.2".equals(Class.forName ("org.apache.xerces.impl.Version").getField("fVersion"). get(null)); }

          catch (Throwable t)

          { // Xerces might not be available _schemaBug = false; }

          }

          So, then when we determine what type of parser (validating or not), we end up running without validation for the Sun JDK ALL THE TIME:

          if (schemaSource != null && _schemaBug)

          { if (_log != null && _log.isTraceEnabled()) _log.trace(_loc.get("parser-schema-bug")); schemaSource = null; }

          boolean validating = _validating && (getDocType() != null

          schemaSource != null);

          So, as soon as Sun's Xerxes parser gets updated with this fix, then this same testcase will fail with the Sun JDK. Which brings me back to my original point of this not being a valid test for standard JPA.

          It looks like we (OpenJPA) wanted to run with a validating parser. But, due to the bug in the Sun Xerxes parser, we've been running without validation for the Sun JDK and with validation for all other JDK's (including the IBM JDK). Since it looks like we want a validating parser, then I think this TestPersistenceUnitWithoutXSD should be removed. And, maybe we should look at providing a switch to run with or without validation.

          Comments?
          Kevin

          Show
          Kevin Sutter added a comment - After a bit more digging, here's the scoop on the xml validation... By default, our OpenJPA code wants to validate the persistence.xml file when we read it in. In the PersistenceProductDerivation$ConfigurationParser, we set the validation to true: public ConfigurationParser(Map map) { _map = map; setCaching(false); setValidating(true); setParseText(true); } But, later in the static initializer for the XMLMetaDataParser, there is a check for the Sun Xerxes parser. This sets _schemaBug to true: static { try { // check for Xerces version 2.0.2 to see if we need to disable // schema validation, which works around the bug reported at: // http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708859 _schemaBug = "Xerces-J 2.0.2".equals(Class.forName ("org.apache.xerces.impl.Version").getField("fVersion"). get(null)); } catch (Throwable t) { // Xerces might not be available _schemaBug = false; } } So, then when we determine what type of parser (validating or not), we end up running without validation for the Sun JDK ALL THE TIME: if (schemaSource != null && _schemaBug) { if (_log != null && _log.isTraceEnabled()) _log.trace(_loc.get("parser-schema-bug")); schemaSource = null; } boolean validating = _validating && (getDocType() != null schemaSource != null); So, as soon as Sun's Xerxes parser gets updated with this fix, then this same testcase will fail with the Sun JDK. Which brings me back to my original point of this not being a valid test for standard JPA. It looks like we (OpenJPA) wanted to run with a validating parser. But, due to the bug in the Sun Xerxes parser, we've been running without validation for the Sun JDK and with validation for all other JDK's (including the IBM JDK). Since it looks like we want a validating parser, then I think this TestPersistenceUnitWithoutXSD should be removed. And, maybe we should look at providing a switch to run with or without validation. Comments? Kevin
          Hide
          Patrick Linskey added a comment -

          > I'm not sure that disabling the IBM JDK's validation is the right way to go,
          > if nothing else it helps to show any cases where we have invalid tags.

          ... except that the test that is failing is one that explicitly tests OpenJPA's ability to parse a persistence.xml that does not have an XSD.

          Show
          Patrick Linskey added a comment - > I'm not sure that disabling the IBM JDK's validation is the right way to go, > if nothing else it helps to show any cases where we have invalid tags. ... except that the test that is failing is one that explicitly tests OpenJPA's ability to parse a persistence.xml that does not have an XSD.
          Hide
          Michael Dick added a comment -

          I think the spec is being a bit draconian - I could do without those 5 lines too. The problem is that the spec does require it so we have to live with it.

          Tests in the openjpa-persistence modules should include the XSD infomation, but we should be able to move the tests to the kernel module and test it with a Broker.

          I'm not sure that disabling the IBM JDK's validation is the right way to go, if nothing else it helps to show any cases where we have invalid tags.

          Show
          Michael Dick added a comment - I think the spec is being a bit draconian - I could do without those 5 lines too. The problem is that the spec does require it so we have to live with it. Tests in the openjpa-persistence modules should include the XSD infomation, but we should be able to move the tests to the kernel module and test it with a Broker. I'm not sure that disabling the IBM JDK's validation is the right way to go, if nothing else it helps to show any cases where we have invalid tags.
          Hide
          Patrick Linskey added a comment -

          I believe that it is valid to do this because it is much easier to create an XML document by hand without an XSD. Without an XSD, I can type up a persistence.xml file free-form; with the XSD; I need to find that horrible five-line chunk of text to put at the top of the file every time.

          Surely there is some way to turn off validation in the IBM parser, right?

          Show
          Patrick Linskey added a comment - I believe that it is valid to do this because it is much easier to create an XML document by hand without an XSD. Without an XSD, I can type up a persistence.xml file free-form; with the XSD; I need to find that horrible five-line chunk of text to put at the top of the file every time. Surely there is some way to turn off validation in the IBM parser, right?
          Hide
          Kevin Sutter added a comment -

          It looks like the final problem is due to the testcase introduced by OPENJPA-503. It seems that the Sun JDK's SAX parser must be non-validating, while the IBM JDK SAX parser needs to validate the persistence.xml. That's why the other three test failures were not being detected by the Sun JDK.

          Why do we think that it is valid to have a persistence.xml file without the xsd specified? According to the JPA spec, the specification of the xsd is a requirement:

          <xsd:documentation><![CDATA[
          This is the XML Schema for the persistence configuration file.
          The file must be named "META-INF/persistence.xml" in the persistence archive.
          Persistence configuration files must indicate the persistence schema by using the persistence namespace:

          http://java.sun.com/xml/ns/persistence

          and indicate the version of the schema by using the version element as shown below:

          <persistence xmlns="http://java.sun.com/xml/ns/persistence"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
          http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
          version="1.0">
          ...
          </persistence>
          ]]></xsd:documentation>

          So, is the TestPersistenceUnitWithoutXSD testcase valid?

          Kevin

          Show
          Kevin Sutter added a comment - It looks like the final problem is due to the testcase introduced by OPENJPA-503 . It seems that the Sun JDK's SAX parser must be non-validating, while the IBM JDK SAX parser needs to validate the persistence.xml. That's why the other three test failures were not being detected by the Sun JDK. Why do we think that it is valid to have a persistence.xml file without the xsd specified? According to the JPA spec, the specification of the xsd is a requirement: <xsd:documentation><![CDATA[ This is the XML Schema for the persistence configuration file. The file must be named "META-INF/persistence.xml" in the persistence archive. Persistence configuration files must indicate the persistence schema by using the persistence namespace: http://java.sun.com/xml/ns/persistence and indicate the version of the schema by using the version element as shown below: <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd " version="1.0"> ... </persistence> ]]></xsd:documentation> So, is the TestPersistenceUnitWithoutXSD testcase valid? Kevin

            People

            • Assignee:
              Kevin Sutter
              Reporter:
              Kevin Sutter
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development