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.
Using journey browser project I have set up a simple maven project in eclipse, using the dependency provided on the page, I have tried to run the code example (also provided on the page)
And I get an NPE:
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:588)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:583)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/java.awt.Toolkit.getDefaultToolkit(Toolkit.java:582)
at java.desktop/java.awt.Toolkit.getEventQueue(Toolkit.java:1494)
at java.desktop/java.awt.EventQueue.isDispatchThread(EventQueue.java:1086)
at java.desktop/javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1493)
at com.codebrig.journey.JourneyBrowserView.<init>(JourneyBrowserView.java:78)
at com.codebrig.journey.JourneyBrowserView.<init>(JourneyBrowserView.java:71)
at JourneyBrowser.main(JourneyBrowser.java:13)
Caused by: java.lang.NullPointerException
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2646)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
at java.base/java.lang.System.loadLibrary(System.java:1870)
at java.desktop/sun.awt.windows.WToolkit$1.run(WToolkit.java:118)
at java.desktop/sun.awt.windows.WToolkit$1.run(WToolkit.java:115)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.awt.windows.WToolkit.loadLibraries(WToolkit.java:114)
at java.desktop/sun.awt.windows.WToolkit.<clinit>(WToolkit.java:129)
... 12 more
Can anyone explain what is happening and why here, I have tried this on 64bit windows with java Coretto 11(jdk11.0.7_10),I initially found a bug here, relating to loadLibray in open JDK and thought that maybe the problem, I just don't have a good enough understanding to work out how to get around it?
I'm not sure, but I think that Corretto bug is probably the one that is causing the problem. As noted, it is from their "upstream"; i.e the OpenJDK codebase. It was due to regression that appeared in jdk11.0.7 due to a backport of a fix for another problem. Apparently, the fix changes some internal JDK fields and that breaks application code. As JDK-8240521 puts it:
The backport of the JDK-8231584 changes internal JDK fields processing. The problem is that the many third-party applications copy-pasted a hack that depends on particular JDK implementation.
If I am reading the Oracle bug entries correctly, the reversion of the broken fix should be in JDK11.0.8. Alternatively, an earlier JDK 11 release than 11.0.7 shouldn't have the broken fix.
Let me know if changing your Java 11 install solves the problem. (If not, I'll see if I can get the line numbers to match up.)
Recently I moved from the Oracle JDK 8 to Open JDK 8 (version: openjdk-1.8.0.242.b08) for Cloudera. Cloudera version is 5.16.2. I have Kerberos and TLS enabled. When I am using Oracle JDK the below issue doesn't occur but when I switch to Open JDK then I am getting the below error. Please note that the proxy user is already enabled from the CM -> HDFS -> configuration.
JobHistoryServer
Error starting JobHistoryServer
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: Error creating done directory: [hdfs://XXXX.YYY.COM:8020/user/history/done]
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:680)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.createHistoryDirs(HistoryFileManager.java:616)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.serviceInit(HistoryFileManager.java:577)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistory.serviceInit(JobHistory.java:95)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:107)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.serviceInit(JobHistoryServer.java:154)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.launchJobHistoryServer(JobHistoryServer.java:229)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.main(JobHistoryServer.java:239)
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): User: RZgWaGioVf#YYY.COM is not allowed to impersonate mapred/XXXX.YYY.COM#YYY.COM
at org.apache.hadoop.ipc.Client.call(Client.java:1504)
at org.apache.hadoop.ipc.Client.call(Client.java:1441)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:231)
at com.sun.proxy.$Proxy16.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:258)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
at com.sun.proxy.$Proxy17.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:2168)
at org.apache.hadoop.fs.Hdfs.getFileStatus(Hdfs.java:133)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1143)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1139)
at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
at org.apache.hadoop.fs.FileContext.getFileStatus(FileContext.java:1139)
at org.apache.hadoop.fs.FileContext$Util.exists(FileContext.java:1604)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.mkdir(HistoryFileManager.java:733)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:663)
This is a known bug I filed with openJDK.
"KerberosTicket client name refers wrongly to sAMAccountName in AD", Major loss of Function.
It is tracked here: https://bugs.openjdk.java.net/browse/JDK-8239385
This issue is resolved. The issue was due to the cross-realm referrals support for Kerberos (JDK-8215032). You need to set -Dsun.security.krb5.disableReferrals=true property of the service or to set this is java.security file.
Might be related to my problem: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1861883
I also reported this to the OpenJDK bug report site (twice) but no reaction so far.
If your problem disappears after downgrading to OpenJDK 1.8.0 232 we've been hit by the same bug.
I got this error message in the console when I tried to run, I just switched laptops and I've wiped my old one. This project has always been stored in a USB so I use that to run it on my new laptop. (So I had to re-download all the applications), I need this to fix so bad due to its my project for class and I haven't record it and I'm supposed to do that and I don't want to fail the class please could u help thank u:
java.lang.NoClassDefFoundError: com/apple/eawt/QuitHandler
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3119)
at java.base/java.lang.Class.getMethodsRecursive(Class.java:3260)
at java.base/java.lang.Class.getMethod0(Class.java:3246)
at java.base/java.lang.Class.getMethod(Class.java:2065)
at processing.core.PApplet.runSketch(PApplet.java:10751)
at processing.core.PApplet.main(PApplet.java:10548)
at processing.core.PApplet.main(PApplet.java:10530)
at robothead.Robothead.main(Robothead.java:8)
Caused by: java.lang.ClassNotFoundException: com.apple.eawt.QuitHandler
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:190)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
... 9 more
I at first download JDK 10 and I read it only works with JDK 8 so I download that and delete JDK 10 in hopes that stuff will return back to normal and it does not works. Also the project, I did it in java oxygen and I downloaded photon on my new laptop and click on the yes I want to convert the files thing so I decided to make a new workspace and copy paste the code but still got that error?Before it was MacBook Air and I switch to the MacBook Pro.
You are mixing up a lot of things.
The basic problem is that starting with Java 9 oracle made changes that lead to such errors ( see https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-C86F7403-7D7C-456F-8873-18C7F1BEDE2F).
So, in order to get this to work, you have to ensure that Java 8 is used. And that your Java 10 installation was really, fully removed. You should then check your eclipse settings to also ensure that it is pointing to Java 8.
With InterClient 7.5.1 and 8.1.5, the creation of a new JDBC connection in Java 8 fails with
java.lang.NoClassDefFoundError: sun/io/ByteToCharConverter
This class seems to be referenced or used by the InterClient JDBC library.
The error does not occur with Java 7. Is there a way to work around this error?
This code reproduces the problem on Java 8:
package com.example.so25365952;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.logging.Level;
import java.util.logging.Logger;
public class Main {
interbase.interclient.Connection conn;
public static void main(String[] args) {
try {
Class.forName("interbase.interclient.Driver");
DriverManager.getConnection("jdbc:interbase://localhost/data/mydb.gdb", "sysdba", "password123");
} catch (ClassNotFoundException | SQLException ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
Output:
Exception in thread "main" java.lang.NoClassDefFoundError:
sun/io/ByteToCharConverter at
interbase.interclient.Connection.connect(Unknown Source) at
interbase.interclient.Connection.(Unknown Source) at
interbase.interclient.Driver.connect(Unknown Source) at
java.sql.DriverManager.getConnection(DriverManager.java:664) at
java.sql.DriverManager.getConnection(DriverManager.java:247) at
com.example.so25365952.Main.main(Main.java:14) Caused by:
java.lang.ClassNotFoundException: sun.io.ByteToCharConverter at
java.net.URLClassLoader$1.run(URLClassLoader.java:372) at
java.net.URLClassLoader$1.run(URLClassLoader.java:361) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:360) at
java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at
java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 6 more
Use db2jcc4.jar which is latest version. If you changed your mind to use Java 8 you need to use this.
I have the similiar problem and this change help me to fix the error.
The sun.* and sunw.* packages are internal and should not be used for exactly this reason. Seems like someone at InterClient screwed up. I'd advise you to contact them with a bug report, so they'll know to fix this for future releases.
If you can't wait for a future release, and are willing to break some licences (which I don't recommend of course). You may be able to create your own sun.io.ByteToCharConverter by copying the code from here, and adding it to the bootstrap classpath with -Xbootclasspath, but that would be a last resort.
sun.io.ByteToCharConvertor was deprecated in java 7. and it seems they remove it in java 8.
The answer to the question interbase.interclient.UnlicensedComponentException with the latest interclient.jar IB (v7.5.80) seems to work for me too. It suggests to use version 1.5 of the JDBC driver for Firebird. Fortunately this driver does not rely on deprecated sun classes and works with JRE 8.
I agree with Sergio, this is now an even older question! :-) But at my workplace, too, we are unfortunately as of 2018 for various reasons still using a super-old Interbase (v9, 2009). So at some point I too was unable to continue using the interclient.jar packaged with IBv9, because I would receive this same sun.io.ByteToCharConverter error. No doubt this was because the Java on my client machine was so much newer now. After all, it is 9 years later. But I did not want in my case to go with the solution of installing a legacy Java on my machine, as has worked for others.
So as a solution, on my client machine (Linux/Debian x64), I installed Interbase 2017, the latest at the time(*). But when installing, I only installed the IB Client (not Server + Client). The /opt/interbase/lib/interclient.jar that is packaged with the IB 2017 client works just fine now (no sun.io error). And yes, this IB 2017 (v13) interclient.jar works just fine connecting to our old IB 2009 server.
(I have to hand it to Embarcadero: They are still 'supporting' being able to connect to older versions -- at least in their interclient.jar and libgds.so. This makes sense as useful of course for those sysadmins who want to migrate from older systems to newer ones.)
(*) You can get a free trial version of Interbase from embarcadero. As far as I can tell, though, when you install it, if you install the Client only and use the interclient.jar, this does not require a license. Only installing the IB server (and depending on number of users/connections, etc) but that is nothing new to IB users/admins.
Works for us, at least, until we upgrade our server's IB version, or move to Firebird.
Hope this helps at least one other person out there.
This is an old question, but in case this helps someone:
Find the Java 7 rt.jar in the lib folder.
Open the file, and go to the folder sun/io.
Find the Java 8 rt.jar in the lib folder.
Open the file, and go to the folder sun/io.
Move all the .class files in the folder sun/io from the Java 7 to the Java 8 sun/io folder, except for Win32ErrorMode.class (this class was in both jar files).
Save the Java 8 rt.jar with the added classes.
This worked for me, using an old jdbc driver for SQL Server.
use
<!-- https://mvnrepository.com/artifact/com.ibm.db2.jcc/db2jcc -->
<dependency>
<groupId>com.ibm.db2.jcc</groupId>
<artifactId>db2jcc</artifactId>
<version>db2jcc4</version>
</dependency>
replace
<dependency>
<groupId>com.ibm.db2.jcc</groupId>
<artifactId>db2jcc</artifactId>
<version>10.1</version>
</dependency>
can Solve the problem