Camel
  1. Camel
  2. CAMEL-5837

Problem with nested schema imports when upgrading from 2.8.6 to 2.10.2

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.10.2
    • Fix Version/s: 2.10.5, 2.11.0
    • Component/s: camel-core
    • Labels:
      None
    • Environment:

      MacOS X, java 7

    • Estimated Complexity:
      Unknown

      Description

      Hello

      I'm experiencing trouble with the validiator component when upgrading from 2.8.6 to 2.10.2.

      The problem seems to be related to imported schemas that does additional imports (all using relative paths). XSD A importing XSD B works fine. But if B in turn imports XSD C. That import seems to be resolved with the base path of A.

      All works fine in 2.8.6 but breaks when upgrading to 2.10.2.

      I will attach an example project where you can just switch version to verify the scenario.

      1. xsd_import_problem.png
        46 kB
        Johan Mörén
      2. xsd-import_example 2.zip
        31 kB
        Johan Mörén
      3. xsd-import_example-reopen.zip
        92 kB
        Johan Mörén

        Activity

        Hide
        Johan Mörén added a comment -

        run this project altering the version from 2.8.6 to 2.10.2 to verify the issue.

        Show
        Johan Mörén added a comment - run this project altering the version from 2.8.6 to 2.10.2 to verify the issue.
        Hide
        Willem Jiang added a comment -

        Camel doesn't use spring to load the schema since 2.9.x, now it only support to resolve the schema from the class path.
        You test can be worked around by adding the relative path health into the health.xsd.

        <xs:import schemaLocation="health/common/common.xsd" namespace="org.health.check.common"/>
        
        Show
        Willem Jiang added a comment - Camel doesn't use spring to load the schema since 2.9.x, now it only support to resolve the schema from the class path. You test can be worked around by adding the relative path health into the health.xsd. <xs: import schemaLocation= "health/common/common.xsd" namespace= "org.health.check.common" />
        Hide
        Johan Mörén added a comment -

        Hi, yes that works but it would make the health.xsd file invalid when working with it stand-alone in an ide like Oxygen or Intellij. Our components have been reading nested schemas from the class-path (we package it in a war-file) before. But perhaps spring did some magic and read it from the filesystem?

        Is there anyway to get the old behavior back and still upgrade to 2.10.2?

        regards,
        Johan

        Show
        Johan Mörén added a comment - Hi, yes that works but it would make the health.xsd file invalid when working with it stand-alone in an ide like Oxygen or Intellij. Our components have been reading nested schemas from the class-path (we package it in a war-file) before. But perhaps spring did some magic and read it from the filesystem? Is there anyway to get the old behavior back and still upgrade to 2.10.2? regards, Johan
        Hide
        Johan Mörén added a comment -

        Another interesting note is that nested xslt-imports/includes works without problems in 2.10.2. Is the URIResolver logic different between the validation- and xslt-component?

        Show
        Johan Mörén added a comment - Another interesting note is that nested xslt-imports/includes works without problems in 2.10.2. Is the URIResolver logic different between the validation- and xslt-component?
        Hide
        Willem Jiang added a comment -

        Xslt component doesn't use the DefaultLSResourceResolver as the resource resolver.
        I just checked the code of Spring ResourceLocator, it will use the URLResolver directly if the import resource is not start with classpath. But I doesn't find a good way to find the resource from file by using the baseURI or SystemId.

        Show
        Willem Jiang added a comment - Xslt component doesn't use the DefaultLSResourceResolver as the resource resolver. I just checked the code of Spring ResourceLocator, it will use the URLResolver directly if the import resource is not start with classpath. But I doesn't find a good way to find the resource from file by using the baseURI or SystemId.
        Hide
        Johan Mörén added a comment -

        From Camels point of view, is this new behavior (since 2.9.x), considered to be a bug or an accepted limitation of the new implementation? We are using xml-schema imports extensively and this causes a lot of trouble for us. I can imagine ways we could get around these problems but not without extensive refactoring of our current projects.

        regards,
        Johan

        Show
        Johan Mörén added a comment - From Camels point of view, is this new behavior (since 2.9.x), considered to be a bug or an accepted limitation of the new implementation? We are using xml-schema imports extensively and this causes a lot of trouble for us. I can imagine ways we could get around these problems but not without extensive refactoring of our current projects. regards, Johan
        Hide
        Giampaolo Tranchida added a comment -

        Hi,

        Same problem for me. For my point of view, this a bug or a regression.

        Any workaround with a custom LSResourceResolver ?

        Regards
        Giampaolo

        Show
        Giampaolo Tranchida added a comment - Hi, Same problem for me. For my point of view, this a bug or a regression. Any workaround with a custom LSResourceResolver ? Regards Giampaolo
        Hide
        Willem Jiang added a comment -

        Hi Giampaolo,

        This issue should be resolved from the new released Camel 2.11.0.
        I already committed the patch into camel trunk.

        Willem

        Show
        Willem Jiang added a comment - Hi Giampaolo, This issue should be resolved from the new released Camel 2.11.0. I already committed the patch into camel trunk. Willem
        Hide
        Christian Müller added a comment -

        I think we can close this issue. We have two unit test classes and multiple tests which make sure this works now.

        Show
        Christian Müller added a comment - I think we can close this issue. We have two unit test classes and multiple tests which make sure this works now.
        Hide
        Johan Mörén added a comment -

        Great news! Thank you. Looking forward to the next release.

        Show
        Johan Mörén added a comment - Great news! Thank you. Looking forward to the next release.
        Hide
        Willem Jiang added a comment -

        CAMEL-6013 has a better solution to fix this kind of issue.

        Show
        Willem Jiang added a comment - CAMEL-6013 has a better solution to fix this kind of issue.
        Hide
        Johan Mörén added a comment -

        Hello

        I tried to upgrade to 2.10.4 but it still have problems resolving my imports.

        I can confirm that the first test-case works. But when i try it with a more complex import structure it fails.

        I have compiled a new example project that i will attach to the issue that shows when the error occurs. I will also attach a picture showing the folder and import structure.

        Show
        Johan Mörén added a comment - Hello I tried to upgrade to 2.10.4 but it still have problems resolving my imports. I can confirm that the first test-case works. But when i try it with a more complex import structure it fails. I have compiled a new example project that i will attach to the issue that shows when the error occurs. I will also attach a picture showing the folder and import structure.
        Hide
        Johan Mörén added a comment - - edited

        This picture shows the imports and the order they occur in. relatedURI property extracted from debugger.

        Show
        Johan Mörén added a comment - - edited This picture shows the imports and the order they occur in. relatedURI property extracted from debugger.
        Hide
        Willem Jiang added a comment -


        I just did a quick fix for this issue and committed the patch into trunk, please verify it with latest camel 2.11-SNAPSHOT.

        Show
        Willem Jiang added a comment - I just did a quick fix for this issue and committed the patch into trunk, please verify it with latest camel 2.11-SNAPSHOT.
        Hide
        Johan Mörén added a comment -

        Thanks Willem, i just tried it with 2.11-SNAPSHOT but the import still fails on 4.xsd.

        Show
        Johan Mörén added a comment - Thanks Willem, i just tried it with 2.11-SNAPSHOT but the import still fails on 4.xsd.
        Hide
        Johan Mörén added a comment -

        Checked my local maven repo and the pom for camel-core is dated the 16th of march. So i guess your fix is not pushed to the snapshot repo yet.

        camel-core-2.11-20130316.163847-415.pom

        /j

        Show
        Johan Mörén added a comment - Checked my local maven repo and the pom for camel-core is dated the 16th of march. So i guess your fix is not pushed to the snapshot repo yet. camel-core-2.11-20130316.163847-415.pom /j
        Hide
        Johan Mörén added a comment -

        Managed to build from 2.11-SNAPSHOT from source and managed to start the route successfully. When trying against my live-code however the fault persisted. I then discovered that the schema import structure in the example wasn't quite right. In my live-code and in the attached image both 1.xsd and 2.xsd imports 4.xsd. When i corrected 2.xsd to reflect this in the example code it refused to run.

        To fix 2.xsd please replace it's content with the following code:

        <?xml version="1.0" encoding="UTF-8"?>
        <xs:schema 
            xmlns:xs="http://www.w3.org/2001/XMLSchema" 
            elementFormDefault="qualified"
            targetNamespace="example.2">
            
            <xs:import schemaLocation="../../common/3.xsd" namespace="example.3"/>
            <xs:import schemaLocation="../common/4.xsd" namespace="example.4"/>
            
        </xs:schema>
        
        

        When debugging this i found that the baseURI, used as key in the relatedURIMap, is not correct (the start and end of the path is correct but it is lacking path elements in the middle). I'm not sure if this is the cause of the problem.

        Show
        Johan Mörén added a comment - Managed to build from 2.11-SNAPSHOT from source and managed to start the route successfully. When trying against my live-code however the fault persisted. I then discovered that the schema import structure in the example wasn't quite right. In my live-code and in the attached image both 1.xsd and 2.xsd imports 4.xsd. When i corrected 2.xsd to reflect this in the example code it refused to run. To fix 2.xsd please replace it's content with the following code: <?xml version= "1.0" encoding= "UTF-8" ?> <xs:schema xmlns:xs = "http://www.w3.org/2001/XMLSchema" elementFormDefault= "qualified" targetNamespace= "example.2" > <xs:import schemaLocation= "../../common/3.xsd" namespace= "example.3" /> <xs:import schemaLocation= "../common/4.xsd" namespace= "example.4" /> </xs:schema> When debugging this i found that the baseURI, used as key in the relatedURIMap, is not correct (the start and end of the path is correct but it is lacking path elements in the middle). I'm not sure if this is the cause of the problem.
        Hide
        Willem Jiang added a comment -

        Hi Johan,

        I just did a quick fix for the issue that you found yesterday.
        Please feel free to check it out for verification.

        Willem

        Show
        Willem Jiang added a comment - Hi Johan, I just did a quick fix for the issue that you found yesterday. Please feel free to check it out for verification. Willem
        Hide
        Johan Mörén added a comment -

        Hi Willem,

        That fix resolved my problems in the original project. Thank you for all your help!

        Regards,
        Johan

        Show
        Johan Mörén added a comment - Hi Willem, That fix resolved my problems in the original project. Thank you for all your help! Regards, Johan

          People

          • Assignee:
            Willem Jiang
            Reporter:
            Johan Mörén
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development