Bugzilla – Full Text Bug Listing
| Summary: | XML Schema validation fails when importing external schema | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Luciana Moreira <moreira> |
| Component: | wst.xml | Assignee: | wst.xml <wst.xml-inbox> |
| Status: | NEW --- | QA Contact: | Nick Sandonato <nsand.dev> |
| Severity: | normal | ||
| Priority: | P3 | CC: | alkazako, ccc, dgolovin, digulla, gregory.amerson, hauser, jesper, jure.lokar, keith.chong.ca, manderse, moreira, shr31223, stryker, thatnitind, valentinbaciu, wolfgang.knauf |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Luciana Moreira
Luciana, it looks like you are using Galileo's initial GA. That corresponds to WTP 3.1.0. There were two service releases for Galileo, and we are just days away from the release of Helios. It would be beneficial if you would try this with one of the latter releases or Helios RC3 to verify that this problem has not been fixed. Hello Carl, You are right I am using Galileo and it was a bit outdated. I have now updated all my plugins. WTP is now on version: Eclipse Web Developer Tools Version: 3.1.1.v200908120400-7R77FStEVw2z07WtDz-OZrhL5C-3 Build id: 20100211202452 The exception in the error log disappeared, but the schema is still not loaded. Instead I get a warning: schema_reference.4: Failed to read schema document: 'http://www.foo.com/hp/development/addressing.xsd', because 1)could not find the document; 2)the document could not be read; 3)the root element of the document is not <xsd:schema> None of the alternatives on the warning is the case as I have checked it several times and also validated my xsd using the W3C Online Validator http://www.w3.org/2001/03/webdata/xsv As for Helios, I have a new computer on the way and will use Helios on it. But this will take at least a month I am afraid. Luciana, are you perhaps running Eclipse behind a proxy? Can you actually access the remote schema using the Eclipse platform internal browser? If needed you can configure the Eclipse proxy settings in Preferences->General->Network Connections. It is a best practice to avoid referencing remote resources, for obvious access and performance reasons. Instead, you could download the schema and contribute it to the XML Catalog (see Preferences->XML->XML Catalog). While the screenshot may be a little bit outdated, this tutorial http://www.eclipse.org/webtools/community/tutorials/XMLCatalog/XMLCatalogTutorial.html should help. Once other thing you could check is the Eclipse internet cache under Preferences->General->Network Connections cache. Sometimes the schema may not get cached properly and the stale one may not be entirely valid. You can clear the cache through the user interface. Hello, I am still using Galileo, but the problem is now gone. I am not behind a proxy and cache was also not the issue. But thx for the nice hints :) I have updated my eclipse and the problem disappeared by itself. On my colleague's machine where eclipse is still on Galileo's initial GA all problems are there. So it looks like it is simply fixed on newer eclipse versions. Mine is now: Eclipse IDE for Java EE Developers 1.2.2.20100217-2310 epp.package.jee I bumped into this recently.
Trying to validate:
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar version="3.1" impl-version="2.0"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:s="urn:security:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-ejb3-2_0.xsd">
</jboss:ejb-jar>
gives:
src-resolve: Cannot resolve this name 'xxx' to a(n) 'type definition' component.
where 'xxx' is defined in the import done inside http://www.jboss.org/schema/jbossas/jboss-ejb3-2_0.xsd which has a <xs:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="jboss-ejb3-spec-2_0.xsd"/>
I'm using Eclipse Luna GA.
I haven't dug into all the details of this case, but there could be a tricky issue involving using/extending the the schema for XML, as the XML validator / catalog resolver treats the schema for XML as a special case. Are any of the affected schemas in your workspace's XML Catalog (declared by a plugin or added manually) ? Hi Jesper, the two involved files can be found here: http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd An instance of this might look like this: <?xml version="1.0" encoding="UTF-8"?> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1" impl-version="2.0"> <assembly-descriptor> </assembly-descriptor> </jboss:ejb-jar> This post results from a WildFly bug report: https://issues.jboss.org/browse/WFLY-3189 Think the original XSD issue was resolved. The recent validation issue is related to XML validation. Jesper, yes we contribute these xml's via plugins but the issue fails even without it afaik. Keith - i'm not sure I follow you - do you mean this needs a separate bug ? (In reply to Max Rydahl Andersen from comment #9) > Keith - i'm not sure I follow you - do you mean this needs a separate bug ? Max, Keith said that and moved this over to the SSE XML component- this bug will be used to fix that (remaining) issue Hi Carl and Keith: What kind of stuff do you need from us to replicate and begin investigating this issue? Anything we can do to help? I have new steps to replicate that may be easier for you all: 1) Take a javaee distribution of mars. 2) Note that the distro has the org.eclipse.jst.standard.schemas plugin 3) Note that the schemas plugin also has a file dtdsAndSchemas/web-app_3_1.xsd as well as dtdsAndSchemas/web-common_3_1.xsd inside of it, and that these should be resolvable by other xsd. 4) Save this schema to disk: http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd 5) Window -> Preferences -> Catalog, click "Add". Browse to the file for "location" and set the "Schema Location" to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd 6) save and exit the xml catalog preference page 7) Create a dynamic web project 8) In the web-inf folder, create a file called jboss-web.xml with the following content: <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0" > </jboss-web> 9) Save the file 10) Validate the project and see the following error in the Problems View: The errors below were detected when validating the file "jboss-web_8_0.xsd" via the file "jboss-web.xml". In most cases these errors can be detected by validating "jboss-web_8_0.xsd" directly. However it is possible that errors will only occur when jboss-web_8_0.xsd is validated in the context of jboss-web.xml. schema_reference:4; Failed to read schema document 'web_app_3_1.xsd', because 1) Could not find the document; 2) The document could not be read ... [sic] Line 75 Here's a screenshot of the error: https://issues.jboss.org/secure/attachment/12386917/Capture4.PNG This should be a pretty easy way to replicate the bug, but I'm not at all sure what to do about it. It's obvious that the standard schemas plugin includes web_app_3_1.xsd and so this should resolve fine. Any ideas what's preventing this from resolving? Is this even the same bug? Or is it a different one? The current bug here mostly had to do with schemaLocation in the header, not inside a referenced schema... so maybe this is a different bug? My first guess would be the schemaLocation reference on line 75. <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_1.xsd"/> But I don't think we can mandate that all xsd providers simply stop filling in a schemaLocation, because that doesn't make much sense. This bug is still visible in Mars M4, and I'm wondering if there's anything we can do at all here. Rob, here’s my 2c. To begin, importing the web app 3.1 schema from your schema via just its file name won’t work unless the two schemas are co-located. That can’t happen here since the web app schema is packaged inside the jst.standard.schemas plugin and your schema is packaged inside your plugin. The solution here is to refer to the web_app_3_1.xsd schema location via its schema location key as contributed to the Eclipse XML catalog, respectively http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd. Second, the xmlns for the import directive should match the target namespace of the schema being imported. So instead of the one you currently use, http://java.sun.com/xml/ns/javaee, you should use http://xmlns.jcp.org/xml/ns/javaee. Thus, the import directive should look like this: <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/> After these changes, there are still four validation errors left in the jboss-web_8_0.xsd schema. Looking at them and also peeking at the jboss-web_7_1.xsd file one can assume that including the jboss-common_6_0.xsd may help. <xsd:include schemaLocation="jboss-common_6_0.xsd”/> Indeed, adding this include solves three of the errors. Of course, you’ll want to confirm that you actually want this include and not a newer one (perhaps matching your app server version?). As for the last error: "src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions.” you’ll have to revise the symbolic-linked-allowedType complex type to conform to the XML schema specification. Hope this helps. After fixing all issues in jboss-web_8_0.xsd (see https://issues.jboss.org/browse/JBMETA-384 for details and PR) validation seems to work for me. I'm not sure what specific bug this issue is targeting any longer. I think it should be closed unless we have a specific failing case still around, in which case this bugzilla should be updated to clearly explain the usecase. Version: Mars.1 Release (4.5.1) Build id: 20150924-1200 On: Linux teletubby 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Hi guys possibly same issue: <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> results in 'schema_reference.4: Failed to read schema document:.......' and referenced element in the actual XSD file that uses the import cannot be resolved 'src-resolve: cannot resolve the name ........' I downloaded the referenced XSD from the exact URL as above saved it locally and modified the XML Catalog accordingly. The <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/> works fine. In any case the issue looks the same to me or at least very similar. ---- I an not going through HTTP proxy (In reply to Jure Lokar from comment #16) > Version: Mars.1 Release (4.5.1) > Build id: 20150924-1200 > On: Linux teletubby 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC > 2014 x86_64 x86_64 x86_64 GNU/Linux > > Hi guys possibly same issue: > > <import namespace="http://www.w3.org/2000/09/xmldsig#" > schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> I had the same problem. I fixed it by adding two entries for this schema. One maps the namespace http://www.w3.org/2000/09/xmldsig# to a local file (I have it in the workspace but it shouldn't matter). The details looks like so: Entry element: URI Location: project/schemas/xmldsig-core-schema.xsd URI: platform:/resource/project/schemas/xmldsig-core-schema.xsd Key type: Namespace name Key: http://www.w3.org/2000/09/xmldsig# The second entry maps the schema location to the same local file: Entry element: System Location: project/schemas/xmldsig-core-schema.xsd URI: platform:/resource/project/schemas/xmldsig-core-schema.xsd Key type: Schema location Key: http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd Afterwards, Eclipse could locate the file and stopped trying to downloading. |
