[
https://issues.apache.org/jira/browse/CXF-9124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17939746#comment-17939746
]
Freeman Yue Fang commented on CXF-9124:
---------------------------------------
Hi [~tflivu],
Thanks for reporting this!
You are right, should be some debug message sneaked in and we should get it
removed. Fixed accordingly.
Freeman
> TransportURIResolver prints stack trace to stderr when using HTTP
> Authentication
> --------------------------------------------------------------------------------
>
> Key: CXF-9124
> URL: https://issues.apache.org/jira/browse/CXF-9124
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Reporter: Tobias Flaig
> Assignee: Freeman Yue Fang
> Priority: Major
> Fix For: 4.1.2, 4.0.8, 3.6.7
>
>
> The following issue happens when a WSDL document URL requires HTTP Basic
> authentication to load.
> I create a default authenticator with the appropriate credentials:
>
> {code:java}
> Authenticator.setDefault(new Authenticator() {
> @Override
> protected PasswordAuthentication getPasswordAuthentication() {
> return new PasswordAuthentication(userName, password);
> }
> });{code}
> Now, I create a jakarta.xml.ws.Service:
>
> {code:java}
> service = Service.create(endpointUrl, serviceName); {code}
> Where endpointUrl is the URL of the WSDL which requires authentication to
> load.
>
> This works perfectly, but unfortunately, the following stacktrace is written
> to stderr (not even using a logger, but directly), which is misleading to the
> user:
>
> {noformat}
> org.apache.cxf.transport.http.HTTPException: HTTP response '401: (GET
> http://[...]?wsdl) 401' when communicating with http://[...]?wsdl
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1677)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1684)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1626)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1420)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.close(HttpClientHTTPConduit.java:662)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:717)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.close(HttpClientHTTPConduit.java:249)
> at
> org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:134)
> at
> org.apache.cxf.wsdl11.CatalogWSDLLocator.getBaseInputSource(CatalogWSDLLocator.java:71)
> at
> org.apache.cxf.wsdl11.AbstractWrapperWSDLLocator.getBaseInputSource(AbstractWrapperWSDLLocator.java:70)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:225)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:165)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:169)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:160)
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:128)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:82)
> at jakarta.xml.ws.Service.<init>(Service.java:82)
> at jakarta.xml.ws.Service.create(Service.java:735)
> [...]{noformat}
> The reason for this seems to be that it first attempts to load the URL
> without authentication, and when this fails, once again with authentication,
> which is fine, except for the stack trace, which is written by
> org.apache.cxf.transport.TransportURIResolver.resolve (
> [https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/transport/TransportURIResolver.java#L158]
> ).
> My expectation would be:
> * No stack trace is ever written to stderr directly, it is written to the
> debug log instead, even if there is a real problem with URL resolution.
> * (If the retry is done by CXF, nothing has to be logged at all since there
> is no error)
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)