[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerwin reopened DAEMON-398:
---------------------------
I tried with [AdoptOpenJDK
11.0.2+9|https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmVariant=hotspot]
and there it works fine.
{code:none}
C:\>dumpbin /headers "c:\Program
Files\Java\adoptopenjdk11.0.2_9\bin\server\jvm.dll"
Microsoft (R) COFF/PE Dumper Version 14.16.27027.1
Copyright (C) Microsoft Corporation. All rights reserved.
OPTIONAL HEADER VALUES
12.00 linker version
{code}
It is compiled with Visual Studio 2013
([ref|http://mariusbancila.ro/blog/2015/08/12/version-history-of-vc-mfc-and-atl/]).
I tried with [AdoptOpenJDK
11.0.3+7|https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmVariant=hotspot]
and there it is broken again.
{code:none}
C:\>dumpbin /headers "C:\Program
Files\Java\adoptopenjdk11.0.3_7\bin\server\jvm.dll"
OPTIONAL HEADER VALUES
14.15 linker version
{code}
They seem to have upgraded their build environment, because this is compiled
with Visual Studio 2017 15.8.
Apart from that, Oracle JDK 11 (both openjdk.java.net and commercial) is
compiled with Visual Studio 2017 15.5.
I assume the Oracle binaries are also supported by commons-daemon.
> Java 11 jvm.dll startup error messages not available on stdout/stderr
> ---------------------------------------------------------------------
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
> Affects Versions: 1.1.1
> Environment: Windows
> Reporter: Gerwin
> Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
