6 Replies Latest reply: Aug 16, 2013 4:52 PM by f7601bf8-8486-4551-9722-7195adfbf42c RSS

    XML Parse issues when using Network Data Model LOD with Springframework 3

    407022
      Hello,

      I am having issues with using using NDM in conjuction with Spring 3. The problem is that there is a dependency on the ConfigManager class in that it has to use Oracle's xml parser from xmlparserv2.jar, and this parser seems to have a history of problems with parsing Spring schemas.

      My setup is as follows:
      Spring Version: 3.0.1
      Oracle: 11GR2 and corresponding spatial libraries

      Note that when using the xerces parser, there is no issue here. It only while using Oracle's specific parser which appears to be hard-coded into the ConfigManager. Spring fortunately offers a workaround, where I can force it to use a specific parser when loading the spring configuration as follows:
      -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
      But this is an extra deployment task we'd rather not have. Note that this issue has been brought up before in relation to OC4J. See the following link:

      How to change the defaut xmlparser on OC4J Standalone 10.1.3.4 for Spring 3

      My question is, is there any other way to configure LOD where it won't have the dependency on the oracle parser?

      Also, fyi, here is the exception that is occurring as well as the header for my spring file.
      org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException:
      Line 11 in XML document from URL [file:/C:/projects/lrs_network_domain/service/target/classes/META-INF/spring.xml] is invalid; 
      nested exception is oracle.xml.parser.schema.XSDException: Duplicated definition for: 'identifiedType'
      
           at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
           [snip]
           ... 31 more
      Caused by: oracle.xml.parser.schema.XSDException: Duplicated definition for: 'identifiedType'
           at oracle.xml.parser.v2.XMLError.flushErrorHandler(XMLError.java:425)
           at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:287)
           at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:331)
           at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:222)
           at oracle.xml.jaxp.JXDocumentBuilder.parse(JXDocumentBuilder.java:155)
           at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75)
           at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388)
      Here is my the header for my spring configuration file:
      <?xml version="1.0" encoding="UTF-8"?>
      
      <beans xmlns="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:aop="http://www.springframework.org/schema/aop"
             xmlns:tx="http://www.springframework.org/schema/tx"
             xmlns:context="http://www.springframework.org/schema/context"
             xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
             http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd
             http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
             http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
      Thanks, Tom
        • 1. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
          462217
          Unfortunately, there is no other way to configure LOD at this moment. LOD config manager always loads/parses the config xml first. After that, you can change the configuration for your network programmatically, but there is no way around the xml, thus you do need the oracle parser.
          • 2. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
            Jack Wang
            Tom,
            Many Spatial Java APIs(including NDM LOD) use the Oracle xmlparser2.jar when parsing xml documents. If you have problems working with other API or tool kits, you may want to file a bug or enhancement request against Oracle XDK.

            jack
            • 3. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
              407022
              I have followed up with our DBA group on this issue, and they are are going to file an a bug.

              Thanks, Tom
              • 4. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
                HaveFun
                I am experiencing this same issue using springframework version 3.0.4. Do you have a bug number for this issue that I could watch to see when it gets fixed?

                Thanks,
                David
                • 5. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
                  HaveFun
                  I am experiencing this same issue using springframework version 3.0.4. Do you have a bug number for this issue that I could watch to see when it gets fixed?

                  Thanks,
                  David
                  • 6. Re: XML Parse issues when using Network Data Model LOD with Springframework 3
                    f7601bf8-8486-4551-9722-7195adfbf42c

                    I ran into this exact issue while trying to get hibernate and spring working with an oracle XMLType column, and found a better solution than to use JVM arguments as you mentioned.

                     

                    Why is it happening?

                    The xmlparserv2.jar uses the JAR Services API (Service Provider Mechanism) to change the default javax.xml classes used for the SAXParserFactory, DocumentBuilderFactory and TransformerFactory.

                     

                     

                     

                    How did it happen?

                    The javax.xml.parsers.FactoryFinder looks for custom implementations by checking for, in this order, environment variables, %JAVA_HOME%/lib/jaxp.properties, then for config files under META-INF/services on the classpath, before using the default implementations included with the JDK (com.sun.org.*).

                     

                    Inside xmlparserv2.jar exists a META-INF/services directory, which the javax.xml.parsers.FactoryFinder class picks up and uses:

                    META-INF/services/javax.xml.parsers.DocumentBuilderFactory (which defines oracle.xml.jaxp.JXDocumentBuilderFactory as the default)

                    META-INF/services/javax.xml.parsers.SAXParserFactory (which defines oracle.xml.jaxp.JXSAXParserFactory as the default)

                    META-INF/services/javax.xml.transform.TransformerFactory (which defines oracle.xml.jaxp.JXSAXTransformerFactory as the default)

                     

                    Solution?

                    Switch all 3 back, otherwise you'll see weird errors.  javax.xml.parsers.* fix the visible errors, while the javax.xml.transform.* fixes more subtle XML parsing (in my case, with apache commons configuration reading/writing).

                     


                    QUICK SOLUTION to solve the application server startup errors:

                     

                    JVM Arguments (not great)

                    To override the changes made by xmlparserv2.jar, add the following JVM properties to your application server startup arguments.  The java.xml.parsers.FactoryFinder logic will check environment variables first.

                    -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl


                    However, if you run test cases using @RunWith(SpringJUnit4ClassRunner.class) or similar, you will still experience the error.

                     

                    BETTER SOLUTION to the application server startup errors AND test case errors:

                     

                    Option 1: Use JVM arguments for the app server and @BeforeClass statements for your test cases.

                    System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");

                    System.setProperty("javax.xml.parsers.SAXParserFactory","com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");

                    System.setProperty("javax.xml.transform.TransformerFactory","com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl");


                    If you have a lot of test cases, this becomes painful.

                     

                    Option 2: Create your own Service Provider definition files in the compile/runtime classpath for your project, which will override those included in xmlparserv2.jar.

                     

                    In a maven spring project, override the xmlparserv2.jar settings by creating the following files in the %PROJECT_HOME%/src/main/resources directory:

                    %PROJECT_HOME%/src/main/resources/META-INF/services/javax.xml.parsers.DocumentBuilderFactory (which defines com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl as the default)

                    %PROJECT_HOME%/src/main/resources/META-INF/services/javax.xml.parsers.SAXParserFactory (which defines com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl as the default)

                    %PROJECT_HOME%/src/main/resources/META-INF/services/javax.xml.transform.TransformerFactory (which defines com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl as the default)

                     

                    These files are referenced by both the application server (no JVM arguments required), and solves any unit test issues without requiring any code changes.

                     

                     

                    This is a snippet of my longer solution for how to get hibernate and spring to work with an oracle XMLType column, found on stackoverflow.