I just brought this up because the behavior is different than what JAX-WS `wsimport` (Oracle Java 7) does when provided with a catalog. Namely, it looks up the namespace in the catalog even if no `schemaLocation` is provided. Whether a `schemaLocation` or not is provided only makes difference (in the `wsimport` implementation) on what kind of entities it's consulting. More specifically, if only namespace is provided `wsimport` searches in the 'public' entries of the catalog, whereas if `schemaLocation` is provided it search in the `system` entries. But that's just what I've observed in experimentation - I haven't looked at `wsimport` sources. Still it makes sense, from a principle of least surprise, that if a catalog is provided, and that catalog has an explicit entry for the namespace, then that entry is consulted. Whether catalogs are in any way covered in the schema specs or fall into the "up to the application" areas I cannot say.
Lastly I agree with the part about including a `schemaLocation` attribute in the schema but in my case it is an industry standard which I would rather I didn't edit in any way. On Mon, Sep 30, 2013 at 8:51 PM, Daniel Kulp <[email protected]> wrote: > > My thoughts on this: > > 1) According to the schema spec, if the schemaLocation hint isn't > specified, it's up to the application to figure out how to resolve it if > needed. Thus, I don't really consider this a "bug". We specifically > just use the information provided and is part of the "compilation unit" > (aka: wsdl). > > 2) Personally, I think it's pretty silly to NOT provide the schemaLocation > and would STRONGLY STRONGLY recommend adding it. The only time I've ever > seen it not specified is when importing schemas that are also embedded in > the same wsdl (so there isn't a location). When ever I see things like > "up to the application" in specs, that, to me, is an interoperability > nightmare. Just specify it. > > 3) That all said, the root issue would be in XmlSchema's SchemaBuilder > class. If there isn't a schemaLocation, it assumes it's part of the > compilation unit it's working on and continues. Doesn't try to resolve > anything. If you want to pursue a patch or something, it would be around > 680 of SchemaBuilder.java. But even changing that MAY require more support > from CXF's side to pre-populate the namespaces it already knows to avoid > it going off to the internet for them. Not really sure. > > Dan > > > On Sep 26, 2013, at 9:56 AM, Menelaos Perdikeas <[email protected]> > wrote: > > > I am using Apache CXF 2.7.6 `wsdl2java` and it seems that the tool > ignores > > or fails to find public catalog entries. In particular I have the > following > > `<xs:import>` in one of my XSD files: > > > > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10"/> > > > > The above cannot be properly resolved with the catalog file entry: > > > > <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; > > uri="STCcoords-v1.10.xsd"/> > > > > If I change the `<xs:import>` by adding a `schemaLocation` attribute, > i.e. > > change it to: > > > > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; > > schemaLocation="http://www.ivoa.net/xml/STC/STCcoords/v1.10/> > > > > It resolves files, but my understanding is that this shouldn't have been > > necessary as I don't want to have to edit the XSD I am provided with. > > > > The behavior is the same whether OASIS XML format or TR9401 format is > used. > > Kind Regards, > > Menelaus. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
