After updating to Java 11 we get the following message:
[4/3/20, 11:47:09:184 CEST] 0000002d com.ibm.ws.classloading.internal.util.FeatureSuggestion I CWWKL0084W: The javax.transaction.TransactionManager class could not be loaded. Try enabling the jdbc-4.0 feature or a newer version of the feature in the server.xml file.
We are already using jdbc-4.3 (had the same message on 4.2 as well). The application itself does not give any errors that I can see. The application is made with maven that has the compile plugin configured with 11.
There are no problems when compiling and running tests for the application on java 11, and this only appears when deployed to liberty. Should we explicitly include a dependency for this in the war, or is this an issue that should be fixed in liberty?
From later releases on, Java EE is not included any more. The transaction classes are in the javax.transaction package.
Adding the following dependency should solve it:
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>1.1</version>
</dependency>
(Not sure if it helps with your deployment, but it works with Spring Boot 2)
Related
Description
When I develop my java project I use:
Java version: 1.8,
Apache Tomcat version 9.0.x
Then, I use Tomcat 10.0.x to run my project (with few modifications in my project). I had to change javax package related imports to jakarta package imports.
When I build the project I got this following error;
java: cannot access javax.servlet.ServletException
class file for javax.servlet.ServletException not found
Fix
When I search for a fix, I found that I need to include Java Servlet API dependency in my pom.xml file. This way I could build the project successfully.
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
Question
Why do I have to include Java Servlet API dependency when I
migrate to Tomcat 10 ?
I did include Java Servlet API dependency,
but is that a proper fix?
Why do I have to include Java Servlet API dependency when I migrate to Tomcat 10 ?
Presumably because your application has a dependency on something that conforms to the JSP 4.0.x specs.
I did include Java Servlet API dependency, but is that a proper fix?
No it is not the proper fix. While you have succeeded in building your app, you will most get classloader errors when you deploy to Tomcat 10. That's because the Tomcat 10 runtime libraries don't provide the javax.servlet.* classes.
The correct approach is to identify why your application or its dependencies are trying to use classes in javax.servlet ... and eliminate this.
Remove the javax.servlet / javax.servlet-api / 4.0.1 dependency.
Search your application codebase for any remaining references to javax.servlet ... and change them.
Use the Maven dependency tree plugin to try to identify which of your applications dependencies has a dependency on the old javax.servlet API. Look for newer versions of those dependencies that use jakarta.servlet instead.
If 2 and 3 don't identify the culprit, it gets rather difficult. You might need to unpack all of the dependent JAR files and "analyze" them using javap and grep. Or there might be better way.
If you are able to identify the dependencies, but you can't find a Jakarta-compatible version, then you have another kind of problem. You have to choose between putting in the effort to port the dependency, finding another library (or whatever) to provide the functionality, or remove the functionality from your web app.
I upgraded from springboot 2.1.3 to 2.2.0. So far things works fine but I noticed when I make a rest request that returns a 400, instead of getting the json response I get the error:
[Tomcat].[localhost] : Exception Processing ErrorPage[errorCode=0, location=/error]
java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.getHttpServletMapping()Ljavax/servlet/http/HttpServletMapping;
The funny thing is I get this only when I start the app from Intellij using an emdedded tomcat. (create a mvn profile with "spring-boot:run")
So,
With standalone tomcat, it works fine everywhere
With embedded tomcat, and only if I start from Intellij I get this error.
But I can do the same thing from command line with
mvn spring-boot:run
which then I have no error ?! As suggested on another post I upgraded my IntelliJ to latest version but didn't help
i think you have to upgrade the version of ur tomcat emdedded , there is a version mismatch.
Spring Boot 2.1.X uses Tomcat 9 which has the Servlet API v4.
But Spring Boot Web 2.1.X still incorporates Servlet API v3.1.
OR
Change tomcat version proprety
<properties>
<tomcat.version>8.5.37</tomcat.version>
<properties>
NB:The tomcat.version property is a normal Maven property in your pom.xml. Just add the tomcat.version to your existing Maven properties
I fixed the problem.
Changing property tomcat.version didn't help, so I omitted it and added this to the child pom (trick is it does not work in parent pom). Also note that the version is 2.2.4 and not 2.2.0
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<version>2.2.4.RELEASE</version>
</dependency>
Just wanted to mention another "solution", because I just faced the same problem, after upgrading to Spring Boot 2.4.0
My App is running on Java 11, Spring Boot 2.4.0 AND JakartaEE Api 8.0.0
For a long time I ignored the Jakarta Version, because I found nothing regarding my problem and this dependency in the web.
But after upgrading JakartaEE to 9.0.0 everything worked out fine.
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.0.0</version>
</dependency>
That was the solution for my problem :) maybe it helps others.
Getting java.lang.IllegalArgumentException: Jetty ALPN/NPN has not been properly configured, while using gRPC(google pub/sub) to publish/consumes messages from Kafka.
Try adding a runtime dependency on netty-tcnative-boringssl-static. See gRPC's SECURITY.md. Note that the version of netty-tcnative necessary changes over time; you should look at the version of the document for a particular release (e.g., this is for 1.2.0).
Finally, went back to boot class class path approach. Prefixed the jetty-alpn.jar to boot class path and it starts working fine in cloud foundry now.
Adding the ALPN client JAR which matches my JDK version fixed this issue for me. In eclipse, you need to set up the jar as a bootstrap entry for the tomcat server.
You can find more info about it here : https://medium.com/#Parithi/jetty-alpn-npn-has-not-been-properly-configured-solution-418417ee6502
As suggested by google, use jetty container instead of tomcat, this solution works, but in our production, applications deployed on tomcat container, but of course I need it to work on tomcat in production.
On debugging the gRPC code, found that guava version causing the issue, updated the guava version 18.0, (where in some classes missed in previous versions), solved the problem , but failed while deploying in CF
Customized emebed-tomcat-core, and it works fine consistently, but again, team say no to custom tomcat container.
Java –jar apm-asset-xxxx.jar – works fine locally, but need to provide a custom command to CF start, didn’t have luxury to change the CF start process.
Finally, trick, the class loader to use tcnative-boring-ssl, library instead of tomcat-core library at runtime, by providing the following dependency in pom.xml. For the past 3 days, this solution is working CF.
org.springframework.boot
spring-boot-starter-web
org.hibernate
*
org.apache.tomcat.embed
tomcat-embed-core
org.apache.tomcat.embed
tomcat-embed-core
provided
Maven manifest plugin to promote the tc-native library to the top in the classloader.
In POM, try to place the gRPC dependency before the spring boot dependency (the order of dependencies matters). I did that and the issue was solved. For example:
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-language</artifactId>
<version>0.13.0-beta</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
I have a Play Framework application and I was using Hibernate 4.2.5.Final (which is retrieved via the Maven dependency manager). I decided to upgrade to Hibernate 4.3.0.Final, recompile my application successfully, and ran it.
I got the exception below, and haven't been able to figure out why. I downgraded back to 4.2.5 and this issue did not occur. I then, tried upgrading Hibernate with each Final release after 4.2.5. That is, I went from 4.2.5.Final to 4.2.6.Final, to 4.2.7.Final, to 4.2.8.Final and then to 4.3.Final. The issue does not occur until I upgrade to 4.3.0.Final.
Java version information
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
And exception:
play.api.UnexpectedException: Unexpected exception[NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:152) ~[play_2.10.jar:2.2.1]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
at scala.Option.map(Option.scala:145) ~[scala-library.jar:na]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:110) ~[play_2.10.jar:2.2.1]
at scala.util.Success.flatMap(Try.scala:200) ~[scala-library.jar:na]
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:781) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3762) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3716) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
I've ran into the same problem. The question here is that play-java-jpa artifact (javaJpa key in the build.sbt file) depends on a different version of the spec (version 2.0 -> "org.hibernate.javax.persistence" % "hibernate-jpa-2.0-api" % "1.0.1.Final").
When you added hibernate-entitymanager 4.3 this brought the newer spec (2.1) and a different factory provider for the entitymanager. Basically you ended up having both jars in the classpath as transitive dependencies.
Edit your build.sbt file like this and it will temporarily fix you problem until play releases a new version of the jpa plugin for the newer api dependency.
libraryDependencies ++= Seq(
javaJdbc,
javaJpa.exclude("org.hibernate.javax.persistence", "hibernate-jpa-2.0-api"),
"org.hibernate" % "hibernate-entitymanager" % "4.3.0.Final"
)
This is for play 2.2.x. In previous versions there were some differences in the build files.
Hibernate 4.3 is the first version to implement the JPA 2.1 spec (part of Java EE 7). And it's thus expecting the JPA 2.1 library in the classpath, not the JPA 2.0 library. That's why you get this exception: Table.indexes() is a new attribute of Table, introduced in JPA 2.1
I update my Hibernate JPA to 2.1 and It works.
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
</dependency>
You probablly have 2 different versions of hibernate-jpa-api on the classpath. To check that run:
mvn dependency:tree >dep.txt
Then search if there are hibernate-jpa-2.0-api and hibernate-jpa-2.1-api. And exclude the excess one.
I could solve the issue simply by replacing the JPA api jar file which is located jboss7/modules/javax/persistence/api/main with 'hibernate-jpa-2.1-api'. also with updating module.xml in the directory.
Error:
java.lang.NoSuchMethodError: javax.persistence.JoinTable.indexes()[Ljavax/persistence/Index;
The only thing that solved my problem was removing the following dependency in pom.xml:
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
</dependency>
And replace it for:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
</dependency>
Hope it helps someone.
i have experienced same issue in my spring boot application. after removing manually javax.persistance.jar file from lib folder. issue was fixed. in pom.xml file i have remained following dependency only
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
I had the same issue, I fixed it by using org.hibernate.annotations.Table annotation instead of javax.persistence.Table in the Entity class.
import javax.persistence.Entity;
import org.hibernate.annotations.Table;
#Entity
#Table(appliesTo = "my_table")
public class MyTable{
//and rest of the code
There are multiple JPA providers in your classpath. Or atleast in your Application server lib folder.
If you are using Maven
Check for dependencies using command mentioned here https://stackoverflow.com/a/47474708/3333878
Then fix by removing/excluding unwanted dependency.
If you just have one dependecy in your classpath, then the application server's class loader might be the issue.
As JavaEE application servers like Websphere, Wildfly, Tomee etc., have their own implementations of JPA and other EE Standards, The Class loader might load it's own implementation instead of picking from your classpath in WAR/EAR file.
To avoid this, you can try below steps.
Removing the offending jar in Application Servers library path. Proceed with Caution, as it might break other hosted applications.
In Tomee 1.7.5 Plume/ Web it will have bundled eclipselink-2.4.2 in the lib folder using JPA 2.0, but I had to use JPA 2.1 from org.hibernate:hibernate-core:5.1.17, so removed the eclipselink jar and added all related/ transitive dependencies from hibernate core.
Add a shared library. and manually add jars to the app server's path. Websphere has this option.
In Websphere, execution of class loader can be changed. so making it the application server's classpath to load last i.e, parent last and having your path load first. Can solve this.
Check if your appserver has above features, before proceeding with first point.
Ibm websphere References :
https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/trun_classload_server.html
https://www.ibm.com/support/pages/how-create-shared-library-and-associate-it-application-server-or-enterprise-application-websphere-application-server
I have a Play Framework application and I was using Hibernate 4.2.5.Final (which is retrieved via the Maven dependency manager). I decided to upgrade to Hibernate 4.3.0.Final, recompile my application successfully, and ran it.
I got the exception below, and haven't been able to figure out why. I downgraded back to 4.2.5 and this issue did not occur. I then, tried upgrading Hibernate with each Final release after 4.2.5. That is, I went from 4.2.5.Final to 4.2.6.Final, to 4.2.7.Final, to 4.2.8.Final and then to 4.3.Final. The issue does not occur until I upgrade to 4.3.0.Final.
Java version information
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
And exception:
play.api.UnexpectedException: Unexpected exception[NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:152) ~[play_2.10.jar:2.2.1]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
at scala.Option.map(Option.scala:145) ~[scala-library.jar:na]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:110) ~[play_2.10.jar:2.2.1]
at scala.util.Success.flatMap(Try.scala:200) ~[scala-library.jar:na]
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:781) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3762) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3716) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
I've ran into the same problem. The question here is that play-java-jpa artifact (javaJpa key in the build.sbt file) depends on a different version of the spec (version 2.0 -> "org.hibernate.javax.persistence" % "hibernate-jpa-2.0-api" % "1.0.1.Final").
When you added hibernate-entitymanager 4.3 this brought the newer spec (2.1) and a different factory provider for the entitymanager. Basically you ended up having both jars in the classpath as transitive dependencies.
Edit your build.sbt file like this and it will temporarily fix you problem until play releases a new version of the jpa plugin for the newer api dependency.
libraryDependencies ++= Seq(
javaJdbc,
javaJpa.exclude("org.hibernate.javax.persistence", "hibernate-jpa-2.0-api"),
"org.hibernate" % "hibernate-entitymanager" % "4.3.0.Final"
)
This is for play 2.2.x. In previous versions there were some differences in the build files.
Hibernate 4.3 is the first version to implement the JPA 2.1 spec (part of Java EE 7). And it's thus expecting the JPA 2.1 library in the classpath, not the JPA 2.0 library. That's why you get this exception: Table.indexes() is a new attribute of Table, introduced in JPA 2.1
I update my Hibernate JPA to 2.1 and It works.
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
</dependency>
You probablly have 2 different versions of hibernate-jpa-api on the classpath. To check that run:
mvn dependency:tree >dep.txt
Then search if there are hibernate-jpa-2.0-api and hibernate-jpa-2.1-api. And exclude the excess one.
I could solve the issue simply by replacing the JPA api jar file which is located jboss7/modules/javax/persistence/api/main with 'hibernate-jpa-2.1-api'. also with updating module.xml in the directory.
Error:
java.lang.NoSuchMethodError: javax.persistence.JoinTable.indexes()[Ljavax/persistence/Index;
The only thing that solved my problem was removing the following dependency in pom.xml:
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
</dependency>
And replace it for:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
</dependency>
Hope it helps someone.
i have experienced same issue in my spring boot application. after removing manually javax.persistance.jar file from lib folder. issue was fixed. in pom.xml file i have remained following dependency only
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
I had the same issue, I fixed it by using org.hibernate.annotations.Table annotation instead of javax.persistence.Table in the Entity class.
import javax.persistence.Entity;
import org.hibernate.annotations.Table;
#Entity
#Table(appliesTo = "my_table")
public class MyTable{
//and rest of the code
There are multiple JPA providers in your classpath. Or atleast in your Application server lib folder.
If you are using Maven
Check for dependencies using command mentioned here https://stackoverflow.com/a/47474708/3333878
Then fix by removing/excluding unwanted dependency.
If you just have one dependecy in your classpath, then the application server's class loader might be the issue.
As JavaEE application servers like Websphere, Wildfly, Tomee etc., have their own implementations of JPA and other EE Standards, The Class loader might load it's own implementation instead of picking from your classpath in WAR/EAR file.
To avoid this, you can try below steps.
Removing the offending jar in Application Servers library path. Proceed with Caution, as it might break other hosted applications.
In Tomee 1.7.5 Plume/ Web it will have bundled eclipselink-2.4.2 in the lib folder using JPA 2.0, but I had to use JPA 2.1 from org.hibernate:hibernate-core:5.1.17, so removed the eclipselink jar and added all related/ transitive dependencies from hibernate core.
Add a shared library. and manually add jars to the app server's path. Websphere has this option.
In Websphere, execution of class loader can be changed. so making it the application server's classpath to load last i.e, parent last and having your path load first. Can solve this.
Check if your appserver has above features, before proceeding with first point.
Ibm websphere References :
https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/trun_classload_server.html
https://www.ibm.com/support/pages/how-create-shared-library-and-associate-it-application-server-or-enterprise-application-websphere-application-server