[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834893#comment-16834893
]
Mark Thomas commented on DAEMON-398:
------------------------------------
I was using Windows 7.
I think it would be useful to add a table to the issue description to track
which combinations work and which do not. That should help us track down
exactly where the problem lies. I'll get something set-up. Help populating it
would be much appreciated. I'm not looking to populate all possible
combinations - just enough to figure out where we should be looking for a root
cause.
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> -------------------------------------------------------------------------------------------------------
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> 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)
