Community
Participate
Working Groups
Created attachment 96006 [details] Patch to fix the problem WTP Build ID: 20080404175400 In the org.eclipse.jst.standard.schemas plugin, the entries in the persistence.xml and orm.xml files are wrong. You won't notice it unless you are not connected to the internet and the XSDs haven't been previously cached and you do something that requires the XSDs. For persistence.xml the "name" attribute should be http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd instead of http://java.sun.com/xml/ns/persistence and for orm.xml, the "name" attribute should be http://java.sun.com/xml/ns/persistence/orm_1_0.xsd instead of http://java.sun.com/xml/ns/persistence/orm I have attached a patch file with the fix to this bugzilla.
What are you doing that requires the schema? I always get this mixed up, but the schema itself says ... Persistence configuration files must indicate the persistence schema by using the persistence namespace: http://java.sun.com/xml/ns/persistence and, to me that means that (the start of) a persistence.xml file would look as follows ... is this the way yours looks? <?xml version="1.0" encoding="UTF-8" ?> <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">
Valentin, does this look like we need to map both URIs?
I must say, it seems like in many existing cases, we use the whole "filename", but in the documentation for the extension point, it appears the target namespace URI is what's supposed to be? Maybe we could clear up the documentation too?
We (IBM) have some tools that need to read the schema. The header for my persistence.xml file is the same as the example you show -- it's actually generated by Dali when you add the JPA facet to a project. The documentation for the catalogContributions extension point is pretty vague about the "name" attribute for the "uri" element, all it says is "A URI reference that is not part of an external identitier", but I can tell you that the current definition in the jst.standard.schemas plugin doesn't work with the persistence.xml and orm.xml files created by Dali. The extension point is actually matching on the second URI specified in the schemaLocation attribute. While it might seem to make sense to use the namespace instead, that wouldn't work with, for instance, the J2EE XSDs, which all have the same namespace.
From what I know, the URI resolver will always honour the actual schema location if specified in an XML instance. This means that if the XML instance looks like the example given above, the catalog contribution will have to look like the corrected ones in the patch. If the XML instance does not specify a schema location, the URI resolver will use the namespace to look-up the actual schema location in the catalog and, failing that, as a last resort, it will go and fetch the schema from the the URI pointed to by the namespace and cache it locally. This URI for example http://java.sun.com/xml/ns/persistence points to an HTML page and not to the actual schema, so it's this page that will get fetched and cached. Of course, the XSD content model adapters won't be able to build a schema from this page... Here http://wiki.eclipse.org/index.php/Using_the_XML_Catalog is some documentation on the XML catalog. It's still work in progress. I think this bug should go to JST common?
No, the bug stays here, in source editing, since you all are the "content model" experts :) Even though the code may be packaged elsewhere. It almost sounds, to my naive ear, that we may need two entries, as Nitin was asking, one foe the case that someone specifies the following in their XML file: <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 <!-- no explicit location --> version="1.0"> vs. the original, that has the explicit location. <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"> The former would work _only_ if a catalog was provided, but ... is that done? Or, is that considered poor form, if not out right wrong? In either case, it's obvious we need what's in John's patch, and only remaining issue is if we need a second definition too. Thanks all.
To my knowledge, the schemaLocation must always specify pairs of URIs namespace/schemaLocation. See http://www.w3.org/TR/xmlschema-1/#schema-loc. I think we would only need the second mapping for editing/validating instances that start like this: <persistence xmlns="http://java.sun.com/xml/ns/persistence" <!-- no xsi:schemaLocation --> version="1.0">
(In reply to comment #5) > From what I know, the URI resolver will always honour the actual schema > location if specified in an XML instance. Isn't that controllable using our preference pages, and if so, what happens if it's off?
(In reply to comment #8) > (In reply to comment #5) > > From what I know, the URI resolver will always honour the actual schema > > location if specified in an XML instance. > Isn't that controllable using our preference pages, and if so, what happens if > it's off? Nitin, I think you're referring to the setting available on the XML Schema files page? From what I know, that setting controls the Xerces grammar preparser: when enabled it ensures that Xerces honours schemaLocation attributes in XML schema directives. See http://xerces.apache.org/xerces2-j/features.html#honour-all-schemaLocations and http://www.opensubscriber.com/message/j-users@xerces.apache.org/2750236.html for more information.
Somehow this bug slipped under my radar due to its low priority(not sure why was it assigned to me in the first place?) and now we seem to have a major dup as bug 235201. We should consider this for RC4. David, I believe you used to take care of the standard schemas plug-in? Care to assess and decide if this should go in for RC4?
Yes, this should have gone in long ago.
*** Bug 235201 has been marked as a duplicate of this bug. ***
Note for future ... normally, when new schemas are added, we should increment minor version number ... but, since so late, I'll leave as is with only an increment in the service field.
Closing.
