I'm not sure why that inconsistency is there. From the code I can see that
loadContextCatalogs is trying to load the default
"META-INF/jax-ws-catalog.xml" which may be collocated with the application
jar (just my theory). But loading a "user" catalog which is supposed to be
located elsewhere is the responsibility of loadCatalogs.
Well, not sure what is the "correct" approach here. Hearing from someone on
the CXF list who wrote that code could help.
Sergey
On Wed, Aug 4, 2010 at 6:35 AM, Richard Opalka <ropalka(a)redhat.com> wrote:
I just found section #4.4 at JAX-WS 2.2 spec but it doesn't
cover
tools behaviour at all :(
However CXF OASISCatalogManager is inconsistent in it's behaviour.
While some of it's methods are just logging WARNings, e.g.:
---
public final void loadContextCatalogs(String name) {
try {
loadCatalogs(Thread.currentThread().getContextClassLoader(), name);
} catch (IOException e) {
LOG.log(Level.WARNING, "Error loading " + name + " catalog
files", e);
}
}
---
other methods are throwing exceptions:
---
public final void loadCatalog(URL catalogURL) throws IOException {
...
try {
File file = new File(catalogURL.toURI());
if (!file.exists()) {
throw new FileNotFoundException(file.getAbsolutePath());
}
...
}
---
Why the behaviour is different for loadContextCatalogs() vs. loadCatalog()?
JBossWS Native & Sun RI are consistent in it's behaviour (just logging
warning).
Rio
On 08/03/2010 04:03 PM, Alessio Soldano wrote:
> Hi,
> yes, that's exactly the reason why I was asking... while I agree the
> behaviour there might appear a bit too restrictive, the root problem
> is still that the "user" is pointing to an file that does not exist.
> Btw, I don't think this is something covered by spec, am I wrong?
> So, given I think the issue this comes from is TCK (right Richard?)...
> we might want to see (privately) what can be done (challenge?) if that
> is actually asking for a missing catalog.
> Thanks
> Alessio
>
> On 08/03/2010 03:58 PM, Sergey Beryozkin wrote:
>> If so then there might be some pushback against this fix...
>> I'm not sure how say CXF behaves if for example a wsdl location is
>> specified in @WebService but the wsdl is not actually there ?
>> The missing catalog file might in principle lead to a wrong resolution ?
>>
>> cheers, Sergey
>>
>> ----- "Alessio Soldano"<asoldano(a)redhat.com> wrote:
>>
>>> Basically your patch would prevent the cxf tooling from failing badly
>>>
>>> when the catalog file prop is provided but the catalog is actually
>>> missing (an error message is instead produced, ignoring the error) ?
>>>
>>> Alessio
>>>
>>> On 08/03/2010 03:30 PM, Richard Opalka wrote:
>>>> Hi Folks,
>>>>
>>>> could somebody commit CXF-2926 upstream and close this issue?
>>>> I don't have write commit rights to CXF repo.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Richard
>>>>
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>>
>>> _______________________________________________
>>> jbossws-dev mailing list
>>> jbossws-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbossws-dev
>
>
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
_______________________________________________
jbossws-dev mailing list
jbossws-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossws-dev