Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: CXF-2926
Date: Thu, 5 Aug 2010 11:51:23 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.34; KDE/4.4.5; x86_64; ; )
Cc: Richard Opalka <ropalka@redhat.com>
References: <4C595001.3060205@redhat.com>
 <201008051148.18736.dkulp@apache.org>
In-Reply-To: <201008051148.18736.dkulp@apache.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201008051151.24219.dkulp@apache.org>


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 <asoldano@redhat.com>
> > To: 	Richard Opalka <ropalka@redhat.com>
> > CC: 	Sergey Beryozkin <sberyozkin@gmail.com>, jbossws-dev
> > <jbossws-dev@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 <ropalka@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"<asoldano@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@lists.jboss.org
> > >>     >>> <mailto:jbossws-dev@lists.jboss.org>
> > >>     >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
> > >>     
> > >>     --
> > >>     Richard Opalka
> > >>     ropalka@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@lists.jboss.org <mailto:jbossws-dev@lists.jboss.org>
> > >>     https://lists.jboss.org/mailman/listinfo/jbossws-dev
> > > 
> > > Office: +420 222 365 200
> > > Mobile: +420 731 186 942

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog