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

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

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

Daniel Kulp is the right person to ask, at least from the logs: [/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 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 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. 9b6b7bf - Freeman Yue Fang, 1 year, 5 months ago : [CXF-2063]should set catalogManager debug level a bit ealier 8f09d2b - James Maode Mao, 2 years, 11 months ago : * CXF-1053 Fix the build on Windows Vista, 6524473 - J. Daniel Kulp, 2 years, 11 months ago : [CXF-1053] Support URI and public types of catalog substitution as well as System 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 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 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. 463803a - J. Daniel Kulp, 3 years, 5 months ago : Commit first part of CXF-440 (patch from Jarek Gawor) RIchard On 08/04/2010 10:07 AM, Sergey Beryozkin wrote: > 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 > <mailto:ropalka@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&quot;&lt;asoldano(a)redhat.com > <mailto:asoldano@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 <mailto:jbossws-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev > > > > > > > -- > Richard Opalka > ropalka(a)redhat.com <mailto:ropalka@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 <mailto:jbossws-dev@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