cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Opalka <ropa...@redhat.com>
Subject CXF-2926
Date Wed, 04 Aug 2010 11:33:21 GMT
  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
>>
>>
>
>
> -- 
> Richard Opalka
> ropalka@redhat.com
> JBoss, by Red Hat
>
> Office: +420 222 365 200
> Mobile: +420 731 186 942


-- 
Alessio Soldano
Web Service Lead, JBoss


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message