[ https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831564#comment-16831564 ]
Mark Thomas commented on DAEMON-396: ------------------------------------ Tomee appears to be using the (renamed) Windows binary provided by the Commons Daemon project. It is version 1.0.14. I have tested with the latest release (1.1.0) and I am unable to recreate the first of the issues. java.library.path is correctly set with both Java 8 and Java 11. > LibraryPath is broken for Java 11 > --------------------------------- > > Key: DAEMON-396 > URL: https://issues.apache.org/jira/browse/DAEMON-396 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Affects Versions: 1.1.1 > Reporter: Gerwin > Priority: Critical > Attachments: JAVA_HOME-bin-to-PATH.patch, apxAddToPathW.patch > > > My application which runs on TomEE is broken when running on Java 11. I'm > getting this error: > {code:none} > java.lang.UnsatisfiedLinkError: no xmlForJava in java.library.path: > [C:\Program Files\TomEE\bin, <<more paths here>>, .] > at > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829) > at java.base/java.lang.System.loadLibrary(System.java:1867) > {code} > It works for Java 8 and 10, but fails for both Oracle JDK 11 and OpenJDK 11. > The application installs the service with the {{--LibraryPath}} option and > {{--StartMode jvm}}. When inspecting the {{java.library.path}} using JMX, I > observe this: > # With Java 8 {{java.library.path}} contains the value specified in the > LibraryPath > # With Java 11 {{java.library.path}} contains the value of the PATH > environment variable > From the sourcecode I see that procrun is executing code in this order: > {code:none} > _wputenv("PATH=;C:\\application\\lib"); > LoadLibraryW("jvm.dll") > JNI_CreateJavaVM() > SetDllDirectoryW(";C:\\application\\lib") > {code} > The JVM is supposed to take the value of the PATH variable into account when > loaded, but it doesn't. > I found these articles: > * Stackoverflow: [Program uses outdated (not current) env variable > value|https://stackoverflow.com/questions/9634905/program-uses-outdated-not-current-env-variable-value] > * Microsoft Docs: [Potential Errors Passing CRT Objects Across DLL > Boundaries#This example passes environment variables across a DLL > boundary|https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2017#example-1] > So the C-Runtime library has its own copy of the environment variables and > behavior depends on how the binaries are compiled. > * /MD means they share a single copy of the C-Runtime library. > * /MT means that they use separate copies of the C-Runtime library. > I expect that Java 11 is build differently, which causes this bug. > Give this quote... > {quote} > Normally when Java is launched and a library path is not specified, the JVM > will default to using the system PATH on Windows and the LD_LIBRARY_PATH on > UNIX systems to locate any native libraries loaded by the application. This > is akin to what happens with the CLASSPATH environment variable when a > specific classpath is not specified when launching the JVM. The use of the > CLASSPATH environment variable has fallen out of style because of all the > conflict problems which can arise when multiple Java applications are > installed on the same machine. The same issues are all there with the library > path as well. > In general, it is advised that you avoid potential problems when your > application is deployed by being conservative about which directories will be > included in the Java library path. > https://wrapper.tanukisoftware.com/doc/english/prop-java-library-path-append-system-path.html > {quote} > .. I think it would be better to change the implementation of > {{--LibraryPath}} to set the JVM option {{-Djava.library.path}} instead of > the PATH env var. > This will make procrun independent of how the jvm.dll is build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)