Thanks for posting this. I'm curious if anyone on the list has concerns about the .bat scripts now delegating the powershell ones. The advantages are obvious; the disadvantages I really don't know. I only occasionally use Windows in a VM, so I haven't really kept up with what is supported in what versions of Windows. I know Powershell has been around a long, long time. On 9/29/15 10:29 AM, Tomaž Cerar wrote: > Hey guys, > > > just heads up, I've managed to prepare[1] all powershell scripts to > replace the aging .bat ones. > > New scripts unify most of the shared "code" that all scripts use by > including common.ps1, > and each script only has the code that differs from common behavior they > all share. > > As result of move we now have much more reliable and faster scripts that > share common code, > which helps with maintaining a lot. > > New scripts (domain.ps1 & standalone.ps1) now support --background (also > controllable via .conf.ps1) > option that runs the process in background and remembers its pid and as > such add support for > feature that until now was only in *nix version of scripts. > > I would like to propose this PR for inclusion to WildFly 10. As it > doesn't alter any existing behavior > but just adds & improve the script experience on Windows. > > As we get to test and verify that new scripts don't break/include any > currently available option/action > I would also like to remove the batch scripts[2], so they would just do > call out to their .ps1 counter parts. > > Once this scripts get merged, I will send PR to also add PS scripts for > WildFly full defined scripts, > given that most of the functionally is already in "common.ps1" new > scripts will be just simple 5 liners [3] > > > -- > tomaz > > > [1] https://github.com/wildfly/wildfly-core/pull/1118 > [2] https://github.com/wildfly/wildfly-core/pull/1126 > [3] > https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Hum, it will break my NetBeans plugin as I rely on the shell scripts ;) I can easily fix this but I vote against removing the bat files this late in the release process.

The one concern I do have is with the --background bit. We do create a PID file for the LAUNCH_IN_BACKGROUND, but it doesn't make sense to me why we do. That's off topic for this though :) We don't seem to use these files for anything so I just don't see the point in creating them. Anyway, the whole PID thing I think needs to be thought about. With the current behavior in the bash scripts it doesn't exit until the background process has been stopped. I can't really tell what the PS scripts do with the launch in background. Does the script exit or pause until the process is exited?

On 29 Sep 2015, at 18:08, Emmanuel Hugonnet wrote: > Hum, it will break my NetBeans plugin as I rely on the shell scripts ;) interesting - all my attempts on using the shell scripts ended with misery since they resulted in not being able to reliably stop/start the server since we don't get the chance to signal the process to die/stop. Any info on how you worked around that in Netbeans ? /max > I can easily fix this but I vote against removing the bat files this late in the release process. > My 2 cents > Emmanuel > > > Le 29/09/2015 17:48, Brian Stansberry a écrit : >> Thanks for posting this. >> >> I'm curious if anyone on the list has concerns about the .bat scripts >> now delegating the powershell ones. The advantages are obvious; the >> disadvantages I really don't know. >> >> I only occasionally use Windows in a VM, so I haven't really kept up >> with what is supported in what versions of Windows. I know Powershell >> has been around a long, long time. >> >> On 9/29/15 10:29 AM, Tomaž Cerar wrote: >>> Hey guys, >>> >>> >>> just heads up, I've managed to prepare[1] all powershell scripts to >>> replace the aging .bat ones. >>> >>> New scripts unify most of the shared "code" that all scripts use by >>> including common.ps1, >>> and each script only has the code that differs from common behavior they >>> all share. >>> >>> As result of move we now have much more reliable and faster scripts that >>> share common code, >>> which helps with maintaining a lot. >>> >>> New scripts (domain.ps1 & standalone.ps1) now support --background (also >>> controllable via .conf.ps1) >>> option that runs the process in background and remembers its pid and as >>> such add support for >>> feature that until now was only in *nix version of scripts. >>> >>> I would like to propose this PR for inclusion to WildFly 10. As it >>> doesn't alter any existing behavior >>> but just adds & improve the script experience on Windows. >>> >>> As we get to test and verify that new scripts don't break/include any >>> currently available option/action >>> I would also like to remove the batch scripts[2], so they would just do >>> call out to their .ps1 counter parts. >>> >>> Once this scripts get merged, I will send PR to also add PS scripts for >>> WildFly full defined scripts, >>> given that most of the functionally is already in "common.ps1" new >>> scripts will be just simple 5 liners [3] >>> >>> >>> -- >>> tomaz >>> >>> >>> [1] https://github.com/wildfly/wildfly-core/pull/1118 >>> [2] https://github.com/wildfly/wildfly-core/pull/1126 >>> [3] >>> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev /max http://about.me/maxandersen

On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet <ehugonne(a)redhat.com <mailto:ehugonne@redhat.com>> wrote: To stop the process : first I try the management API command then I have some funky code from arquillian (iirc) which kills the jboss-modules processes. you probably mean https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/sr... Great thing it works for you :) This was written by Stuart & me over some discussion in Brno F2F as an optional feature that we would use in testsuite for our CI as we had problems with hanging processes. But it ended up not really useful... -- tomaz

Right this is my concern. The behavior is different as the bash scripts don't exit. They wait for the process to end. Maybe it's correct to be different, I don't know.

Yes ;) Well I don't test much on Windows but it works just nice on Linux ;-)

Le 30/09/2015 15:05, Tomaž Cerar a écrit : > > On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet > <ehugonne(a)redhat.com <mailto:ehugonne@redhat.com>> wrote: > > To stop the process : first I try the management API command then I > have some funky code from arquillian (iirc) which kills the > jboss-modules processes. > > > > you probably mean > https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/sr... > Great thing it works for you :) > This was written by Stuart & me over some discussion in Brno F2F as > an optional feature that we would use in testsuite for our CI > as we had problems with hanging processes. > But it ended up not really useful... > > -- > tomaz > >

> Right this is my concern. The behavior is different as the bash > scripts don't exit. They wait for the process to end. Maybe it's > correct to be different, I don't know. If you send signal 10 (kill -l 10 returns USR1) AS got restarted thanks while loop - https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... and it doesn't matter if you execute it normally or with LAUNCH_JBOSS_IN_BACKGROUND don't know what the real use case is to get it restarted

wildfly-init-redhat.sh and wildfly-init-debian.sh do restart by stop&&start restart) $0 stop $0 start EAP 6.4.3 RPM init.d script does stop&&start too restart|reload) stop sleep 3 start RETVAL=$? ;; There is some magic in the .sh scripts with number 128 and it's related wait command / bash / signals http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html#sect_12_02_02 http://veithen.github.io/2014/11/16/sigterm-propagation.html > > Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much > implemented > to satisfy the init.d script we have and is not really useful if you run it > directly. it is used in: https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... read kpid < $JBOSS_PIDFILE in stop function > If that is really so, I am not a fan of having that in standalone.sh > directly... > domain.sh has the same mechanism LAUNCH_JBOSS_IN_BACKGROUND + JBOSS_PIDFILE If it's removed from both files something will have to be added to the init/systemd scripts. Cheers. Rostislav _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hey guys, just heads up, I've managed to prepare[1] all powershell scripts to replace the aging .bat ones. New scripts unify most of the shared "code" that all scripts use by including common.ps1, and each script only has the code that differs from common behavior they all share. As result of move we now have much more reliable and faster scripts that share common code, which helps with maintaining a lot. New scripts (domain.ps1 & standalone.ps1) now support --background (also controllable via .conf.ps1) option that runs the process in background and remembers its pid and as such add support for feature that until now was only in *nix version of scripts. I would like to propose this PR for inclusion to WildFly 10. As it doesn't alter any existing behavior but just adds & improve the script experience on Windows. As we get to test and verify that new scripts don't break/include any currently available option/action I would also like to remove the batch scripts[2], so they would just do call out to their .ps1 counter parts. Once this scripts get merged, I will send PR to also add PS scripts for WildFly full defined scripts, given that most of the functionally is already in "common.ps1" new scripts will be just simple 5 liners [3] -- tomaz [1] https://github.com/wildfly/wildfly-core/pull/1118 [2] https://github.com/wildfly/wildfly-core/pull/1126 [3] https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev