You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike Spring MVC and Spring WebFlux, Jersey doesn't log its request mappings. A side-effect of this is that when you use the Actuator on top of Jersey all of the endpoints disappear from the log. The argument in favour of the current arrangement is that it aligns with Jersey's behaviour and might be part of the reason why a user prefers Jersey. The argument against the current arrangement is that users who are used to a Spring MVC or WebFlux-based Actuator may get confused and think the endpoints aren't working.
The text was updated successfully, but these errors were encountered:
The argument against the current arrangement is that users who are used to a Spring MVC or WebFlux-based Actuator may get confused and think the endpoints aren't working.
Whatever we do, we'll need to draw a line somewhere as there are many other differences between Jersey and Spring MVC. I think the two systems are different and relying on log output for this is weird. Perhaps that's the problem and we should offer something that provides that information?
wilkinsona
changed the title
Consider logging Actuator endpoint mappings when using Jersey
Log summary of exposed web endpoints at startup
Mar 12, 2018
Unlike Spring MVC and Spring WebFlux, Jersey doesn't log its request mappings. A side-effect of this is that when you use the Actuator on top of Jersey all of the endpoints disappear from the log. The argument in favour of the current arrangement is that it aligns with Jersey's behaviour and might be part of the reason why a user prefers Jersey. The argument against the current arrangement is that users who are used to a Spring MVC or WebFlux-based Actuator may get confused and think the endpoints aren't working.
The text was updated successfully, but these errors were encountered: