Closed codefromthecrypt closed 9 months ago
looking at logs we have relatively clean and well one that is something we should address so the nag in console helpful cc @openzipkin/armeria
[INFO] Running zipkin2.server.internal.ITZipkinServerSsl
00:13:15,478 WARN [main] support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker (PostProcessorRegistrationDelegate.java:429) - Bean 'com.linecorp.armeria.spring.ArmeriaBeanPostProcessorConfiguration' of type [com.linecorp.armeria.spring.ArmeriaBeanPostProcessorConfiguration$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [armeriaBeanPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.
00:13:15,856 INFO [armeria-boss-https+http-*:46321] server.Server$ServerPortStartListener (Server.java:808) - Serving HTTPS at /[0:0:0:0:0:0:0:0%0]:46321 - https://127.0.0.1:46321/
00:13:15,857 INFO [armeria-boss-https+http-*:46321] server.Server$ServerPortStartListener (Server.java:808) - Serving HTTP at /[0:0:0:0:0:0:0:0%0]:46321 - http://127.0.0.1:46321/
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.747 s -- in zipkin2.server.internal.ITZipkinServerSsl
Before, running tests required careful configuration or your screen will fill up with this:
per https://github.com/spring-projects/spring-boot/issues/39583, by adding an empty src/test/resources/banner.txt, we are sure this won't happen.
This is better than asking people to redirect output to a log file, as normal use in IDE is easier when you can see the logs by default. It is also helpful in CI to be able to see logs without the complexity of searching for file artifacts after failure.
There was mention of a possible "application context caching" problem when you don't show the spring banner in tests, but we hid it before more laboriously without issues. I think whatever problem that is doesn't apply here.