[ 
https://issues.apache.org/jira/browse/CXF-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398529#comment-17398529
 ] 

Marcel Schramm commented on CXF-8581:
-------------------------------------

Hey,

 

so, it appears the logging part was an oversight on our side, we had an 
Exception mapper that was faulty.

 

However, the problem with 200 OK still persists. It seems that this is due to 
the fact that the code inside the endpoint runs successfully, tells the client 
`200 OK` and then starts streaming the data (chunking?).

During the streaming we get the serialization error. I am assuming it's like 
this by design though, as you can't change the status code once it has been set 
and you also can't start streaming before the status code has been set, as the 
client won't be able to read it anyways?

 

If you agree, feel free to just close this issue :)

 

Thank you for the fast reply.

> Exceptions caught during JSON serialisation aren't handled correctly
> --------------------------------------------------------------------
>
>                 Key: CXF-8581
>                 URL: https://issues.apache.org/jira/browse/CXF-8581
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.4.4
>         Environment: OpenJDK 11
> Windows 10 x64
> Apache CXF 3.4.4
>            Reporter: Marcel Schramm
>            Priority: Major
>
> When trying to serialize an object that contains unserializable data, cxf 
> runs into an exception.
> An error log message is printed by `JAXRSUtils.logMessageHandlerProblem`. 
> However, the message contains no stack trace. On top of that the invoking 
> client receives a `200 OK` HTTP status code and partially written JSON, 
> followed by an error message.
>  
> What I'd have expected instead, is to use the registered `ExceptionMapper`, 
> which would turn this into an `500 Internal Server Error`. On top of that, it 
> should print the stacktrace, as it's pretty hard to know what's going on 
> otherwise.
>  
> In our specific case, we had an object that contains a `java.awt.Font` object.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to