We Keep Coding

Using Spring Data 2.6.1 with Eclipselink and Jakarta 3, is it possible?

We are currently bumping dependency versions of a Spring project with persistence based on JPA with Eclipselink. During the upgrade process I learned about Eclipselink switching to Jakarta namespace starting with version 3.0 due to legal reasons as explained in this thread.
We succeeded in updating the code so that we use Jakarta Persistence API 3.0.0 independently from Spring Data. The migration is quite straight forward:
Bump Eclipselink version to 3.0.x
Add an explicit dependency to Jakarta 3
Replace javax.persistence with jakarta.persistence in the code and in persistence.xml
Now I am looking into configuring Spring Data to use Eclipselink with Jakarta 3.0.0, but I noticed Spring still depends on JAXB 2.2.3. When I override the version in my Maven project, Spring Data complains on startup:
java.lang.NoClassDefFoundError: javax/persistence/EntityManagerFactory
at org.springframework.data.jpa.util.BeanDefinitionUtils.<clinit>(BeanDefinitionUtils.java:57)
at org.springframework.data.jpa.repository.support.EntityManagerBeanDefinitionRegistrarPostProcessor.postProcessBeanFactory(EntityManagerBeanDefinitionRegistrarPostProcessor.java:72)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:325)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:191)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:746)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:564)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:145)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:730)
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:412)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:302)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1301)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1290)
at com.mycompany.sandbox.springjpaeclipselinkfix.SpringApp.main(SpringApp.java:12)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49)
Caused by: java.lang.ClassNotFoundException: javax.persistence.EntityManagerFactory
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 18 common frames omitted
Apparently, it tries to create a persistence unit called default and fails to load javax/persistence/EntityManagerFactory (obviously, it is now in the jakarta.persistence package).
My understanding is that Spring Data's code depends on Jakarta 2 and using Jakarta 3 is not supported. However, it should be possible to use Eclipselink as Spring Data persistence provider and Eclipselink does support Jakarta 3. I am puzzled at this point and I cannot find any current examples for this, only old stuff relating to javax.persistence.
Is it possible to configure Spring Data to use Eclipselink 3 and Jakarta 3, or should I stick to the old namespace for now?
And if it's possible, can you point me to some current examples?
Obviously, one could fork Spring Data JPA's code and do the migration but I have not enough resources to maintain a branch.
I am posting also the relevant parts of my pom.xml (the rest resembles a standard Spring Data project):
<project>
...
<properties>
...
<jakarta-persistence.version>3.0.0</jakarta-persistence.version>
<eclipselink.version>3.1.0-M1</eclipselink.version>
</properties>
<dependencies>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
<exclusions>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
</exclusion>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
</dependency>
...
</dependencies>
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>${eclipselink.version}</version>
</dependency>
<dependency>
<groupId>jakarta.persistence</groupId>
<artifactId>jakarta.persistence-api</artifactId>
<version>${jakarta-persistence.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
...
</project>
Other tags: Jakarta EE 9, Jakarta Persistence 3.0, Java 17.

I found the answer in the Spring blog. Apparently the roadmap includes switching to the jakarta namespace "in Q4 2022":
As announced at SpringOne yesterday, Spring Framework 6 and Spring
Boot 3 are planned towards a high-end baseline for their general
availability in Q4 2022:
Java 17+ (from Java 8-17 in the Spring Framework 5.3.x line)
Jakarta EE 9+ (from Java EE 7-8 in the Spring Framework 5.3.x line)
This forward-looking baseline will provide significant benefits in our
API design and integration efforts, shining through to your
application code and future-proofing the framework as well as your
applications for many years to come. However, it comes at a cost, of
course: Spring Framework 6 and Spring Boot 3 based applications will
require a minimum of JDK 17 at runtime, as well as a minimum of Tomcat
10 / Jetty 11 (for Jakarta EE 9 compatibility). Even more importantly,
there might be some changes required in your application source code:
e.g. the javax to jakarta namespace change in Jakarta EE 9 wherever
you’re touching the Servlet API, JPA, Bean Validation, etc.
It is thus a matter of waiting until the change is rolled out by Spring.

NoClassDefFoundError while deploying a OpenID Azure AD java web-app on Weblogic

I am trying to integrate Azure AD for my web-app using OpenIDConnect approach. When I try to deploy the built ear file on weblogic I get NoClassDefFound for
com.nimbusds.openid.connect.sdk.AuthenticationSuccessResponse
. I have included oauth2-oidc-sdk-5.24.1.jar in the web-inf/lib folder, also verified that it is actually present within the ear file yet the application deployment fails complaining it is not able to find this class.
I found similar issue here. So I tried deploying both oauth2-oidc-sdk-5.24.1.jar and gson jar file as a library along with my java web app, but that did not help as well.
Much appreciated if I can get any pointers or suggestions to overcome this error.
The full stacktrace during deployment:
Caused By: java.lang.NoClassDefFoundError: com/nimbusds/openid/connect/sdk/AuthenticationSuccessResponse
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
at java.lang.Class.getDeclaredMethods(Class.java:1793)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getMethods(BaseJ2eeAnnotationProcessor.java:1055)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getMethods(BaseJ2eeAnnotationProcessor.java:1043)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.processJ2eeAnnotations(BaseJ2eeAnnotationProcessor.java:99)
at weblogic.j2ee.dd.xml.J2eeAnnotationProcessor.processJ2eeAnnotations(J2eeAnnotationProcessor.java:37)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processFilters(WebAnnotationProcessorImpl.java:239)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processJ2eeAnnotations(WebAnnotationProcessorImpl.java:210)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processAnnotations(WebAnnotationProcessorImpl.java:105)
at weblogic.servlet.internal.WebAppServletContext.processAnnotations(WebAppServletContext.java:1370)
at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:450)
at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:494)
at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:418)
at weblogic.servlet.internal.WebAppModule.registerWebApp(WebAppModule.java:976)
at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:384)
at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:45)
at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:648)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
#####################################
Update 2021/06/02
To resolve the version compatibility issue, I had to opt below specific versions of dependencies to get it not throw the error for JDK1.6, and microsoft adal4j had to recompiled in JDK6 (adal4j jar is supported on jdk1.7 and above)
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<classifier>jdk16</classifier>
<version>5.9</version>
<groupId>com.nimbusds</groupId>
<artifactId>oauth2-oidc-sdk</artifactId>
<classifier>jdk16</classifier>
<version>5.24.1</version>
</dependency>
If the JDK is 1.7, below is the specific versions that worked for me:
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>adal4j</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>oauth2-oidc-sdk</artifactId>
<version>5.24.1</version>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<version>7.8</version>
</dependency>
Hope this helps someone facing similar error on JDK1.6 and JDK1.7

This is usually caused by incompatible versions. You can try different versions of oauth2-oidc-sdk until you find a compatible package.
Or you can also change the version of spring to achieve the purpose of version compatibility as mentioned in the comments.

maven dependency conflict java.lang.NoSuchMethodError: org.apache.http.conn.ssl.SSLConnectionSocketFactory error when creating aws S3 client

I am getting the below error when I am trying to create amazon S3 client. It worked earlier and after I have done few code changed from then on I am seeing this error. I feel it could be of some dependency conflict but unable to find it out. Try many things but nothing could help.
java.lang.NoSuchMethodError: org.apache.http.conn.ssl.SSLConnectionSocketFactory.<init>(Ljavax/net/ssl/SSLContext;Ljavax/net/ssl/HostnameVerifier;)V
at com.amazonaws.http.conn.ssl.SdkTLSSocketFactory.<init>(SdkTLSSocketFactory.java:56)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.getPreferredSocketFactory(ApacheConnectionManagerFactory.java:91)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.create(ApacheConnectionManagerFactory.java:65)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.create(ApacheConnectionManagerFactory.java:58)
at com.amazonaws.http.apache.client.impl.ApacheHttpClientFactory.create(ApacheHttpClientFactory.java:51)
at com.amazonaws.http.apache.client.impl.ApacheHttpClientFactory.create(ApacheHttpClientFactory.java:39)
at com.amazonaws.http.AmazonHttpClient.<init>(AmazonHttpClient.java:301)
at com.amazonaws.AmazonWebServiceClient.<init>(AmazonWebServiceClient.java:164)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:523)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:503)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:485)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:457)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:439)
at com.ge.hc.cloud.e2e.workflows.steps.BasicWorkflowSteps.<clinit>(BasicWorkflowSteps.java:72)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:386)
at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
at net.thucydides.core.steps.StepFactory.webEnabledStepLibrary(StepFactory.java:201)
at net.thucydides.core.steps.StepFactory.createProxyStepLibrary(StepFactory.java:164)
at net.thucydides.core.steps.StepFactory.instantiateNewStepLibraryFor(StepFactory.java:117)
at net.thucydides.core.steps.StepFactory.instantiateNewStepLibraryFor(StepFactory.java:109)
at net.thucydides.core.steps.StepFactory.getNewStepLibraryFor(StepFactory.java:77)
at net.thucydides.core.steps.StepFactory.getStepLibraryFor(StepFactory.java:72)
at net.thucydides.core.steps.StepAnnotations.instantiateAnyUnitiaializedSteps(StepAnnotations.java:52)
at net.thucydides.core.steps.StepAnnotations.instanciateScenarioStepFields(StepAnnotations.java:41)
at net.thucydides.core.steps.StepAnnotations.injectScenarioStepsInto(StepAnnotations.java:23)
at net.serenitybdd.jbehave.SerenityStepFactory.createInstanceOfType(SerenityStepFactory.java:80)
at org.jbehave.core.steps.StepCreator.stepsInstance(StepCreator.java:83)
at org.jbehave.core.steps.StepCreator$ParametrisedStep.perform(StepCreator.java:595)
at org.jbehave.core.embedder.StoryRunner$FineSoFar.run(StoryRunner.java:566)
Appreciate any kind of help.

I faced the similar issue. I was using AWS JavaV2 SDK software.amazon.awssdk with version 2.19.14.
The Amazon Java SDK jar that I had imported had a dependency on org.apache.httpcomponents. Once I imported the dependency and built the project again, I was able to create the client.
My pom.xml looked something like this.
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>ssm</artifactId>
</dependency>
</dependencies>

Maven dependencies in a Mule project . Classloader control not working as expected

I'm trying to build a mule project in maven which uses a library that in turn uses apache-commons-codec-1.8 . Mule 3.5 currently supports only v 1.3
In order to get around this Ive implemented classloader control in mule and blocked mule from loading its version of the library by doing the following in mule-deploy.properties.
loader.override=-org.apache.commons.codec
In addition I've updated my pom.xml to include the 1.9 version of the library . Here is a snapshot of running mvn:dependency tree on the project.
However, when I run my test method I get a runtime exception
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString([B)Ljava/lang/String;
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:64)
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:91)
at com.nimbusds.jose.Header.toBase64URL(Header.java:238)
at com.nimbusds.jose.JWSObject.<init>(JWSObject.java:101)
at com.package.components.lastmile.originator.TokenSignerTemplate.sign(TokenSignerTemplate.java:109)
at com.package.components.lastmile.originator.TokenSignerTemplate.signClaim(TokenSignerTemplate.java:122)
at com.package.orchestration.LMSFakeClaimsHandler.testSignParse_Positive(LMSFakeClaimsHandler.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
which is clearly because it's referencing the older version of apache-commons. How do I make sure that it references only the latest version and not the older version?
mule-deploy.properties
#Fri Dec 12 09:58:12 PST 2014
loader.override=-org.apache.commons.codec
redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=..flows.
.
Relevant positions of pom.xml
<dependencies>
....
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.9</version>
</dependency>
....
<!-- Test to check commons-codec works -->
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
P.S: The same snippet seems to work fine on a non mule project, indicating this is a mule related issue.

If you are running the Mule app in Mule server, excluding the lib from the pom will not work, since the codec lib is present in the server itself.
Try to insert the newest codec lib version in the server lib shared folder (maintaining the property loader.override=-org.apache.commons.codec)

Add the following exclusion to your pom.
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
And then add the dependency of Commons Codec 1.9.
Then your override property in mule-deploy.properties will work as expected.
Update: 12/30:
The override property seems to be the problem.
loader.override=-org.apache.commons.codec is not correct.
Try the following
loader.override=org.apache.commons.codec
Hope this helps.

I have a similar issue with the jackson-xc. I don't know why Mule 3.5 comes with a mix of jackson 1 and 2 libraries
jackson-annotations-2.1.1.jar
jackson-core-2.1.1.jar
jackson-databind-2.1.1.jar
jackson-core-asl-1.9.11.jar
jackson-jaxrs-1.9.11.jar
jackson-mapper-asl-1.9.11.jar
jackson-xc-1.7.1.jar
And with jackson-xc-1.7.1 instead of jackson-xc-1.9.11 that would be aligned to the version of the other jackson 1 libraries.
In my application it is producing the "classic" library issue exception:
Caused by: java.lang.AbstractMethodError
at org.codehaus.jackson.map.AnnotationIntrospector$Pair.findDeserializer(AnnotationIntrospector.java:1335)
Since using
loader.override=...
into the mule-deploy.properties didn't work (with either override and/or blocking on the package org.codehaus.jackson.xc and on the class org.codehaus.jackson.xc.JaxbAnnotationIntrospector) the only solution I have found goes in the direction of Nuno's answer and is to put the jar we want to use in a lib folder with higher priority than lib/opt
lib/shared has been deprecated but you can use lib/user to override.
I would prefer to use the loader.override (classloader-control-in-mule 3.5) and avoid the modification of all the installation, but for now is the only solution that is working for me.

Incompatible argument to function

My ear application runs well on Tomcat 6 on local window PC, but it cannot run on Weblogic server 10.3.6 on the same PC.
Caused By: java.lang.VerifyError: (class: org/springframework/web/servlet/FrameworkServlet, method: processRequest signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) Incompatible argument to function
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
at java.lang.Class.getDeclaredFields(Class.java:1743)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getFields.....
Below is part of my pom.xml which might be related to the problem.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>compile</scope>
</dependency>

From your webapp's /WEB-INF/lib folder, remove all Tomcat-specific libraries like el-ri.jar, el-api.jar. It will make your webapp incompatible with containers of a different make/version resulting in this kind of errors.
For more info clear explanation see here
Possible cause 1:
java.lang.VerifyError can be the result when you have compiled against a different library than you are using at runtime.
Refer here Causes of getting a java.lang.VerifyError
Possible cause 2:
How do I import the javax.servlet API in my Eclipse project?
Specially read this paragraph
You should above all never manually copy/download/move/include the individual servletcontainer-specific libraries like servlet-api.jar, jsp-api.jar, el-api.jar, j2ee.jar, javaee.jar, etc. It would only lead to future portability, compatibility, classpath and maintainability troubles, because your webapp would not work when it's deployed to a servletcontainer of a different make/version than where those libraries are originally obtained from.