[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-396.
--------------------------------
Resolution: Fixed
Problem 1 is a variation of DAEMON-401 and has been fixed in a similar way.
> LibraryPath is broken for Java 11 using Windows 10/2016
> -------------------------------------------------------
>
> 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 with
> Windows 10/2016. 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)
