Remove Spring actuator from my project - spring

I have a Spring boot project using spring security and Oauth2 and I'm noticing some bad behaviour which could be caused by actuator.
To be sure I want to remove it from the project but I can't find it explicitly mentionned in my Maven dependencies.
Any idea on how to do it?

It is not quite clear to me whether you want to exclude the actuator dependencies from your classpath or whether you want to disable the behaviour from your container. If it is the latter, you should be able to do so through your application.properties, i.e.:
management.endpoints.enabled-by-default=false
I am pretty sure you can disable also by using annotations on your spring boot application class as an alternative.

Find where it is with dependencies hiearchy and exclude it.
This official documentation may help you to do so.

Use mvn dependency:tree to print all the transitive dependencies as a tree structure. It's a standard maven-dependency-plugin mojo.
Once you find the dependency that introduces it use <dependencyManagement> section with correct <exclude> to remove the actuator from the project.

Related

How to find Spring Boot auto-configuration classes that are activated by adding a specific starter project to pom?

How Spring Boot auto-configuration classes are activated based on the maven starter projects that are included in project pom.xml as dependencies?
for example, by adding spring-boot-starter-security to pom.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
class SecurityAutoConfiguration is activated. how does this happen? How SecurityAutoConfiguration is related to spring-boot-starter-security?
the starter project themselves are completely empty, there is no java code in these starter projects, and just a couple of dependencies is defined in pom.xml. I want to know exactly what happens when I add a starter project to my Spring Boot project and exactly what configurations are applied.
Autoconfiguration is one, or maybe the main one, feature of SpringBoot
Basically, depending on certain conditions, some configurations or/and beans are made available.
In your case here is what happens :
spring-boot-starter-security, as other starters, is just here to make some others dependencies available for your project, particulary spring-security-config which itself, has a dependency on spring-security-core
If your looking at the code source of SecurityAutoConfiguration you can see that is configuration class depends on the availabality of the class DefaultAuthenticationEventPublisher, which is true as now you have a (transitive) dependency on spring-security-core.
This SecurityAutoConfiguration class is listed as a Autoconfiguration class inside the config file org.springframework.boot.autoconfigure.AutoConfiguration.imports (spring.factories for some previous Spring Boot version) of the spring-boot-autoconfigure project, which make it active for your application.
Here you can find the documentation :
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.developing-auto-configuration.understanding-auto-configured-beans
You can find it here - https://www.baeldung.com/spring-boot-security-autoconfiguration
Basically, either property for the starter can be disabled or exclude specific auto configuration from #springboot(exclude = SecurityAutoConfiguration.class
)

Spring Boot requires spring-boot-starter-security as a dependency for ssl

I inherited Spring Boot application (version 1.5.8). I think it reads external foo.properties file then creates Map object having key/value pair then SpringApplication.setDefaultProperties consumes it.
When I inspected the properties file, it has many ssl related key/value properties
server.ssl.key-alias=<some_value>
server.ssl.key-password=<some_value>
server.ssl.key-store=<some_value>
server.ssl.key-store-type=<some_value>
From its pom.xml file I don't see spring-boot-starter-security as a dependency though. My assumption is it is ok. Although as newbie, when I went through simple tutorial of Spring Boot in regard to ssl, it has aforementioned lib as a dependency.
I plan to add more ssl key/value pairs like:
server.ssl.enabled=<some_value>
server.ssl.ciphers=<some_value>
server.ssl.protocol=<some_value>
My question is do I need spring-boot-starter-security lib as a dependency or not. I am sure I'd find out once I update/execute the application but I decided to ask first if anyone knows in advance. My initial research didn't come up with an answer I was looking for.
Update:
From its pom.xml, I see following added as dependency. Another attempt of research makes me believe spring-boot-starter comes with spring-boot-starter-security but I am not positive about this.
spring-boot-starter
spring-boot-starter-log4j2
spring-boot-starter-web
No, you definitely don't need spring-boot-starter-security to enable SSL/TLS in your Spring Boot application.
As described in the Spring Boot documentation, you can enable SSL declaratively by setting the various server.ssl.* properties, typically in application.properties or application.yml.
Refer to the Ssl class for details of all of the supported properties. You may also consider checking the Spring Boot common application properties (in special the server properties).
No.
Spring Boot does not need security for SSL, it's a Tomcat issue. I recommend you to read this tutorial

Spring boot war file with unnecessary jars

I am making war packaging of my spring boot. made spring boot starter tomcat as provided, removed spring boot maven plugin.
But I still see tomcat jdbc and tomcat juli, to name a few (even junit, but it could be from other custom dependencies, so discounting this for this question). I am using logback, but I see log4j over slf4j from starter web.
Can I ask, how to skip unwanted jars and keep my package nice and tidy
Maven has the concept of "scope" for dependencies. You probably know the scope test which is used for unit test dependencies which should not go into the final product. Use this scope for junit.
What you need is the scope provided for the Tomcat dependencies. This tells Maven: "Don't include it; when the code is run, someone else will make sure this dependency is on the classpath".
The dependency log4j-over-slf4j is necessary when one of your dependencies still uses log4j to log. log4j-over-slf4j contains the code to redirect those calls to logback.
Now you will face the case where you can't change the scope because it's in a POM of someone else.
The correct solution here is to define the dependency with the correct scope (and version) in a dependencyManagement element in your POM. This definition will be used when any POM asks for this group+artifactId. So even when some deep dependency of Spring Boot pulls that in, your WAR will be build with the version and scope from the dependencyManagement element.
See also:
Dependency Scopes
Dependency Management

Maven: How to include a dependency with a specific build profile?

I have a project where I use Spring Boot 1.1.2.RELEASE which uses Spring 4.1.5, and Spring HATEOAS 0.10.0.RELEASE which uses Spring 4.0.9. This causes some dependency problems like the infamous java.lang.ClassNotFoundException: org.springframework.beans.factory.SmartInitializingSingleton.
I dug into the POM of spring-hateoas and found that there are different profiles defined, one of them being spring41 which depends on Spring 4.1.5. Is it possible to select this profile in my <dependency> section, or do I have to exclude the Spring dependencies?
Automatically selecting a profile for a build isn't easy. You can enable it by default in your personal settings.xml but that breaks the build for everyone who doesn't have the same file.
You can't enable a profile in the POM of the project.
With Maven 3.3, you can add the profile to ${maven.projectBasedir}/.mvn/maven.config. Since this file is part of the project, it's easy to share. You can use the Maven Enforcer plugin to make sure everyone uses a Maven version with actually uses the file.
If you can't use 3.3, then your best bet is to exclude the dependencies. If you have a parent POM, then you can use a dependencyManagement element to do it for all POMs in the reactor build.

Why Spring 3 needs explicit cglib dependency declaration when using Maven?

I'm using Spring 3 and Maven. I've defined all spring modules in my pom.xml.
When I use <aop:scoped-proxy />, I get an error saying that CGLIB is missing.
Well... I add CGLIB as a dependency in my pom and it all runs...
I'm a little confused... Maven is a dependency manager... Why it does not download CGLIB when I use the spring-aop module?
It's not the only case... Why do some projects need explicit dependency declaration instead of using Maven transitive dependency mechanism?
It's because cglib is marked as an optional dependency.
Essentially you don't need cglib for every usage of the spring-aop library, so maven doesn't download it automatically. You need to specify it manually, unfortunately.
I'm a little confused... Maven is a dependency manager... Why it does not download the cglib when I use the spring-aop module ?
Because not everybody uses CGLIB (an AOP proxy in Spring can be a JDK dynamic proxy or a CGLIB proxy) so CGLIB is marked as an optional dependency in the pom of spring-aop and you have to add it explicitly if you want to use it. This is exactly what optional dependencies are for.
Another similar example is Hibernate that lets you choose between cglib and javassist in hibernate-core in the same way. Hibernate also lets you choose between various connection pools (if you decide to use one of them) or cache providers (only ehcache, the default, is not declared as optional).
My guess would be that cglib is not enabled in Spring by default. And therefore it's not included in the pom unless you explicitly enable it.
As far as I know, Maven cannot go into your Spring configuration files and determine if it needs additional optionally enabled libraries. Although, that certainly sounds like it would be a cool Spring-Maven plugin if it were possible to modify the pom on the fly via plugin. Not sure if it is, but it would be cool.
Good news - this is a problem of the past:
As of Spring 3.2, it is no longer necessary to add CGLIB to your
project classpath, as CGLIB classes are repackaged under
org.springframework and included directly in the spring-core JAR. This
means that CGLIB-based proxy support just works in the same way that
JDK dynamic proxies always have.
Read more here.

Resources