<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
OK Richard, thanks.<br>
Then you should probably send him an email and CC the cxf dev list.<br>
Thanks<br>
Alessio<br>
<br>
On 08/04/2010 10:32 AM, Richard Opalka wrote:
<blockquote cite="mid:4C59258F.2010203@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Daniel Kulp is the right person to ask, at least from the logs:<br>
<br>
[/home/opalka][/home/opalka/THIRDPARTY/CXF/trunk]>git log -20
--pretty=format:"%h - %an, %ar : %s"
rt/core/src/main/java/org/apache/cxf/catalog/OASISCatalogManager.java<br>
e5f270e - J. Daniel Kulp, 11 months ago : Work on reducing startup
time by lazy-initting things and marking classes that
Jsr250BeanPostProcessor don't need to deal with<br>
d0d45f3 - J. Daniel Kulp, 1 year, 4 months ago : Update catalog
support to detect if xml-resolver is available and if not, disable
itself. If not using catalogs, xml-resolvers is now optional.<br>
9b6b7bf - Freeman Yue Fang, 1 year, 5 months ago :
[CXF-2063]should set catalogManager debug level a bit ealier<br>
8f09d2b - James Maode Mao, 2 years, 11 months ago : * CXF-1053
Fix the build on Windows Vista,<br>
6524473 - J. Daniel Kulp, 2 years, 11 months ago : [CXF-1053]
Support URI and public types of catalog substitution as well as
System<br>
ec4aa77 - J. Daniel Kulp, 2 years, 11 months ago : [CXF-942] Fix
some JAX-WS SOAPFaultException mapping issues * Make all Logger
creations go through LogUtils.getL7dLogger so I can stop trying t<br>
4f981fe - James Maode Mao, 3 years, 1 month ago : * WSDLDefinition
builder support catalog * WSDL2Java jaxws frontend support catalog
* Map the ws-addr.xsd from network to the classpath<br>
7848106 - J. Daniel Kulp, 3 years, 2 months ago : Update OASIS
catalog stuff to be a real bus extension so we don't create new
Catalogs for every wsdl/schema we processes.<br>
463803a - J. Daniel Kulp, 3 years, 5 months ago : Commit first
part of CXF-440 (patch from Jarek Gawor)<br>
<br>
RIchard<br>
<br>
On 08/04/2010 10:07 AM, Sergey Beryozkin wrote:
<blockquote
cite="mid:AANLkTimKnemyzZi2+PjFC8uF9MrER-khLXrPJ+2hdpOT@mail.gmail.com"
type="cite">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.<br>
<br>
Well, not sure what is the "correct" approach here. Hearing from
someone on the CXF list who wrote that code could help. <br>
<br>
Sergey<br>
<br>
<div class="gmail_quote">On Wed, Aug 4, 2010 at 6:35 AM, Richard
Opalka <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ropalka@redhat.com" target="_blank">ropalka@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;"> I just found section #4.4 at JAX-WS 2.2 spec but it
doesn't cover<br>
tools behaviour at all :(<br>
<br>
However CXF OASISCatalogManager is inconsistent in it's
behaviour.<br>
While some of it's methods are just logging WARNings, e.g.:<br>
---<br>
public final void loadContextCatalogs(String name) {<br>
try {<br>
<br>
loadCatalogs(Thread.currentThread().getContextClassLoader(),
name);<br>
} catch (IOException e) {<br>
LOG.log(Level.WARNING, "Error loading " + name +
" catalog<br>
files", e);<br>
}<br>
}<br>
---<br>
other methods are throwing exceptions:<br>
---<br>
public final void loadCatalog(URL catalogURL) throws
IOException {<br>
...<br>
try {<br>
File file = new File(catalogURL.toURI());<br>
if (!file.exists()) {<br>
throw new
FileNotFoundException(file.getAbsolutePath());<br>
}<br>
...<br>
}<br>
---<br>
<br>
Why the behaviour is different for loadContextCatalogs() vs.
loadCatalog()?<br>
JBossWS Native & Sun RI are consistent in it's behaviour
(just logging<br>
warning).<br>
<br>
Rio<br>
<br>
On 08/03/2010 04:03 PM, Alessio Soldano wrote:<br>
> Hi,<br>
> yes, that's exactly the reason why I was asking...
while I agree the<br>
> behaviour there might appear a bit too restrictive, the
root problem<br>
> is still that the "user" is pointing to an file that
does not exist.<br>
> Btw, I don't think this is something covered by spec,
am I wrong?<br>
> So, given I think the issue this comes from is TCK
(right Richard?)...<br>
> we might want to see (privately) what can be done
(challenge?) if that<br>
> is actually asking for a missing catalog.<br>
> Thanks<br>
> Alessio<br>
><br>
> On 08/03/2010 03:58 PM, Sergey Beryozkin wrote:<br>
>> If so then there might be some pushback against
this fix...<br>
>> I'm not sure how say CXF behaves if for example a
wsdl location is<br>
>> specified in @WebService but the wsdl is not
actually there ?<br>
>> The missing catalog file might in principle lead to
a wrong resolution ?<br>
>><br>
>> cheers, Sergey<br>
>><br>
>> ----- "Alessio Soldano"<<a
moz-do-not-send="true" href="mailto:asoldano@redhat.com"
target="_blank">asoldano@redhat.com</a>> wrote:<br>
>><br>
>>> Basically your patch would prevent the cxf
tooling from failing badly<br>
>>><br>
>>> when the catalog file prop is provided but the
catalog is actually<br>
>>> missing (an error message is instead produced,
ignoring the error) ?<br>
>>><br>
>>> Alessio<br>
>>><br>
>>> On 08/03/2010 03:30 PM, Richard Opalka wrote:<br>
>>>> Hi Folks,<br>
>>>><br>
>>>> could somebody commit CXF-2926
upstream and close this issue?<br>
>>>> I don't have write commit rights to CXF
repo.<br>
>>>><br>
>>>> Thanks in advance,<br>
>>>><br>
>>>> Richard<br>
>>>><br>
>>><br>
>>> --<br>
>>> Alessio Soldano<br>
>>> Web Service Lead, JBoss<br>
>>><br>
>>> _______________________________________________<br>
>>> jbossws-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:jbossws-dev@lists.jboss.org" target="_blank">jbossws-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/jbossws-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/jbossws-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Richard Opalka<br>
<a moz-do-not-send="true" href="mailto:ropalka@redhat.com"
target="_blank">ropalka@redhat.com</a><br>
JBoss, by Red Hat<br>
<br>
Office: +420 222 365 200<br>
Mobile: +420 731 186 942<br>
<br>
_______________________________________________<br>
jbossws-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:jbossws-dev@lists.jboss.org" target="_blank">jbossws-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/jbossws-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/jbossws-dev</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Richard Opalka
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ropalka@redhat.com">ropalka@redhat.com</a>
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Alessio Soldano
Web Service Lead, JBoss</pre>
</body>
</html>