I've implemented a basic togglz setup using Spring Boot starter. I'm getting the following at startup:
WARN o.t.s.l.TogglzApplicationContextBinderApplicationListener - ApplicationContext already bound to current context class loader, releasing it first
This may also be causing multiple startups, as I sometimes see the Spring banner go by twice.
To summarize my implementation:
Using property-based toggles in application.yml
Wiring FeatureManager into components
Have a configuration which returns a SpringSecurityUserProvider bean
Not using a TogglzConfig (though I tested with it, and see no difference)
I've looked at the Togglz class, and see the log warning, but I don't understand what situation in Spring Boot would cause this error.
Thank you!
Related
I'm working on an integration with an older library so that it can use Spring Boot testing, and for that I need to register a certain bean very early in the process, so that an ApplicationListener<ApplicationReadyEvent> can add a PropertySource to the Environment.
This works fine in the normal startup, but when using the #SpringBootTest annotation I need to be able to inspect the TestContext very early and add it to the testing BootstrapContext, so that the application listener can access it also in the integration tests.
But I can't find a good way to add bean instances to the test BootstrapContext apart from specifying an initializer class in the spring.factories files, or am I missing something here?
I have been looking into using #BootstrapWith and subclassing SpringBootContextBootstrapper, but can't seem to find a way to add some kind of BootstrapregistryInitializer-like functions?
Below exception handler that is common for all my controllers, is working fine except that I need to disable the WARN log from AbstractHandlerExceptionResolver class after processing the exception. Using Spring Web MVC 5.x version.
#ControllerAdvice
public class AllExceptionHandler{
#ExceptionHandler(SomeCustomException.class)
#ResponseStatus(HttpStatus.BAD_REQUEST)
public void exceptionHandler() {
}
}
This is the log that is generated which I'm trying to avoid:
02-20-2019 15:22:54,896 WARN [http-nio-8080-exec-1] (AbstractHandlerExceptionResolver.java:140) - Resolved [com.rasa.rrt.ste.controller.SomeCustomException]
I'm not using Spring Boot.
Tried to extend the above AllExceptionHandler class with ExceptionHandlerExceptionResolver and call warnLogCategory(null) in the AllExceptionHandler constructor, but it throws NullPointerException.
Also, I see on Google to set this property spring.mvc.log-resolved-exception=false to disable warning, but not sure where/how to set it.
You mentioned spring.mvc.log-resolved-exception=false as a possible solution:
Also, I see on google to set this property "spring.mvc.log-resolved-exception=false" to disable warning, but not sure where/how to set it.
The spring.mvc.log-resolved-exception property is a Spring Boot property, and would be set using standard Spring Boot externalized configuration mechanisms. Enabling the property causes Spring Boot to configure HandlerExceptionResolver beans to log exceptions when they otherwise wouldn't.
Whether to enable warn logging of exceptions resolved by a "HandlerExceptionResolver", except for "DefaultHandlerExceptionResolver".
Since you've stated you're not using Spring Boot, this property is not applicable to your scenario.
You can disable this warning log in your logback configuration,
by specifying in my case in 'logback-spring.groovy' following line
logger("org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver", ERROR)
I am reading the source code of Spring Boot and I found that Spring Boot refreshes the context right after preparing the context in the run method.
SpringApplication.run method:
...
prepareContext(context, environment, listeners, applicationArguments,printedBanner);
refreshContext(context);
...
Can anyone explain why refreshing context is needed? Thanks.
Because refreshContext causes context initialization/reinitialization, such as invoking BeanFactoryPostProcessor beans, registering listeners, initilizing message source etc. You can see it in sources of the AbstractApplicationContext#refresh method.
Here you can find an article about Spring internals and refresh process.
I have been prototyping with Spring boot where I added dependency on spring-boot-starter-actuator and spring-boot-starter-data-rest and named my testing REST endpoint to /info. Application ran without any errors however my endpoint couldn't be called and app returned 404 all the time.
After some time I found out that actuator project contains SAME endpoint /info and basically overrides my custom RESTful endpoint since I didn't name it.
My question is: Is there any way how I can prevent such behavior in general (meaning bean clashing by mistake)? Or at least get WARN message when this is happening.
Thanks in advance for your answers
You can disable /info actuator endpoint by using the following property;
management.endpoint.info.enabled=false
Actually all can be disabled, or you can enable only certain ones, if you check the source link I've provided below;
By default, all endpoints except for shutdown are enabled. If you prefer to specifically “opt-in” endpoint enablement you can use the endpoints.enabled property.
source
For logging of this behaviour, while deploying you can see the endpoints and corresponding beans, you can deduce from this log I guess. But better not to use same endpoint with actuator while they are enabled.
Yes, there is a chance to disable particular classes by #EnableAutoconfiguration with a parameter exclude= where you can specify classname or whole package by using {} brackets
Example:
#EnableAutoConfiguration(exclude = {MyClassName.class}
#EnableAutoConfiguration(exclude = {MyClassName.class, MyClassName2.class})
I've been trying to figure out what I'm missing with my RestTemplate setup (particularly OAuth2RestTemplate) so I want to see the logs for debugging. I found one possible solution for it, but nothing about the operation of the RestTemplate gets shown.
What I've done so far is to replace the default Logback logging mechanism in my Spring Boot app by following the configuration shown here. When I run my Spring Boot application after changing the logging dependencies, all I see on the console is the Spring logo (in ASCII) and nothing else. I've already defined a log4j-spring.properties in src/main/resources with the property defined in the previous link.
What else am I missing here? Do I need to run my Spring Boot app in debug mode? If so, how do I do that? Also, how do I set this up using the default Logback mechanism?