spring-boot-admin
spring-boot-admin copied to clipboard
Improve Error Handling of LegacyConverters when json parsing fails
Using Spring Boot Admin 2.1.6 with a Spring Boot 2 applications (Spring Cloud Greenwich; Spring Boot 2.1.x). On one of my application the Http Traces gives me only the following error: Fetching traces failed. Cannot read property 'map' of undefined
Developer console shows:
Fetching traces failed: TypeError: Cannot read property 'map' of undefined
at o.
Unfortunately, JavaScript style web apps are incomprehensible to me, so I am not able to debug much more myself.
Not sure if it is related, but on the same application I also get the following errors, althought this is for sure a Spring Boot 2 application.
- Metrics are not supported for Spring Boot 1.x applications.
- Mappings are not supported for Spring Boot 1.x applications.
Could you please provide a sample to reproduce the issues?
I will try to trim the application down to a full sample. But is there something else I could do to debug, eg. output from the actuators to look for?
That would also help
Do you have a custom Jackson config?
No custom Jackson config, but yes, server side logs indicate problems with parsing JSON, unfortunately not very specific:
2019-11-06 17:23:46.880 ERROR 23991 --- [http-nio-8780-exec-4] org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.core.codec.DecodingException: JSON decoding error: Cannot deserialize instance of `java.util.ArrayList` out of START_OBJECT token; nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.util.ArrayList` out of START_OBJECT token
at [Source: UNKNOWN; line: -1, column: -1]] with root cause
com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.util.ArrayList` out of START_OBJECT token
at [Source: UNKNOWN; line: -1, column: -1]
Could you give me a hint about where in Spring Boot Admin source this parsing happens, and maybe a test I could run with my own sample output? That would be very helpful for me to debug myself.
the sba server only parses the responses, if it is a response from a spring boot 1.x appication. In this case the LegacyEndpointConverters::convertHttptrace is responsible.
Aha, so it is related to that the SBA server misinterperets this as a Spring Boot 1.x application, even though it is a 2.x. app, thus trying to parse 2.x http trace as a 1.x http trace. So the question then is what makes it think it is 1.x, which class in SBA is responsible for that?
Aha, so it is related to that the SBA server misinterperets this as a Spring Boot 1.x application, even though it is a 2.x. app, thus trying to parse 2.x http trace as a 1.x http trace.
Maybe - at best you startup your debugger and verify this.
So the question then is what makes it think it is 1.x, which class in SBA is responsible for that?
SBA looks at the content-type header from the response to figure out wether a conversion is necessary or not.
SBA looks at the content-type header from the response to figure out wether a conversion is necessary or not.
Thank you so much, that explains it. The app responds with Content-Type: application/json;charset=UTF-8
. This is probably due to custom content negotiation in our app that obviously interferes with the actuators content type, even though the payload is spring boot 2.x.trace.
If anything for SBA, an improvement can be to check for actual vnd.spring-boot.actuator.v1+json before attempting legacy parsing and an error message otherwise saying "Unsupported Content-Type", instead of a nonsensical "Cannot read property 'map' of undefined". Up to you if you want to keep this issue for that or just close it.
If anything for SBA, an improvement can be to check for actual vnd.spring-boot.actuator.v1+json ...
The problem with that that the vendor content-type for the actuator wasn't there since ever, so changing this might break things for (really really) old applications.
I'll keep the issue for improving the error handling for the legacy converters.