[jbossws-dev] CXF-2926

[Sergey Beryozkin]

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 at 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 at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >
> >
>
>
> --
> Richard Opalka
> ropalka at redhat.com
> JBoss, by Red Hat
>
> Office: +420 222 365 200
> Mobile: +420 731 186 942
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20100804/b5e674c0/attachment.html