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})
Related
is there a way in Spring Boot to display only my custom
Request Mappings with actuator? By default it shows everything.
As described in the reference documentation, the default behaviour of actuator endpoints, when the actuator module is on the classpath, is 'opt-out' - that is, most endpoints are enabled by default and must be disabled if required.
For the opposite effect (i.e. actuator endpoints must be specifically enabled), add the following setting to your application.properties:
management.endpoints.enabled-by-default=false
or alternatively, if using YAML:
management:
endpoints:
enabled-by-default: false
There is no way to filter which mappings get added. By default, anything with #RequestMapping is included.
You could always disable the provided mapping endpoint and write your own custom endpoint that includes only the controllers you care about.
A really strange situation is observed in our application (Spring Boot 1.5.6 with all-default BOM dependencies): you can perfectly log in (with AbstractPreAuthenticatedProcessingFilter), but this still leaves Principal in request null! I.e. request.getUserPrincipal() is null while SecurityContextHolder.getContext().getAuthentication() is not!
This in turn affects the ability of our health endpoint to be sensitive: it uses Principal (see HealthMvcEndpoint.exposeHealthDetails(HttpServletRequest, Principal)) which is injected by ServletRequestMethodArgumentResolver, which in turn takes it from the request...
Looks like I'm missing something simple, but still can't find it :(
So, after creating a new Spring Boot application and debugging it to its guts, I've found out that nobody actually sets Principal into the request. It's Spring who wraps it into another one that uses Spring's SecurityContext for the above (and some other methods). And this wrapping is done by the SecurityContextHolderAwareRequestFilter, which is there by default (see HttpSecurity.servletApi())...
But somebody has disabled the default Spring Security configuration for our project, so the filter was not there!
Following the online docs for adding jersey to Sring boot, it appears I just need to include the following package
spring-boot-starter-jersey
Actually, it states that Spring Boot provides automatic configuration by including this package.
Where can I find out what exactly is happening?
If I don't add this package then what is NOT configured?
I tried searching for the package in google but got no specific explanation only saying that it automatically configures, but configures what?
I would like to know a little more of what is happening behind the scenes.
All of the auto-configuration code for all that Spring Boot supports is in the spring-boot-autoconfigure module. If you look through the packages, you will see a jersey package.
The "starter" modules generally do not have any code (of course unless it is a third-party module). How it works is that the code in the auto-configuration has some annotations that are #ConditionalOnXxx, where the condition be anything from a class being on the classpath. If this class is not available, then the auto-configuration will not take place. That's pretty much all adding the jersey starter module does: it adds the jersey dependencies so that the auto-configurer will applied.
Now what exactly is being auto-configured specifically for Jersey? Check out the source for the JerseyAutoConfiguration. Basically what you are going to see is your ResourceConfig being injected into the configurer. From that ResourceConfig, it creates Jersey's ServletContainer (which is the main entry point for Jersey.
Then, depending on our properties configuration, either a FilterRegistrationBean or a ServletRegistrationBean is created as a Spring bean, wrapping Jersey's ServletContainer. Jersey can be created as a Servlet or a Servlet Filter. Whichever one we configure we be used.
And that's it for the Jersey configuration. Spring Boot will get a servlet container (e.g. Tomcat, Jetty) from some other auto-configuration, and take the Filter/ServletRegistrationBean and add the Servlet/Filter to that servlet container.
Also, not really that important, but the auto-configuration also give us some Jackson configuration helpers. For example, instead of configuring our own ContextResolver, we can just configure an ObjectMapper Spring bean.
That's really all you get. It's nothing so spectacular that you couldn't just do it yourself without depending on the auto-configuration.
I would recommend learning a little more about how Spring Boot works to provide the automatic configuration in general.
A good reference is the spring boot reference guide. http://docs.spring.io/spring-boot/docs/1.5.3.RELEASE/reference/htmlsingle/#common-application-properties
You can look at the common application properties in appendix A to see what all spring allows you to configure out of the box.
The Reference guide also gives a high level of what "spring-boot-starter-jersey" if you search for it on the page.
They also have a few samples that you can go through and debug to follow along if that is a way for you to learn.
Hope that gives you a starting point for learning!
I'm studying the Spring Security framework with Spring Boot, and one thing I dislike about boot is it's obscurity. There's so much magic happening, troubleshooting and customization is trial and error, guessing what is configured automatically and where. This is high risk in the security field, as misconfigured system may be compromised.
I would like to replace springSecurityFilterChain with my own implementation. In vanilla Spring I would register DelegatingFilterProxy with a different name in web.xml, and implement corresponding bean. However, Spring boot apparently registers springSecurityFilterChain automatically if jars are present, and now I'm not sure if the auto configuration will back of just by declaring the springSecurityFilterChain in a traditional way, or will this lead to misconfigured system?
Generally, I would like to understand Spring boot better, and not just guessing what is happening, where and how to take control of that area.
There are a lot of preconfigured things, but you can override every single step. The magic of #EnableAutoConfiguration is just convenience. The --debug switch should tell you more what is happening in the background.
http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html
If you use Spring Boot 1.4.x (I'm not sure about previous releases), one of the following would work.
#EnableAutoConfiguration(exclude = {org.springframework.boot.autoconfigure.security.SecurityFilterAutoConfiguration.class})
OR
#SpringBootApplication(exclude = { org.springframework.boot.autoconfigure.security.SecurityFilterAutoConfiguration.class})
OR
In your application.properties file,
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.security.SecurityFilterAutoConfiguration
Sometimes you may need to exclude the org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration class as well.
Do you really want to disable the whole security chain? I don't see the use case, but if, then you do not need #EnableWebSecurity at all. If you only want to adjust the chain, create a Class annotated with #Configuration and #EnableWebSecurity which is extending WebSecurityConfigurerAdapter. There you can tell who is allowed to do what by overriding configure(HttpSecurity).
I'm redirecting from http to https using the TomcatEmbeddedServletContainerFactory instructions found here:
http://drissamri.be/blog/java/enable-https-in-spring-boot/
However this breaks the testing of the rest controller, even though it uses an Application to run the test that does not contain or reference the TomcatEmbeddedServletContainerFactory configuration performing the redirection.
If I remove the redirection configuration from the Application that contains the #SpringBootApplication annotation that runs the application, the test passes.
Any idea how to keep the production configuration for the application in place without breaking the Rest controller configuration?
TIA,
- Ole
If you don't want to use the TomcatEmbeddedServletContainerFactory in your Application.java in your test, you could always add work with Spring profiles to make sure that bean is only loaded when you start your application with a certain profile (production for example).
Then the #Bean TomcatEmbeddedServletContainerFactory would have a #Profile("production") annotation, and your test would not create that bean unless you are using the production profile explicitly.
I will update this answer when you give more information regarding your problem.