Develop Reference

How to debug java.lang.ClassNotFoundException during Tomcat startup?

When Tomcat loads my war, I get this error:
Exception in thread "ClientMessageReceptor0" java.lang.NoClassDefFoundError: java/net/Inet6Address
at org.jacorb.orb.iiop.IIOPAddress.getNetworkInetAddresses(IIOPAddress.java:675)
at org.jacorb.orb.iiop.IIOPAddress.getLocalHost(IIOPAddress.java:591)
at org.jacorb.orb.iiop.IIOPAddress.getLocalHostAddress(IIOPAddress.java:574)
at org.jacorb.orb.listener.SSLListenerUtil.processException(SSLListenerUtil.java:73)
at org.jacorb.orb.iiop.IIOPConnection.handleCommFailure(IIOPConnection.java:77)
at org.jacorb.orb.etf.StreamConnectionBase.read(StreamConnectionBase.java:139)
at org.jacorb.orb.giop.GIOPConnection.getMessage(GIOPConnection.java:389)
at org.jacorb.orb.giop.GIOPConnection.receiveMessagesLoop(GIOPConnection.java:541)
at org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.java:533)
at org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:69)
at org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:60)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: Illegal access: this web application instance has been stopped already. Could not load [java.net.Inet6Address]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1375)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1226)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1188)
Our application uses Tomcat v9.0.41 and JDK 1.8.0_111 . This same combination works for others in my team and also it worked for me sometime back. I'm not sure what changed now. I have looked at other similar posts and they suggest mismatch between Tomcat and JDK version. But above combination of Tomcat and JDK works for others.
I have removed all other JDK and JRE version on my system.
Ensured JAVA_HOME points to JDK 1.8.0_111 and PATH points to correct JRE.
Any pointers on how to debug this further? Can I turn on some logging during Tomcat startup to see what paths are being used by Tomcat? Any suggestions are highly appreciated :).

Wildfly org.jboss.nio -> FileNotFoundException: Invalid file path with Windows Java JDK 11.0.15+10

Since the update to Eclipse Tamurin JDK 11.0.15+10 we notice a problem as soon a HTTP request reaches Wildfly 20.0.1.Final. The same behaviour exsists in Wildfly 26.1.0.Final This only happens with the JDK Windows version, the Linux JDK works fine.
As it is an "Invalid file path" error, an OS dependent BUG seems possible.
Until now SAP Machine is the only JDK that does not encounter this failure.
I'm still not sure if this is a JDK or a Wildfly problem...
You can check that when opening the Wildfly Management Interface.
ERROR [io.undertow.request] (External Management Request Threads -- 1) UT005071: Undertow request failed HttpServerExchange{ GET /management}: java.io.IOError: java.io.FileNotFoundException: Invalid file path
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1103)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1093)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels.<clinit>(Channels.java:1093)
at io.undertow.core#2.1.3.Final//io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:231)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:245)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:238)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:75)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:107)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainUtil.writeResponse(DomainUtil.java:89)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler$1.doSendResponse(DomainApiHandler.java:177)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.ResponseCallback.sendResponse(ResponseCallback.java:32)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:232)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:91)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at io.undertow.core#2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.core#2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:829)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.FileNotFoundException: Invalid file path
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:231)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:126)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1098)
... 29 more
JDK
Works with Wildfly
Eclipse Tamurin
no
Amazon Coretto
no
Azul Zulu
no
Bellsoft
no
Oracle OpenJDK
no
Oracle JDK
no
SAP Machine
yes

This is an issue in the JDK. You can wait for JDK 11.0.16 or downgrade to a lower version like JDK 11.0.14.

This is caused by a known JDK bug. You can work around the issue by setting Djdk.io.File.enableADS system property. In Intellij go to Run -> Edit configurations and paste -Djdk.io.File.enableADS=true in VM Options field.

How to fix "Could not initialize class org.apache.ignite.IgniteJdbcThinDriver" error in Apache Ignite?

The Problem
I'm trying to connect to a Apache Ignite server with Apache Ignite built-in tool, SQLLine. I get the error: java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
Background
I have Apache Ignite running in a container and CentOS7 running in another container. Both containers running in the same network (pinging works both ways). The tried connection is happening from CentOS7 to Apache Ignite.
Apache Ignite seems to be running fine with just the default configuration. In the CentOS7 container, I have installed Oracle JDK 12.0.1 and I have Apache Ignite 2.7.0 binary files in a folder. I have also set the IGNITE_HOME environmental variable.
Here, (https://apacheignite-sql.readme.io/docs/sqlline), it says I can connect to my cluster with just: ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1/. However, this throws the previously mentioned error.
SQLLine should come with Ignite JDBC drivers. I have tried downloading them manually (https://apacheignite-sql.readme.io/docs/jdbc-driver#section-multiple-endpoints). When I downloaded the driver, which is said to be the ignite-core-{version}.jar, I put it in the same folder as sqlline.jar files.
Output
[root#bc72c4fbf47e bin]# ./sqlline.sh
sqlline version 1.3.0
sqlline> !connect jdbc:ignite:thin://172.19.0.2/
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/var/tmp/apache-ignite/libs/ignite-core-2.7.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:415)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
at sqlline.SqlLine.findRegisteredDriver(SqlLine.java:1568)
at sqlline.SqlLine.scanForDriver(SqlLine.java:1542)
at sqlline.Commands.connect(Commands.java:1074)
at sqlline.Commands.connect(Commands.java:1001)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
Conclusion
I should be able to connect to my Ignite server with !connect jdbc:ignite:thin://172.19.0.2/ command in sqlline.
This does not work, and throws Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
IgniteJDBCThinDriver is installed/available.

Adding JVM argument
--add-opens java.base/java.nio=ALL-UNNAMED
solved the problem for me.

It is recommended to Java 8, as Apache Ignite 2.7.0 does not have full Java 12 support. Otherwise you can try tinkering with JVM options.

Thank you #alamar, that worked!
I uninstalled JDK12 that i had installed with RPM.
Check the package name:
rpm -qa | grep jdk.
Delete the package:
rpm -e jdk-12.0.1-12.0.1-ga.x86_64.
I'm working on a isolated system, so I downloaded and transferred JDK8.rpm from another machine.
Install JDK8:
rpm -ihv jdk-8u211-linux-x64.rpm.
Now when I run:
./sqlline.sh --verbose=true -u jdbc:ignite:thin://172.19.0.2,
I get:
issuing: !connect jdbc:ignite:thin://172.19.0.2/ '' '' org.apache.ignite.IgniteJdbcTh
Connecting to jdbc:ignite:thin://172.19.0.2/
Connected to: Apache Ignite (version 2.7.0#20181130-sha1:256ae401)
Driver: Apache Ignite Thin JDBC Driver (version 2.7.0#20181130-sha1:256ae401)
Autocommit status: true
Transaction isolation: TRANSACTION_REPEATABLE_READ
sqlline version 1.3.0.
I can now query my database.

I got this error in the following very strange situation:
A dependency of my maven java project had Apache-Ignite as a dependency. The moment I opened a connection to a SQLite database at an invalid path (e.g. ./result/r.sqlite where the folder ./result does not exist) this error occurred (using th driver org.xerial.sqlite-jdbc:v3.30.1.)So this call
Class.forName("org.sqlite.JDBC");
Connection conn = DriverManager.getConnection("jdbc:sqlite:result.sqlite")
would result in this stacktrace:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:674)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:251)
at MyClass.myMethod(MyClass.java:154)
So the solution would obviously be to make sure the folder exsits where the sqlite database should be created in.

Tomcat not running for a JAR file

I am using Postman alongside a JAR file that runs a REST service that holds some contacts. However when I try to run the JAR file by using: java -jar ContactListRESTService.jar in Powershell, I am seeing a bunch of errors that Apache Tomcat could not run. Postman also doesn't recognize the localhost.
Caused by: java.lang.IllegalStateException: Tomcat connector in failed state
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.start(TomcatEmbeddedServletContainer.java:159)
Caused by: java.lang.IllegalStateException: Tomcat connector in failed state
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.start(TomcatEmbeddedServletCntainer.java:159) ~[spring-boot 1.3.7.RELEASE.jar!/:1.3.7.RELEASE]
I have tried uninstalling and reinstalling JAVA SE per some guidance from a mentor with no results.
If anyone can point me in the right direction please.

Where to deploy jars for a Domino Agent

I've an agent that use Axis jars.
Which are the alternatives for these jars deploying?
If I put them into lib/ext folder on server, everything works fine, but I wouldn't deploy "by hand" all jars in every production server.
If I put them into Archive agent section, also into WEB-INF/lib project folder, I always have a java.lang.ClassNotFoundException error.
UPDATE 1
I tried to deploy a jar into notesdata/domino/java folder and modified notes.ini JavaUserClasses variable to point to this jar, but same error!
UPDATE 2
As suggested, I put the jar (axiom-api-1.2.8.jar) into agent Archive, but still the same error
HTTP JVM: java.lang.NoClassDefFoundError: org.apache.axiom.om.OMNode
HTTP JVM: at java.lang.J9VMInternals.verifyImpl(Native Method)
HTTP JVM: at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
HTTP JVM: at java.lang.J9VMInternals.verify(J9VMInternals.java:70)
HTTP JVM: at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
HTTP JVM: at org.apache.axis2.context.ConfigurationContextFactory.createBasicConfigurationContext(ConfigurationContextFactory.java:337)
HTTP JVM: at org.apache.axis2.context.ConfigurationContextFactory.createDefaultConfigurationContext(ConfigurationContextFactory.java:326)
HTTP JVM: at JavaAgent.NotesMain(JavaAgent.java:499)
HTTP JVM: at lotus.domino.AgentBase.runNotes(Unknown Source)
HTTP JVM: at lotus.domino.NotesThread.run(Unknown Source)

The right place to put jar is into agent's Archive section.
The problem experienced during my test following
HTTP JVM: java.lang.NoClassDefFoundError: org.apache.axiom.om.OMNode
doesn't depend on the axiom-api-1.2.8.jar absence, but on the absence of the whole jar dependencies.
Infact, including all jars needed, everything work's fine.
Thanks Knut for your suggestion.