Ehcache 2 maven dependency-CodePudding

In my pom i have ehcache 2 dependency

        <dependency>
            <groupId>net.sf.ehcache</groupId>
            <artifactId>ehcache</artifactId>
            <version>${ehcache.version}</version>
        </dependency>

The problem is that during application build we have a grype check for vulnerabilities and it detects couple of libraries inside this dependency:

NAME              INSTALLED         FIXED-IN  VULNERABILITY        SEVERITY 
jackson-databind  2.11.1            2.12.6.1  GHSA-57j2-w4cx-62h2  High      
jersey-common     2.31              2.34      GHSA-c43q-5hpj-4crv  Medium    
jetty-server      9.4.39.v20210325  9.4.41    GHSA-m6cp-vxjx-65j6  Low

It is a bit confusing because libraries added to ehcache jar in really strange way - not like dependencies but files with extension *.class_terracotta in folder "rest-management-private-classpath" which is shown on screenshot

Because of this approach libraries versions can not be overridden or excluded in pom file.

Probably proper approach would be to migrate from ehcache 2 to 3, but it might take some time and i'm wondering if there are any fast solution to exclude this libraries from ehcache jar or override their version?

P.S. When i check ehcache doc it says that dependency should be added with type pom

    <dependency>
      <groupId>net.sf.ehcache</groupId>
      <artifactId>ehcache</artifactId>
      <version>2.10.4</version>
      <type>pom</type>
    </dependency>

but if i change it to this type in my pom - cache manager in not initialized and i'm getting this error

Error starting Tomcat context. Exception: org.springframework.beans.factory.UnsatisfiedDependencyException. Message: Error creating bean with name 'sessionRepositoryFilterRegistration' defined in class path resource [org/springframework/boot/autoconfigure/session/SessionRepositoryFilterConfiguration.class]: Unsatisfied dependency expressed through method 'sessionRepositoryFilterRegistration' parameter 1; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.boot.autoconfigure.session.JdbcSessionConfiguration$SpringBootJdbcHttpSessionConfiguration': Unsatisfied dependency expressed through method 'setTransactionManager' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: 'entityManagerFactory' depends on missing bean 'cacheManager'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'cacheManager' available

CodePudding user response：

Sometimes library artifacts are released in multiple ways.

One way packages all needed dependencies so it can be used as-is without addition of extra dependencies. The challenge with that is just what you observed here - those embedded dependencies cannot be excluded or changed. org.hamcrest:hamcrest-all is an example.

Some libraries also have a "lighter" version - one containing just the classes etc. for that specific artifact. Then, we can explicitly add other dependencies to get the desired functionality - and we are fully in control of what versions etc. are used. org.hamcrest:hamcrest-core and org.hamcrest:hamcrest-library are partial replacements for hamcrest-all (more dependencies are likely needed to get the complete functionality provided by the -all version).

Personally I much prefer the second way because issues like the one encountered are tricky to find and debug.

So, the fix here is to see if there is a "light" version of Ehcache version 2 and switch to it (along with any other dependencies you need for core functionality) instead.

If there isn't one, and you absolutely cannot switch to version 3, then you could pursue using the maven-shade-plugin to rebuild the ehcache jar, filtering out the extra dependencies. I would highly suggest against this, as who wants to rebuild the ehcache jars with every version update? And it's possible if not likely that the (now mangled) library won't work properly anyway. Plus it would have to be manually uploaded to the team's artifact repository, ideally with a classifier or a different group ID to make it clear that this is not the official release. And if all of this is making your head spin, that's a great justification for doing the upgrade. :)