What exactly does fail in wildfly?
What fails is that the file.exists() method return false instead of true.
If I run the same code at command line (using the same jvm, probably not the same options) the methods return true but as soon as I'm in wildfly, the method return false.
In another OS and with the same JVM, I have not the same problem.
This cause my application to crash because of a file not exists exception...
I have perform more investigation :
- "security-manager-exists": "false",
- "file class name": "java.io.File",
- "query-path": "/applis/ortolang-bags/sldr000850/data/head/objects/§doc",
- "file.getAbsolutePath()": "/applis/ortolang-bags/sldr000850/data/head/objects/§doc",
- "file.exists()": "false",
- "file.getFreeSpace()": "0",
- "path.isAbsolute()": "true",
- "path.getFileSystem()": "sun.nio.fs.LinuxFileSystem@6d892bb2",
- "path.toFile().exists": "false",
- "Files.exists(path)": "true",
- "Files.notExists(path)": "false",
- "Files.getFileStore(path).name()": "/dev/mapper/data1-applis1",
- "Files.isDirectory(path)": "true",
- "Files.isRegularFile(path)": "false"
As you can see, files.exists() gives false whereas Files.exists(path) (using Path.get("/applis/ortolang-bags/sldr000850/data/head/objects/§doc")) gives true.
It seems that in wlidfly on SLES11 (I don't know why, maybe an underlying file management package library different) the Java.IO API does not works with § in filenames...
This is just a stab in the dark, but could this be an issue with AIO? With your OS and filesystem, AIO is enabled in WildFly. It is not used from a JSE application. You don't specify the "other" OS where the problem doesn't exist, but I'm guessing it's not Linux, so NIO is used instead.
I thought AIO was only used by HornetQ, but it may be used across all of WildFly. Uninstall libaio and try again to see whether the problem persists.
Well I still don't see where exactly WildFly comes involved in your problem.
You are using Java NIO and IO api which WildFly doesn't modify or intercept in any way.
That said, it is possible that there is a bug in JDK itself, it wouldn't be the first time on this subject.
Did you try using latest version of JDK as it could fix the problem. Also can you reproduce this on any other platform/ linux distro?
I've found the problem. Wildfly is not the problem but the environment which lunch wildfly.
LANG in wildfly in en_US.UTF-8 whereas when I lunch the program in a shell, I don't know why, but even in root using sudo specifying not keeping the user env, I still in fr_FR.UTF-8.
Java.IO is using the default charset and because § char is not compliant in the two charset, there is a mistake. Java.NIO does handle this correctly.
I'm very sorry for this, but my problem is a linux env problem in fact.
Thanks a lot for trying to help me, best regards, Jérôme.