I am trying to create a Spring Boot project.
When I modified some dependency and use Maven reload the project, these warnings happen.
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.7.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.hank</groupId>
<artifactId>springboot-mall</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>springboot-mall</name>
<description>springboot-mall</description>
<properties>
<java.version>11</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
<version>8.0.22</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
warnings
Warning:(20, 3) Provides transitive vulnerable dependency ch.qos.logback:logback-classic:1.2.3 CVE-2021-42550 6.6 Deserialization of Untrusted Data vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(20, 3) Provides transitive vulnerable dependency ch.qos.logback:logback-core:1.2.3 CVE-2021-42550 6.6 Deserialization of Untrusted Data vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(20, 3) Provides transitive vulnerable dependency org.springframework:spring-beans:5.2.12.RELEASE CVE-2022-22965 9.8 Improper Control of Generation of Code ('Code Injection') vulnerability pending CVSS allocation CVE-2022-22970 5.3 Allocation of Resources Without Limits or Throttling vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(20, 3) Provides transitive vulnerable dependency org.springframework:spring-context:5.2.12.RELEASE CVE-2022-22968 5.3 Improper Handling of Case Sensitivity vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(20, 3) Provides transitive vulnerable dependency org.springframework:spring-core:5.2.12.RELEASE CVE-2021-22060 4.3 Improper Output Neutralization for Logs vulnerability pending CVSS allocation CVE-2021-22096 4.3 Improper Output Neutralization for Logs vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency com.fasterxml.jackson.core:jackson-databind:2.11.3 Cxced0c06c-935c 5.9 Uncontrolled Resource Consumption vulnerability pending CVSS allocation CVE-2020-36518 7.5 Out-of-bounds Write vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.apache.tomcat.embed:tomcat-embed-core:9.0.41 CVE-2021-25329 7.0 Deserialization of Untrusted Data vulnerability pending CVSS allocation CVE-2021-25122 7.5 Exposure of Sensitive Information to an Unauthorized Actor vulnerability pending CVSS allocation CVE-2021-33037 5.3 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability pending CVSS allocation CVE-2021-41079 7.5 Improper Input Validation vulnerability pending CVSS allocation CVE-2021-30639 7.5 Improper Handling of Exceptional Conditions vulnerability pending CVSS allocation CVE-2021-30640 6.5 Improper Encoding or Escaping of Output vulnerability pending CVSS allocation CVE-2022-23181 7.0 Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.glassfish:jakarta.el:3.0.3 CVE-2021-28170 5.3 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.apache.tomcat.embed:tomcat-embed-websocket:9.0.41 CVE-2021-42340 7.5 Missing Release of Resource after Effective Lifetime vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.springframework:spring-web:5.2.12.RELEASE CVE-2016-1000027 9.8 Deserialization of Untrusted Data vulnerability pending CVSS allocation CVE-2021-22118 7.8 Improper Privilege Management vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.springframework:spring-webmvc:5.2.12.RELEASE CVE-2016-1000027 9.8 Deserialization of Untrusted Data vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(24, 3) Provides transitive vulnerable dependency org.springframework:spring-expression:5.2.12.RELEASE CVE-2022-22950 6.5 Allocation of Resources Without Limits or Throttling vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(29, 3) Dependency com.h2database:h2:1.4.200 is vulnerable CVE-2018-14335 6.5 Improper Link Resolution Before File Access ('Link Following') vulnerability pending CVSS allocation CVE-2021-42392 9.8 Deserialization of Untrusted Data vulnerability pending CVSS allocation CVE-2021-23463 9.1 Improper Restriction of XML External Entity Reference vulnerability pending CVSS allocation CVE-2022-23221 9.8 Improper Control of Generation of Code ('Code Injection') vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(34, 3) Dependency mysql:mysql-connector-java:8.0.22 is vulnerable CVE-2021-2471 5.9 Improper Restriction of XML External Entity Reference vulnerability with medium severity found CVE-2022-21363 6.6 Improper Input Validation vulnerability pending CVSS allocation Results powered by Checkmarx(c)
Warning:(40, 3) Provides transitive vulnerable dependency net.minidev:json-smart:2.3 CVE-2021-27568 9.1 Improper Check for Unusual or Exceptional Conditions vulnerability pending CVSS allocation CVE-2021-31684 7.5 Out-of-bounds Write vulnerability pending CVSS allocation Results powered by Checkmarx(c)
What exactly means these message? It seems something security problem, but I don't know how to figure it out.
I have tried to google the warnings, but there is no information to refer to.
These messages telling you that the dependencies you used have some known vurnerabilities either direct or transitive to other dependencies.
for example spring boot version 2.3.7.RELEASE you can check at the maven repository website list of known vurnerabilities of this dependency
So you either upgrade the dependency version or check the mitigation of the known vurnerabilities for further details.
try this one,
<dependency>
<groupId>org.foo.bar</groupId>
<artifactId>foo-bar</artifactId>
</dependency>
rather than
<dependency>
<groupId>org.foo.bar</groupId>
<artifactId>foo-bar</artifactId>
<version>1.3.56</version>
</dependency>
Related
Even simple Spring Boot app jar contains lots of dependencies and functionality which never will be used by your app.
All this stuff:
should be loaded and it takes its time
many of these classes should be instantiated, initialized and will consume the memory and resources.
It could be crucial for micro service architecture and cloud native apps where memory footprint could be a price (e.g. https://run.pivotal.io/pricing/) and/or startup time is important.
E.g. the spring-boot-autoconfigure-2.1.6.RELEASE.jar (1.2Mb) contains couchbase, freemaker, cassandra and many others which with 99% probability never be used for your particular project. Or spring-core-5.1.8.RELEASE.jar (1.2Mb) contains the classes like KotlinDetector. Seriously? In core lib?
I never will use this full of OOP anti-patterns ugly language. Why should I care on it in my app?
Why should I pay for all this useless stuff?
I'm tried to use ProGuard to get rid all unused classes and methods. But it seems no way for Spring Boot, Hibernate etc which are using Reflection API, AOP and even debug information!
ProGuard was not able even to finish with no errors complaining on lack of some classes.
Another idea to use jlink, GraalVM native image and native build. And I found bunch of articles on that. For my understanding it is impossible to use it for Spring Boot app at this time.
Spring Boot is nice tool to build the apps.
QUESTION: is there a way to get rid all unused stuff from your final Spring Boot jar/war?
Please read about Spring Boot Maven Plugin
It explains how you can exclude dependency during packaging,
By default, both the repackage and the run goals will include any provided dependencies that are defined in the project. A Spring Boot project should consider provided dependencies as container dependencies that are required to run the application
There are two ways one can exclude a dependency from being
packaged/used at runtime
Exclude a specific artifact identified by groupId and artifactId (optionally with a classifier if needed)
Exclude any artifact belonging to a given groupId
however I doubt if you can remove anything inside any artifact
<plugins>
...
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.1.8.RELEASE</version>
<configuration>
<excludes>
<exclude>
<groupId>com.foo</groupId>
<artifactId>bar</artifactId>
</exclude>
</excludes>
</configuration>
...
</plugin>
...
</plugins>
Also you can handle it at dependency level using exclusions
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</exclusion>
</exclusions>
</dependency
I made custom dependency which uses spring 4.x version and I include it in a project which uses spring 3.x version. When a method from this dependency is called it uses classes from spring 3.x version not from 4.x. Is it possible to force this dependency to use spring 4.x whereas the project itself will use spring 3.x ?
I don't think that is possible due to the fact that, when finally project is running, the dependencies are resolved on the basis of group id and artifact id and not on their version. Which is why your application is using 3.x dependency as it is overriding the one mentioned in the parent project. Hope this helps.
Yes, you can if you separate your application (which you probably don't want to). Another approach: You might think about using another class loader within the same JVM. This, however, leads to a probably bigger bunch of problems, especially using Spring.
Dzone article about loading the same class from libs with different versions.
As pvpkiran noted, you want to exclude the spring v3 transitive dependency from your custom artifact. From the maven documentation - Optional Dependencies and Dependency Exclusions:
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>
I've been developing a JSF2.0 (I'm not really sure about the JSF version) application on TomEE 1.7.3 (JavaEE6 based).
In my Maven pom.xml, I had too many dependencies which I've copied from many examples, but I reduced them to minimum requirements. Bellow is the "dependencies" part of my pom.xml:
<dependencies>
<!-- JavaEE6 -->
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
</dependency>
<!-- /JavaEE6 -->
<!-- OmniFaces for JSF, #Eager, postback same request parameters, etc. -->
<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>omnifaces</artifactId>
<version>1.8.3</version>
</dependency>
<!-- /OmniFaces -->
<!-- glassfish faces (is it called mojarra??) -->
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.12</version>
<scope>runtime</scope>
</dependency>
<!-- /glassfish faces -->
<!-- some mysql connector -->
<!-- some aws sdks, s3, ec2, etc -->
<!-- some apache commons, StringUtils. etc -->
<!-- some apache velocity -->
</dependencies>
The org.glassfish#javax.faces#2.2.12 dependency can be removed as well,
but it causes html layout problem (with the bootstrap css).
Downgrading it to version 2.0.x, causes the same layout problem.
I know I can fix it, but it takes couple of hours.
What I want to ask is:
Is it good or bad idea to use glassfish faces 2.2.x within TomEE1.7.x? TomEE's description says that it only supports up to JSF 2.0, but so far, it is working almost fine (I have few problems but those do not seem relevant to this version).
Is it better to remove glassfish faces dependency and use the default MyFaces instead?
Is it even better if I choose glassfish server, instead of TomEE, in my case?
BTW, I asked another question yesterday:
JSF2.0 Some facesmessages not sent to redirected page on error handling
and I recognized that I have to clean up my project first, so it might help reduce my problems.
Thank you.
As you already said yourself, TomEE is a Java EE 6 container (and not a barebones JSP/Servlet container like Tomcat). So it has already (nearly) everything from Java EE 6 provided out the box, including JSF 2.0/2.1. Nearly, because it's actually a Java EE web profile container. So you should actually use javaee-web-api artifact ID.
Only this should be sufficient:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
As an Apache product, its bundled JSF implementation is actually MyFaces, not Mojarra.
In case you intend to use JSF 2.2, which is part of Java EE 7, you should be using TomEE 7 instead and change the version in pom.
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
A milestone was released just this month, see the downloads page. Alternatives to TomEE 7 are WildFly 8+ or Payara 4+.
See also:
Our JSF wiki page - also contains JSF installation instructions and Maven coordinates (and many more useful information to get started).
I noticed that the Spring Boot Sample Data Redis declares the following dependencies:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-redis</artifactId>
</dependency>
See here for full POM: https://github.com/spring-projects/spring-boot/blob/v1.0.0.RC4/spring-boot-samples/spring-boot-sample-data-redis/pom.xml
I see no mention of the <artifactId>spring-boot-starter-redis</artifactId>
My question is: when do I use spring-boot-starter versus spring-boot-starter-xxx where xxx is the name of the project (here Redis)?
The answer to the specific question: spring-boot-starter is a baseline for the others, and for standalone (non-web) apps that don't use any other Spring components - it has basic support for Spring, Logging, and Testing, but nothing else (no webapp features, no database etc.). Since all the other starters depend on it, once you use another one you can remove the vanilla starter. EDIT: see here https://github.com/spring-projects/spring-boot/commit/77fd127e09963a844f8fb4e574e1f0d9d3424d4e.
Up to you on the redis starter, but I would use the starter if it exists, since it will typically cut down on the number of dependencies you need to declare. The redis one actually doesn't add a lot of value (hence it didn't exist until recently), but it probably ought to be used in the sample.
In my project, which is being developed in Spring 3.1, I am trying to perform both client side and server side validations by making use of Apache Commons Validator. But just by adding the below mentioned code is causing some xml exception.
added dependency in pom.xml: -
<dependency>
<groupId>org.springmodules</groupId>
<artifactId>spring-modules-validation</artifactId>
<version>0.8</version>
</dependency>
compile time exception in servlet-context.xml --> Resource Path Location Type Referenced file contains errors (jar:file:/C:/Users/shift/.m2/repository/org/springframework/spring-beans/3.1.0.RELEASE/spring-beans-3.1.0.RELEASE.jar!/org/springframework/beans/factory/xml/spring-beans-3.0.xsd).
I read somewhere that the jars of Spring 3.1 might be colliding with Spring 2.x (which is added in maven repository as [i]spring-modules-validation[/i] brings it with it). After that I added an exclusion as mentioned below: -
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
After which the exception disappeared but inbuilt classes like InternalResourceViewResolver, DataSourceTransactionManager, etc. are not found by the compiler.
Is there something else which I have missed, or any other way apart from Commons Validator to perform client and server side validations in Spring 3.1 ?