Problem:
When opening an transformation (i.e., XSL) file in JDeveloper 11g, you may get the error "Failed to open the source schema: Duplicated definition for: ...".
Analysis:
Let's say that you are referencing a WSDL that is local to your project (Project1.wsdl). Let's say that this WSDL is importing a schema from the MDS. That reference may look like this:
Now let's say that in the MDS, this complex-types.xsd imports simple-types.xsd which resides in the same folder. In my example, the reference in complex-types.xsd might look like this:
And that the CustomMeta.xsd schema, which resides in an entirely different folder, also imports the same simple-types.xsd file as follows:
Basically, both complex-types.xsd and CustomMeta.xsd both import simple-types.xsd, but in different ways. complex-types.xsd uses a local reference via the ./ and CustomMeta.xsd references it via an ORAMDS lookup.
The problem is, the CustomMeta.xsd reference is translated to this HTTP URL at runtime:
To compare, notice that the first URL looks like this:
Solution:
In the example above, you have one of two options.
1. Modify complex-types.xsd to alternatively reference the sub-schema as follows:
2. Modify complex-types.xsd to alternatively reference the sub-schema as follows:
Applicable Versions:
References:
When opening an transformation (i.e., XSL) file in JDeveloper 11g, you may get the error "Failed to open the source schema: Duplicated definition for: ...".
Analysis:
Let's say that you are referencing a WSDL that is local to your project (Project1.wsdl). Let's say that this WSDL is importing a schema from the MDS. That reference may look like this:
oramds:/apps/AIAMetaData/AIAComponents/ExtensionObjectLibrary/Core/Common/complex-types.xsdIn actuality, when this is deployed to the server, it is translated to an HTTP URL automatically behind the scenes that might look like this:
http://dev.ipnweb.com:8001/soa-infra/services/EBS/ItemEBS/ItemEBS_ep?XSD=../../../../../ExtensionObjectLibrary/Core/Common/complex-types.xsdSo far, so good.
Now let's say that in the MDS, this complex-types.xsd imports simple-types.xsd which resides in the same folder. In my example, the reference in complex-types.xsd might look like this:
<xsd:include schemaLocation="./simple-types.xsd"/>Similar to what I mentioned earlier, this is translated at runtime to the following:
http://dev.ipnweb.com:8001/soa-infra/services/EBS/ItemEBS/ItemEBS_ep?XSD=../../../../../ExtensionObjectLibrary/Core/Common/./simple-types.xsdNow let's say that in the same project, you are importing another schema:
oramds:/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Infrastructure/CustomMeta.xsd
And that the CustomMeta.xsd schema, which resides in an entirely different folder, also imports the same simple-types.xsd file as follows:
<xsd:include schemaLocation="oramds:/apps/AIAMetaData/AIAComponents/ExtensionObjectLibrary/Core/Common/simple-types.xsd"/>So far, so good.
Basically, both complex-types.xsd and CustomMeta.xsd both import simple-types.xsd, but in different ways. complex-types.xsd uses a local reference via the ./ and CustomMeta.xsd references it via an ORAMDS lookup.
The problem is, the CustomMeta.xsd reference is translated to this HTTP URL at runtime:
http://dev.ipnweb.com:8001/soa-infra/services/EBS/ItemEBS/ItemEBS_ep?XSD=../../../../../ExtensionObjectLibrary/Core/Common/simple-types.xsdThis looks different!
To compare, notice that the first URL looks like this:
http://dev.ipnweb.com:8001/soa-infra/services/EBS/ItemEBS/ItemEBS_ep?XSD=../../../../../ExtensionObjectLibrary/Core/Common/./simple-types.xsdWhile the second URL looks like this:
http://dev.ipnweb.com:8001/soa-infra/services/EBS/ItemEBS/ItemEBS_ep?XSD=../../../../../ExtensionObjectLibrary/Core/Common/simple-types.xsdJDeveloper 11g thinks they are two different schemas, hence thinks that we are trying to duplicate the definitions!
Solution:
In the example above, you have one of two options.
1. Modify complex-types.xsd to alternatively reference the sub-schema as follows:
OLD: <xsd:include schemaLocation="./simple-types.xsd"/>-OR-
NEW: <xsd:include schemaLocation="simple-types.xsd"/>
2. Modify complex-types.xsd to alternatively reference the sub-schema as follows:
OLD: <xsd:include schemaLocation="./simple-types.xsd"/>You may have to bounce and/or redeploy your code to re-cache those schemas before testing again.
NEW: <xsd:include schemaLocation="oramds:/apps/AIAMetaData/AIAComponents/ExtensionObjectLibrary/Core/Common/simple-types.xsd"/>
Applicable Versions:
- Oracle JDeveloper 11g (11.1.1.5)
- Oracle SOA Suite 11g (11.1.1.5)
References:
No comments:
Post a Comment