[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-398:
-------------------------------
Description:
*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.
||OS||Daemon version (built with)||Java vendor and version (built
with)||Result||
|Windows 7|1.1.x HEAD (9.00)|AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2008R2 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2012R2|1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.2+9 (12.00)|OK|
|Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|Fail|
Note: It is assumed the OS is fully patched unless otherwise stated.
was:
*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.
> 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.
> ||OS||Daemon version (built with)||Java vendor and version (built
> with)||Result||
> |Windows 7|1.1.x HEAD (9.00)|AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2008R2 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2012R2|1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.2+9 (12.00)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|Fail|
> Note: It is assumed the OS is fully patched unless otherwise stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
