Would you like me to file a bug report? I would be happy to do so but
provide me coordinates as I want to make sure I file it against the right
project.


On Fri, Sep 27, 2013 at 2:58 PM, Aki Yoshida <[email protected]> wrote:

> the problem is that there is not much we can do in cxf, as the
> relevant code is not in cxf but in wsdl4j (more specifically, in its
> WSDLReaderImpl), which explicitly ignores those import statements
> without the schemaLocation attribute.
>
> if this is the wrong behavior, we need to have it fixed there in wsdl4j.
>
> regards, aki
>
> 2013/9/27 Menelaos Perdikeas <[email protected]>:
> > The thing is that I am not convinced that one should have to use the
> > `schemaLocation` attribute to override the location of a schema to be
> > fetched using a catalog. At least in the JAX-WS `wsimport` tool that
> ships
> > with standard Oracle Java 7, one is able to provide alternative locations
> > for schemas that are simply referenced with an <import> element, without
> > `schemaLocation` attributes. So I am giving the same catalog to both
> > `wsimport` and `wsdl2java` tools, and only `wsdl2java` is unable to use
> the
> > correct entry in the catalog, that's why I suspect this to be a bug. I
> > dunno perhaps I should file a bug report.
> >
> >
> > On Fri, Sep 27, 2013 at 12:59 AM, Aki Yoshida <[email protected]> wrote:
> >
> >> hi,
> >> sorry for my short reply earlier.
> >>
> >> the publicId identifier is an old time identifier and has a different
> >> usage and syntax from the URLs.
> >> http://en.wikipedia.org/wiki/Formal_Public_Identifier
> >>
> >> For redirecting URLs to somewhere else, you can use system or
> >> rewriteSystem entries.
> >> So, I thought my quick reply would solve your issue, assuming the
> >> lookup to fall back to use the namespace URL of the import when its
> >> schemaLocation attribute is not set.
> >>
> >> But it looks like this assumption was wrong. In other words, the
> >> schemaLocation must be set when the schema needs to be retrieved.
> >>
> >> In that case, I was wondering where you get the schema that omits the
> >> schemaLocation attribute and if it can be processed by other schema
> >> based tools.
> >>
> >> regards, aki
> >>
> >> 2013/9/26 Menelaos Perdikeas <[email protected]>:
> >> > Changing the catalog entry from
> >> >
> >> >     <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10";
> >> >  uri="STCcoords-v1.10.xsd"/>
> >> >
> >> > to:
> >> >
> >> >     <system systemId="http://www.ivoa.net/xml/STC/STCcoords/v1.10";
> >> >  uri="STCcoords-v1.10.xsd"/>
> >> >
> >> > still requires adding the `schemeLocation` attribute in the `<import>`
> >> > element otherwise the types of the imported schema are not found.
> >> > That is, I still need to modify the XSD schema (which only has an
> >> > `<import>` element without a `schemaLocation` attribute).
> >> > Can you elaborate a bit more on public versus system entries? I am not
> >> sure
> >> > I get all the nuances.
> >> >
> >> >
> >> > On Thu, Sep 26, 2013 at 5:42 PM, Aki Yoshida <[email protected]>
> wrote:
> >> >
> >> >> that's not a public id.
> >> >> can you use the system entry instead?
> >> >>
> >> >>
> >> >> 2013/9/26 Menelaos Perdikeas <[email protected]>:
> >> >> > 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.
> >> >>
> >>
> >
> >
> >
> > --
> > at Thy word I will let down the net.
>



-- 
at Thy word I will let down the net.

Reply via email to