You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Richard Opalka <ro...@redhat.com> on 2010/08/04 13:33:21 UTC
CXF-2926
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 <as...@redhat.com>
To: Richard Opalka <ro...@redhat.com>
CC: Sergey Beryozkin <sb...@gmail.com>, jbossws-dev
<jb...@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
>> <ma...@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
>> <ma...@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 <ma...@lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>> >
>> >
>>
>>
>> --
>> Richard Opalka
>> ropalka@redhat.com <ma...@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 <ma...@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
Re: CXF-2926
Posted by Daniel Kulp <dk...@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 <as...@redhat.com>
> > To: Richard Opalka <ro...@redhat.com>
> > CC: Sergey Beryozkin <sb...@gmail.com>, jbossws-dev
> > <jb...@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
> > >>
> > >> <ma...@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
> > >>
> > >> <ma...@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
> > >> >>> <ma...@lists.jboss.org>
> > >> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
> > >>
> > >> --
> > >> Richard Opalka
> > >> ropalka@redhat.com <ma...@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 <ma...@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
Re: CXF-2926
Posted by Richard Opalka <ro...@redhat.com>.
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<as...@redhat.com>
>> To: Richard Opalka<ro...@redhat.com>
>> CC: Sergey Beryozkin<sb...@gmail.com>, jbossws-dev
>> <jb...@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
>>>>
>>>> <ma...@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
>>>>
>>>> <ma...@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<ma...@lists.jboss.org>
>>>> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>>
>>>> --
>>>> Richard Opalka
>>>> ropalka@redhat.com<ma...@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<ma...@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
Re: CXF-2926
Posted by Daniel Kulp <dk...@apache.org>.
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 <as...@redhat.com>
> To: Richard Opalka <ro...@redhat.com>
> CC: Sergey Beryozkin <sb...@gmail.com>, jbossws-dev
> <jb...@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
> >>
> >> <ma...@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
> >>
> >> <ma...@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 <ma...@lists.jboss.org>
> >> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >>
> >> --
> >> Richard Opalka
> >> ropalka@redhat.com <ma...@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 <ma...@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