cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Opalka <ropa...@redhat.com>
Subject Re: CXF-2926
Date Fri, 06 Aug 2010 07:25:56 GMT
  Let me disagree Daniel.
The main purpose of catalog feature is to
"avoiding costly remote accesses".
The missing catalog file shouldn't be the reason for throwing
FileNotFoundException because it's a hint ;)
Warning is more appropriate in this case (just my opinion).

Richard

PS: Anyway I'm going to challenge it to ORCL as well.

On 08/05/2010 05:48 PM, 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


-- 
Richard Opalka
ropalka@redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942


Mime
View raw message