You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Menelaos Perdikeas <mp...@gmail.com> on 2013/09/26 15:56:11 UTC
Apache CXF :: wsdl2java ignoring catalog configuration for public entries
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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Aki Yoshida <el...@gmail.com>.
what we need is a statement that confirms that a valid wsdl processor
must use the schema's namespace url to lookup the schema resource in
this case.
I can also confirm that wsimport handles the imports without the
schemaLoc attribute. But I haven't found a clear statement about this
behavior and am still looking for more info. I chatted with Alessio
about this and asked him to look into it, as well.
2013/9/27 Menelaos Perdikeas <mp...@gmail.com>:
> 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 <el...@gmail.com> 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 <mp...@gmail.com>:
>> > 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 <el...@gmail.com> 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 <mp...@gmail.com>:
>> >> > 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 <el...@gmail.com>
>> wrote:
>> >> >
>> >> >> that's not a public id.
>> >> >> can you use the system entry instead?
>> >> >>
>> >> >>
>> >> >> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
>> >> >> > 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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Menelaos Perdikeas <mp...@gmail.com>.
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 <el...@gmail.com> 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 <mp...@gmail.com>:
> > 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 <el...@gmail.com> 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 <mp...@gmail.com>:
> >> > 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 <el...@gmail.com>
> wrote:
> >> >
> >> >> that's not a public id.
> >> >> can you use the system entry instead?
> >> >>
> >> >>
> >> >> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
> >> >> > 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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Aki Yoshida <el...@gmail.com>.
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 <mp...@gmail.com>:
> 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 <el...@gmail.com> 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 <mp...@gmail.com>:
>> > 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 <el...@gmail.com> wrote:
>> >
>> >> that's not a public id.
>> >> can you use the system entry instead?
>> >>
>> >>
>> >> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
>> >> > 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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Menelaos Perdikeas <mp...@gmail.com>.
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 <el...@gmail.com> 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 <mp...@gmail.com>:
> > 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 <el...@gmail.com> wrote:
> >
> >> that's not a public id.
> >> can you use the system entry instead?
> >>
> >>
> >> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
> >> > 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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Aki Yoshida <el...@gmail.com>.
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 <mp...@gmail.com>:
> 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 <el...@gmail.com> wrote:
>
>> that's not a public id.
>> can you use the system entry instead?
>>
>>
>> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
>> > 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.
>>
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Menelaos Perdikeas <mp...@gmail.com>.
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 <el...@gmail.com> wrote:
> that's not a public id.
> can you use the system entry instead?
>
>
> 2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
> > 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.
>
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Aki Yoshida <el...@gmail.com>.
that's not a public id.
can you use the system entry instead?
2013/9/26 Menelaos Perdikeas <mp...@gmail.com>:
> 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.
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Menelaos Perdikeas <mp...@gmail.com>.
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 <dk...@apache.org> 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 <mp...@gmail.com>
> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: Apache CXF :: wsdl2java ignoring catalog configuration for public entries
Posted by Daniel Kulp <dk...@apache.org>.
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 <mp...@gmail.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com