Oh, on a related note: Apparently some of the CXF unit tests hit the internet. (Specifically example.com.) I was trying to build things on the plane to Germany this week and ran into a problem when the onboard wifi returned the redirect page for the wifi login when the test ran. I THOUGHT I had fixed all those a while ago, apparently not.
Dan On Thursday 05 August 2010 11:48:18 am Daniel Kulp wrote: > The loadContextCatalogs is more of the "runtime" version that grabs the > catalogs from the META-INF things at runtime. The loadCatalogs is more > of a tooling thing. > > For the most part, for tooling things, I GREATLY prefer a tool failing to a > warning being printed. For example: > > Let's say you have a catalog that redirects an internet location to a nice > file in the source tree. Everything works great. Build don't hit the > internet. Everyone is happy. > > A developer accidentally deletes the catalog. Without a failure, the > build keep working as long as they can hit the internet just fine. Thus, > no one really notices (how many of you actually look at all the maven > warnings?) and a month goes buy. Suddenly, you get a build failure due > to a network glitch or something and you then need to spend a lot of time > trying to figure out what happened as you all THOUGHT it wasn't hitting > the internet. > > Yes, hypothetical example. However, it does happen. > > My strong preference would be to challenge the test and see how Oracle > responds. If they don't accept the challenge and modify the TCK, then > change to WARNING so you can proceed. If they do change it, leave as is. > > > Dan > > On Wednesday 04 August 2010 7:33:21 am Richard Opalka wrote: > > Forwarding to Daniel for his opinions on this topic. > > > > Rio > > > > -------- Original Message -------- > > Subject: Re: [jbossws-dev] CXF-2926 > > Date: Wed, 04 Aug 2010 11:37:38 +0200 > > From: Alessio Soldano <asold...@redhat.com> > > To: Richard Opalka <ropa...@redhat.com> > > CC: Sergey Beryozkin <sberyoz...@gmail.com>, jbossws-dev > > <jbossws-...@lists.jboss.org> > > > > > > > > OK Richard, thanks. > > Then you should probably send him an email and CC the cxf dev list. > > Thanks > > Alessio > > > > On 08/04/2010 10:32 AM, Richard Opalka wrote: > > > 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 <ropa...@redhat.com > > >> > > >> <mailto:ropa...@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"<asold...@redhat.com > > >> > > >> <mailto:asold...@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-...@lists.jboss.org > > >> >>> <mailto:jbossws-...@lists.jboss.org> > > >> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev > > >> > > >> -- > > >> Richard Opalka > > >> ropa...@redhat.com <mailto:ropa...@redhat.com> > > >> JBoss, by Red Hat > > >> > > >> Office: +420 222 365 200 > > >> Mobile: +420 731 186 942 > > >> > > >> _______________________________________________ > > >> jbossws-dev mailing list > > >> jbossws-...@lists.jboss.org <mailto:jbossws-...@lists.jboss.org> > > >> https://lists.jboss.org/mailman/listinfo/jbossws-dev > > > > > > Office: +420 222 365 200 > > > Mobile: +420 731 186 942 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
