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
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. :)
Related
I am facing below error while deploying spring boot microservice on cloud foundry:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [com/ge/pd/reports/config/HibernateConfig.class]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: javax.persistence.JoinColumn.foreignKey()Ljavax/persistence/ForeignKey;
As I checked many resolution on stack overflow and many other portals for the solution, All the solution are related to jar version conflicts.
I have eliminated all the conflicts jar from the application and updated with all the jar versions which is required.
I am using below jar and its version:
hibernate-core-5.0.12.Final.jar - 5.0.12
hibernate-jpa-2.1-api-1.0.0.Final.jar - 2.1
hibernate-entitymanager-5.0.12.Final.jar - 5.0.12
openjpa-2.4.0.jar - 2.4.0
Please Provide the Solution.
This indeed looks like a dependency conflict, more specifically, between Hibernate 5.0.12 (which uses JPA 2.1) and OpenJPA 2.4.0 (which uses JPA 2.0). Try removing the OpenJPA dependency.
As this SO thread shows, the said method was introduced in JPA 2.1.
I'm using Spring 3.2.0 in a legacy project with Mybatis 3.3.0 and Mybatis Spring 1.2.3.
I have several projects that use this technology and they need to have similar new code added to a library that will allow me to interact with an outside system, and during this interaction I need to call several methods in the database in this new code.
I created an interface and put it in a package, say:
com.mycompany.myapp.dao.MyNewService
That interface has a few methods. All of those are defined in a Mybatis mapper file, MyNewService.xml in that same package path.
I create a .jar file of all this code.
In my main application, I added a dependency to this .jar file and it ends up inside of WEB-INF\lib\MyHelpers.jar
In that application, I have a root application context spring file and I attempt to use a mybatis MapperScannerConfigurer to find this new bean/service via:
<!--scan for mappers and let them be autowired -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.mycompany.myapp.dao" />
<property name="sqlSessionFactoryBeanName"
value="sqlSessionFactory" />
</bean>
When I run this code, it appears that it cannot find this service in that package path which I know is in WEB-INF\lib\MyHelpers.jar.
The application produces a warning on startup:
WARN (ClassPathMapperScanner.java:167) - No MyBatis mapper was
found in '[com.mycompany.myapp.dao]' package.
Please check your configuration.
The code later fails during dependency injection with a massive stacktrace which essentially says:
2017-03-08 15:38:39,625 [[ACTIVE] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)'] ERROR
(org.springframework.web.servlet.DispatcherServlet:466) - Context
initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'orderDetailsController': Injection of
autowired dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not
autowire field: private com.mycompany.myapp.dao.MyNewService
com.mycompany.otherapp.controller.OrderDetailsController.myNewService
; nested exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No
matching bean of type [com.mycompany.myapp.dao.MyNewService ] found
for dependency: expected at least 1 bean which qualifies as autowire
candidate for this dependency. Dependency annotations:
{#org.springframework.beans.factory.annotation.Autowired(required=true)}
If I dig into that Mybatis code, its simply not finding the resource from the package path inside that .jar when it's using some ResourceResolver code. IF I move my code into my project directly rather than adding the .jar dependency, the code works fine without error.
The concern of course is that I have to put this same code across six projects, so I thought I'd have it in this .jar file and use the MapperScannerConfigurer. We use that in all the projects but all the .xml is within the applications WEB-INF\classes when deployed, it is not inside a .jar file within WEB-INF\lib.
Any ideas how to accomplish this? In summary, it would be akin to:
Making a file called Model.jar based on Mybatis interfaces and .xml mapper files
Adding this as a dependency that appears in WEB-INF\lib
configuring the main spring applicationContext file using the syntax I have above.
If you need more clarification, I can certainly add it.
We've been using mule-module-redis-3.3.3-SNAPSHOT in production with mule 3.4.2 (standalone EE) for about two years now; works great, thanks!
With mule-module-redis-3.4.0, our project's maven compile is ok (yes, we've refactored our code to use the different parameter signatures in some of the RedisModule methods).
But we have been stymied so far with following error below when running any integration test within the maven build. (Our integration test classes simply extend mule's FunctionalTestCase class.)
The one difference we've noticed for the redis-connector 3.4.0 is the RedisModule.set() method has an #Inject annotation; wondering if there could be some dependency conflict or missing dependency/configuration we might be missing?
"... Error creating bean with name 'globalredis': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire method: public byte[] org.mule.module.redis.RedisModule.set(java.lang.String,java.lang.Integer,boolean,java.lang.String,org.mule.api.MuleEvent); nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [java.lang.String] is defined: expected single matching bean but found 3: applicationVersion,mysqlPort,testConversionSendToBillingEnabled (org.mule.api.lifecycle.InitialisationException)"
[I've had good suggestions, without success so far :( on the Mule Community Forum with this issue, so hoping there might be others more involved with the mule redis-connector who are here. Thanks!]
jawr-core has the following dependency (see artifact details):
<dependency>
<groupId>org.mozilla</groupId>
<artifactId>rhino</artifactId>
<scope>provided</scope>
</dependency>
When processing LESS files I'm facing an exception saying java.lang.NoClassDefFoundError: org/mozilla/javascript/ScriptableObject
If adding rhino dependency explicitly with scope compile to my project the exception is gone.
But why Jawr has a dependency on it with scope provided when it is required to process LESS files?
The servlet container my webapp is running on is Tomcat 7.
jawr have made all their dependencies provided, not just the rhino dependency.
It looks to me like they are really worried about getting in the way of your server's classpath.
At this link: http://jawr.java.net/docs/postprocessors.html#YUI_compressor, they state the following:
...which might be problematic if you already have rhino on your server's classpath...
Can only presume that is why they are all provided. You then explicitly need to include the dependencies that you require for the functionality of jawr that you want to use.
My problem is that I'm building spring-boot project and I'm using class A from some other project which use log4j 1.2.8. When I force spring to use log4j 1.2.8 I have following error:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'jettyEmbeddedServletContainerFactory' defined
in class path resource
[org/springframework/boot/autoconfigure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedJetty.class]:
Initialization of bean failed; nested excepti
on is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration':
Injection of autowired dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not
autowire field: private
org.springframework.boot.autoconfigure.web.ServerProperties
org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration.properties;
nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'serverProperties' defined in class path
resource
[org/springframework/boot/autoconfigure/web/ServerPropertiesAutoConfiguration.class]:
Initialization of bean failed; nested exception is
java.lang.NoSuchFieldError: TRACE
Spring need at least log4j 1.2.12, so when I use this version of log4j my A class have follwing error:
java.lang.NoSuchMethodError:
org.apache.log4j.LogManager.exists(Ljava/lang/String;)Lorg/apache/log4j/Logger;
There is any solution other than upgrade of my A class log4j? Maybe there is any way to force at runtime some classes should use log4j 1.2.8 and other would use 1.2.12 ?
OSGI is such kind of technology which you can have multiple versions of same library in one JVM runtime.
However, it's overkilled for most of cases. Same suggestion as others, upgrading your source code would be much cheaper way.
Solution for this problem is easy. I mentioned in comment that spring use log4j-over-slf4j which doesn't implement LogManager.exists method which my Class is using. I've just excluded from my project(gradle) log4j-over-slf4j and added dependency to log4j as below.
configurations {
compile.exclude module: 'log4j-over-slf4j'
}
compile group: 'log4j', name: 'log4j', version: '1.2.17'
The easiest solution is to upgrade your project A. Updating the logging library is a minor risk, fiddling with different library versions can be tedious and confusing.
Disclaimer: I'm not familiar with spring-boot, maybe it has a clever way of dealing with this issue.
I would highly recommend to upgrade the class that is making the problems with an older log4j version. Every thing you could do, at my knowledge, would be way more complicated then upgrading. You could split up into 2 diffrent projects in their own classloader or something like that.. basicly that is what something like tomcat does to achieve multiple java web applications.. but then you have to look how both communicate etc etc... so I suppose that the most solutions will make it more complicated than it needs to be, or should be