[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834786#comment-16834786
]
Gerwin commented on DAEMON-396:
-------------------------------
bq. 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.
Which JDK binaries did you use? I just figured out that AdoptOpenJDK 11.0.2 is
compiled with VS2013, and that will work.
But Oracle binaries (both openjdk.java.net and commercial) and AdoptOpenJDK
11.0.3 are compiled with VS2017. And then it is broken.
bq. I'm not a fan of the solution to the first problem as it tends (always?)
adds a dependency on one of the .Net runtimes which aren't always installed.
Alternative is to redistribute the dependencies (e.g. msvcp140.dll) with
commons-daemon. Tomcat and OpenJDK are doing this too.
> 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.0
> Reporter: Gerwin
> Priority: Critical
> Fix For: 1.1.1
>
> 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)
