[
https://issues.apache.org/jira/browse/CXF-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Xu updated CXF-9078:
-------------------------
Description:
When using HTTP GET action by either calling JAX-WS Dispatch invoke() or JAX-RS
WebClient invoke()/async().method() with a dummy payload, the program always
ends up with a NullPointerException.
The typical stack flow could look like the following:
{code:java}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.OutputStream.write(byte[], int, int)" because "<parameter1>" is null
at java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source)
at
org.apache.cxf.io.CachedOutputStream.writeCacheTo(CachedOutputStream.java:317)
at
org.apache.cxf.transport.http.asyncclient.hc5.AsyncHTTPConduit$AsyncWrappedOutputStream.close(AsyncHTTPConduit.java:439)
at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
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.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349)
at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) {code}
By checking code around AsyncHTTPConduit.java:439, I would think
handleHeadersTrustCaching() could have left _wrappedStream_ as _null_ for GET
action, which eventually crashing the later _out.writeCacheTo(wrappedStream)._
My local case seems to be OK after I override the class and put a check before
_out.writeCacheTo(wrappedStream)._ But I'm no expert on the related modules.
Please let me know if there are any other solutions.
I know the issue won't be hit with JAX-RS client if GET is triggered with a
null payload. But somehow in our usage, we can't totally ban GET for JAX-WS
dispatch. So it's still a problem to us.
was:
When using HTTP GET action by either calling JAX-WS Dispatch invoke() or JAX-RS
WebClient invoke()/async().method() with a dummy payload, the program always
ends up with a NullPointerException.
The typical stack flow could look like the following:
{code:java}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.OutputStream.write(byte[], int, int)" because "<parameter1>" is null
at java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source)
at
org.apache.cxf.io.CachedOutputStream.writeCacheTo(CachedOutputStream.java:317)
at
org.apache.cxf.transport.http.asyncclient.hc5.AsyncHTTPConduit$AsyncWrappedOutputStream.close(AsyncHTTPConduit.java:439)
at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
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.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349)
at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) {code}
By checking code around AsyncHTTPConduit.java:439, I would think
handleHeadersTrustCaching() could have left _wrappedStream_ as _null_ for GET
action, which eventually crashing the later _out.writeCacheTo(wrappedStream)._
My local case seems to be OK after I override the class and put a check before
_out.writeCacheTo(wrappedStream)._ But I'm no expert on the related modules.
Please let me know if there are any other solutions.
I know the issue won't be hit with JAX-RS client if GET is triggered without
any payload. But somehow in our usage, we can't totally ban GET for JAX-WS
dispatch. So it's still a problem to us.
> AsyncHTTPConduit.java causing NullPointerException when closing
> ---------------------------------------------------------------
>
> Key: CXF-9078
> URL: https://issues.apache.org/jira/browse/CXF-9078
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 4.0.5
> Reporter: Luke Xu
> Priority: Major
>
> When using HTTP GET action by either calling JAX-WS Dispatch invoke() or
> JAX-RS WebClient invoke()/async().method() with a dummy payload, the program
> always ends up with a NullPointerException.
> The typical stack flow could look like the following:
>
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.OutputStream.write(byte[], int, int)" because "<parameter1>" is null
> at java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source)
> at
> org.apache.cxf.io.CachedOutputStream.writeCacheTo(CachedOutputStream.java:317)
> at
> org.apache.cxf.transport.http.asyncclient.hc5.AsyncHTTPConduit$AsyncWrappedOutputStream.close(AsyncHTTPConduit.java:439)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
> 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.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
> at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349)
> at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) {code}
>
>
> By checking code around AsyncHTTPConduit.java:439, I would think
> handleHeadersTrustCaching() could have left _wrappedStream_ as _null_ for GET
> action, which eventually crashing the later _out.writeCacheTo(wrappedStream)._
>
> My local case seems to be OK after I override the class and put a check
> before _out.writeCacheTo(wrappedStream)._ But I'm no expert on the related
> modules. Please let me know if there are any other solutions.
>
> I know the issue won't be hit with JAX-RS client if GET is triggered with a
> null payload. But somehow in our usage, we can't totally ban GET for JAX-WS
> dispatch. So it's still a problem to us.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
