Using Maven to build my project under windows works fine, but when I build it under Linux I get a NoSuchMethodError regarding one of the spring libs.
I am guessing it is something to do with class loader differences cross-platform and somewhere in my dependencies and I may have the same class twice but windows is loading one while linux loads the other?
Has anyone come across this problem before, or have any advice on how I can debug this error further?
nested exception is java.lang.NoSuchMethodError:
org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(Lorg/springframework/beans/factory/xml/ParserContext;Lorg/w3c/dom/Element;)V:
java.lang.NoSuchMethodError:
org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(Lorg/springframework/beans/factory/xml/ParserContext;Lorg/w3c/dom/Element;)V
at org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser$AopAutoProxyConf
Stack Trace Pastie
POM.xml Pastie
Your spring dependencies have too many different versions:
org.springframework:spring-beans:jar:2.5.6:compile
org.springframework:spring-aop:jar:2.0.8:compile
org.springframework:spring-jms:jar:3.0.5.RELEASE:compile
Make all spring dependencies have the same version (preferably 3.0.5.RELEASE)
Related
I have a Java EE web service that I just converted to use log4j2 over v1. My JUnit tests are failing with the following stacktrace:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.logging.log4j.util.PropertiesUtil
at org.apache.logging.log4j.status.StatusLogger.<clinit>(StatusLogger.java:78)
at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:61)
The exact line it's failing on is LOGGER = LogManager.getLogger(MyEndpoint.class);. I've searched high and low and cannot find any solution to this nor this being a common problem. My dependencies are:
junit 4.12
mockito-core 2.15.0
log4j-core and log4j-api 2.19.0
Due to other dependencies I still have log4j1 on the classpath, however excluding it from the build doesn't change the outcome.
I cannot post the whole source code as this is a company project.
I found I had to add org.osgi:osgi.core:8.0.0 to my list of dependencies. If anyone knows why, I would love to hear it.
I've been trying to create an integration test using the embeddedKafka, but I'm getting problem of missing dependency when trying to run it, this is the error:
Unable to load class org.springframework.kafka.test.EmbeddedKafkaBroker due to missing dependency org/I0Itec/zkclient/serialize/ZkSerializer
I saw some stuff saying that this is related to my dependencies, so here is my dependencies:
springBootVersion = '2.3.5.RELEASE'
compile("org.springframework.boot:spring-boot-starter-web:${springBootVersion}")
compile("org.springframework.kafka:spring-kafka:${springBootVersion}")
testCompile("org.springframework.boot:spring-boot-starter-test:${springBootVersion}",
'org.spockframework:spock-core:1.2-groovy-2.4',
'org.spockframework:spock-spring:1.2-groovy-2.4',
'com.microsoft.azure:spring-data-cosmosdb:2.3.0',
'com.nimbusds:oauth2-oidc-sdk:5.64.4',
)
testCompile("org.springframework.kafka:spring-kafka-test:${springBootVersion}")
So, my question is, am I missing something?
EDIT
After changed the versions as indicated, I got a different error:
Error creating bean with name 'embeddedKafka': Invocation of init
method failed; nested exception is java.lang.NoClassDefFoundError:
scala/math/Ordering$$anon$7
I've added the scala dependencies, but still having the same issue:
testImplementation("org.scala-lang:scala-library:2.12.11")
testImplementation("org.scala-lang:scala-reflect:2.12.11")
You somehow have a mismatched kafka Vs. kafka-clients jars on the classpath; they all must be the same version.
You generally should not specify a version on boot's dependencies and use its dependency management instead.
You are pulling in spring-kafka 2.3.5 whereas spring-boot 2.3.5 requires spring-kafka 2.5.7.
Spring-kafka 2.5.x uses the kafka-clients 2.5.1.
See here for how to override versions of kafka jars when using a different version to the version that Boot prescribes.
the Kafka Client libraries for a time were inlining a particular version of the Scala library. This caused problems for those of us wanting to use the kafka client library with a slightly different version of Scala than that inline version.
In this cases the version of Scala they were using inline is Scala 2.12.10
They removed this dependency in later versions and this was backported as fixes (the earliest being 2.8.0) https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html)
I'm using Jenkins 1.6.20 (Git Client Plugin 1.18.0, Git Plugin 2.4.0) to get the Java application code from bitbucket.org and deploy it to Apache Tomcat 8.0.23.
The error appears while deploying and looks like:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'requestMappingHandlerMapping' defined in class path resource [org/spr$
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
bla-bla-bla ... so many errors ...
Caused by: java.lang.IllegalStateException: Ambiguous mapping found. Cannot map 'positionWS' bean method
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
The problem is that the class (with annotation #Controller) PositionWS with method getEmployeePost was renamed to ResourceWS a week ago, so exists no more, so I should not get this error.
To fix this I have to create a blank PositionWS controller (with no methods in it), commit & push that to bitbucket (and delete (cus i really don't need it) later and commit & push).
It seems to be like a bug in any of the applications I use. I can't find out in which app there is a bug to report it. Tell me please, if anyone faced such problems.
The heart of the issue was in incorrect configuration of Jenkins, it was my fault.
When I was configuring Jenkins I set maven goal as "install", but it must be "clean install". According to this Jenkins never deleted old files and kept them, so got a lot of issues of different kinds and with different log messages.
Due to Jenkins working specialty it downloads project files and try to assemble it on path /var/lib/jenkins/jobs/<projectName>/workspace/target/.
So I've drop the data in this folder and afterwards set maven goal to "clean install" and that fixed the issue.
I have Grails 2.0.4 application that depends on a jar that depends on org.apache.httpcomponents:httpcore:4.3.1
I'm getting a NoSuchField exception which I managed to track down to org.apache.http.impl.conn.BasicLineParser.INSTANCE.
This field is only present from httpcore 4.3, before this version the field was BasicLineParser.DEFAULT instead
My BuildConfig.groovy is like:
dependencies {
runtime 'mysql:mysql-connector-java:5.1.16'
runtime 'org.apache.httpcomponents:httpclient:4.3.1'
runtime 'org.apache.httpcomponents:httpcore:4.3.1'
}
Running the dependecy report I found out the there is a signpost-commonshttp4 by oauth.signpost that depends on httpcore:4.0.1 which is probably the root cause of my issue, because it doesn't have the INSTANCE property.
I've tried to exclude this dependency adding
runtime('oauth.signpost:signpost-commonshttp4:1.2.1.1'){
excludes 'httpcore'
}
with no success.
Is there any other way to prevent the code to use the older library version?
Regards
RESOLVED
I managed to resolve this issue adding an extra dependecies configuration
build 'org.apache.httpcomponents:httpclient:4.3.1'
build 'org.apache.httpcomponents:httpcore:4.3.1'
along with the runtime
Thank you all
I am playing with Weld-SE. I have a project which has pluggable modules. With one module, weld works. When other module, which uses weld-servlet-core, is put on classpath (with it's deps), CDI stops working, giving errors like "Unable to resolve dependency XY" or (after removing that #Inject) this:
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor</class> in jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml#11 is neither annotated #Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
...
Although the class has #Interceptor (and the same class works fine with the other module).
When I debug WeldBootstrap#startContainer(Environment environment, Deployment deployment),
deployment.beanDeploymentArchive.beanClasses contains the interceptor
("org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor").
I've checked the dependencies and TattleTale report, they all seem fine.
Any ideas what should I look at / try next?
The project is at http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ To see the error, run mvn dependency:copy-dependencies java -cp ... org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
Thanks, Ondra
Update: JIRA: https://issues.jboss.org/browse/WELD-940
Also, I found that it might be caused by a bug in Weld's scanning extension, <weld:scan>.
It was caused by using Weld's scanning extension, <weld:scan>:
An <includes> element contained package wildcard which resulted in matching classes in both "packages" (which is .jar in CDI / Weld's terminology IIUC).
I am not sure if I used it improperly or it's a bug.
See JIRA: https://issues.jboss.org/browse/WELD-940