[JBoss JIRA] (WFCORE-3843) Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3843:
----------------------------------------
Summary: Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used
Key: WFCORE-3843
URL: https://issues.jboss.org/browse/WFCORE-3843
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 5.0.0.Alpha7
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The legacy feature pack licenses.xml generation uses the maven-resources-plugin copy-resources goal to copy the core-feature-pack-licenses.xml file from a custom src location to a custom target location, and then runs the licenses-plugin insert-versions goal, using that target file as both an input and an output of that goal.
The problem is using the -Pjboss-release profile causes those executions to occur in a different order. With -Pjboss-release, the copy-resources happens after the insert-versions, removing all effect of the insert-versions.
There are a couple fixes that come to mind. One is moving the copy-resources from prepare-package phase to prepare-resources. The other is dropping the copy-resources altogether and just directly specifying the src file as the input to the insert-versions.
I think I'll go for the latter as the result seems simpler to understand in the future.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3842) Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3842:
----------------------------------------
Summary: Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used
Key: WFCORE-3842
URL: https://issues.jboss.org/browse/WFCORE-3842
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 5.0.0.Alpha7
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The legacy feature pack licenses.xml generation uses the maven-resources-plugin copy-resources goal to copy the core-feature-pack-licenses.xml file from a custom src location to a custom target location, and then runs the licenses-plugin insert-versions goal, using that target file as both an input and an output of that goal.
The problem is using the -Pjboss-release profile causes those executions to occur in a different order. With -Pjboss-release, the copy-resources happens after the insert-versions, removing all effect of the insert-versions.
There are a couple fixes that come to mind. One is moving the copy-resources from prepare-package phase to prepare-resources. The other is dropping the copy-resources altogether and just directly specifying the src file as the input to the insert-versions.
I think I'll go for the latter as the result seems simpler to understand in the future.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBEE-172) Unable to find unambiguous method: class java.lang.String.replace(java.lang.String, java.lang.String)
by Felipe Nisrallah Saab (JIRA)
[ https://issues.jboss.org/browse/JBEE-172?page=com.atlassian.jira.plugin.s... ]
Felipe Nisrallah Saab commented on JBEE-172:
--------------------------------------------
Fix made and merge requested: https://github.com/jboss/jboss-el-api_spec/pull/23
> Unable to find unambiguous method: class java.lang.String.replace(java.lang.String, java.lang.String)
> -----------------------------------------------------------------------------------------------------
>
> Key: JBEE-172
> URL: https://issues.jboss.org/browse/JBEE-172
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.7.Final
> Environment: Wildfly 10, Jdk 8
> Reporter: Ramesh khot
> Assignee: Scott Marlow
>
> I am using String.replace('-',' ') function inside jstl/core forEach tag but getting
> Unable to find unambiguous method: class java.lang.String.replace(java.lang.String, java.lang.String)
> at com.sun.faces.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:358)
> at com.sun.faces.facelets.tag.TagAttributeImpl.getValue(TagAttributeImpl.java:322)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.assignUniqueId(ComponentTagHandlerDelegateImpl.java:434)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. The same is true for service failure actions flag which is turned on by new service.bat when Windows service is installed (i.e. this flag is not installed by old service.bat but is required for service recovery actions to take place). (was: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. The same is true for service failure actions flag with is turned on by new service.bat when Windows service is installed (i.e. this flag is not installed by old service.bat but is required for service recovery actions to take place).)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. The same is true for service failure actions flag with is turned on by new service.bat when Windows service is installed (i.e. this flag is not installed by old service.bat but is required for service recovery actions to take place). (was: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. The same is true for service failure actions flag with is turned on by new service.bat when Windows service is installed (i.e. this flag is not installed by old service.bat but is required for this service recovery actions to take place).)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. The same is true for service failure actions flag with is turned on by new service.bat when Windows service is installed (i.e. this flag is not installed by old service.bat but is required for this service recovery actions to take place). (was: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat.)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. (was: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because new start parameter (additional environment variable - ISSERVICE) of Procrun is added in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat.)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because new start parameter (additional environment variable - ISSERVICE) of Procrun is added in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. (was: If [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] is taken as is then existing Windows service (installed before this change) needs to be reinstalled because new start parameter (additional environment variable - {{ISSERVICE}})of Procrun is added in new service.bat and {{ISSERVICE}} is required for correct transformation of exit code by modified domain.bat and standalone.bat.)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin... ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3293
Release Notes Text: If [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] is taken as is then existing Windows service (installed before this change) needs to be reinstalled because new start parameter (additional environment variable - {{ISSERVICE}})of Procrun is added in new service.bat and {{ISSERVICE}} is required for correct transformation of exit code by modified domain.bat and standalone.bat.
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
by Marat Abrarov (JIRA)
Marat Abrarov created WFLY-10362:
------------------------------------
Summary: Propagation of exit code to Windows Service Control Manager
Key: WFLY-10362
URL: https://issues.jboss.org/browse/WFLY-10362
Project: WildFly
Issue Type: Enhancement
Components: Scripts
Reporter: Marat Abrarov
I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939...] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
Below is the list of issues I found being the root cause:
# WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
{code}
exit /B my_exit_code
{code}
to return exit code to the caller always.
# Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=1...] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
# Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
I suggest to:
# Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
# Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=...], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
# Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months