jamesfredley commented on code in PR #15698:
URL: https://github.com/apache/grails-core/pull/15698#discussion_r3430118267
##########
grails-profiles/base/commands/run-app.groovy:
##########
@@ -125,6 +144,12 @@ catch(org.gradle.tooling.BuildCancelledException e) {
return true
}
catch(Throwable e) {
+ // A deliberate stop-app terminates the bootRun process, which surfaces
here as a build
+ // failure; report it as a clean shutdown rather than a startup failure.
+
if(org.grails.cli.gradle.RunningApplicationProcess.isStopRequested(buildDir)) {
Review Comment:
You're right that the TERM is the graceful path, and that's exactly what
`stop-app` does - `ProcessHandle.destroy()` sends `SIGTERM` on Unix, so the JVM
shutdown hooks and Spring's orderly shutdown run. The `run-app.stopping` marker
has nothing to do with *how* the app is shut down; it is purely a
message-classification hint for one narrow case.
Because `stop-app` terminates only the forked application JVM (not the
Gradle `bootRun` process), that build returns a non-zero child exit (e.g. 143).
A *foreground*, blocking `grails run-app` waiting on that build would otherwise
print "Failed to start server"; the marker lets it print "Application stopped"
instead. In interactive mode the marker isn't even needed - `run-app` returns
after the server is up, so it never reaches that catch.
I reworked this in 18dd33505e to make the intent unambiguous:
- The marker is now an empty, presence-only file (it previously stored an
unused `System.currentTimeMillis()`).
- The comments in `stop-app.groovy` and `RunningApplicationProcess` now
state explicitly that it is a foreground message classifier, not part of
shutdown.
If you'd still prefer to drop it entirely, I'm happy to - the only
consequence is that a *foreground* `grails run-app` (not interactive mode)
would print a benign Gradle build-failure line when stopped from another
terminal. Let me know which you prefer.
##########
grails-doc/src/en/ref/Command Line/stop-app.adoc:
##########
@@ -25,30 +25,34 @@ under the License.
=== Purpose
-Stops a running Grails application in an embedded servlet container.
+Stops a Grails application that was started with the
link:{commandLineRef}run-app.html[run-app] command.
-NOTE: This command will work in development mode only.
+NOTE: This command works in development mode only.
=== Examples
[source,groovy]
----
-grails stop-app
-grails stop-app --port=9090 --host=mywebsite
+$ grails
+grails> run-app
+grails> stop-app
----
+It can also be run as a separate invocation, including from a different
terminal than the one that started the application:
-=== Description
+[source,bash]
+----
+$ grails stop-app
+----
-Arguments:
+=== Description
+
-* `port` - Specifies the port which the Grails application is running on
(defaults to 8080 for HTTP or 8443 for HTTPS)
-* `host` - Specifies the host the Grails application is bound to
+Use `stop-app` to stop the application for the current project after it has
been started with `run-app`. The command can be run from interactive mode or as
a separate command from another terminal.
Review Comment:
Agreed - moved it to the upgrade notes in 18dd33505e. Added section "12.27
stop-app no longer uses JMX or the Actuator shutdown endpoint" to
`upgrading60x.adoc`, covering the removed `--host`/`--port` options, the
Windows best-effort shutdown, the new `build/run-app.pid` behavior, and the
default-build-directory constraint. The command reference no longer documents
the removed options - it now only describes current user-facing behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
