jdaugherty commented on code in PR #16536:
URL: https://github.com/apache/grails-core/pull/16536#discussion_r4199897646


##########
grails-doc/src/en/guide/gettingStarted/runningAndDebuggingAnApplication.adoc:
##########
@@ -74,3 +74,189 @@ For debugging a Grails app, you have two options. You can 
either right-click on
 $ ./gradlew bootRun --debug-jvm
 
 For more information on the `bootRun` command, please refer to the 
link:{commandLineRef}bootRun.html[bootRun section of the Grails reference 
guide].
+
+[[startupProgress]]
+=== Watching the Application Start
+
+The `grails-startup-progress` module shows how far an application has got as 
it starts. Add it to the application's `build.gradle`, or select the 
`grails-startup-progress` feature when generating the application:
+
+[source,groovy]
+----
+dependencies {
+    implementation 'org.apache.grails:grails-startup-progress'
+}
+----
+
+With it, in development mode, which is the `development` environment run from 
the project directory as `./gradlew bootRun` does, Grails answers on the 
application's port as soon as the application begins to start, rather than 
leaving the port closed until the embedded server is ready. Opening the 
application in a browser while it starts shows a progress page with:
+
+* the stage the start has reached: preparing the application context, loading 
plugins and bean definitions, creating beans, starting the web server, and 
running plugin startup hooks and `BootStrap` classes
+* how many of the application's beans have been created, and which bean is 
being created now
+* the beans that have taken longest to create so far, not counting the beans 
they depend on, which is usually the quickest way to find out why a start is 
slow
+
+The page reloads the address it was opened at once the application is ready, 
which is after `BootStrap` has finished, not merely once the web server is 
listening. A browser that opens the application while `BootStrap` runs is shown 
the progress page too, rather than pages from an application that has not 
finished starting.
+
+Until the web server is listening, any request that is not for a web page, 
such as a call to a REST endpoint, gets a `503 Service Unavailable` response 
with a `Retry-After` header. Once it is listening, such requests reach the 
application as they always have, including requests the application makes to 
itself from `BootStrap`.
+
+If the start fails, the page shows the exception and its stack trace and stays 
open. Start the application again and the page follows the new start and 
reloads when it is ready.
+
+The stages, the beans, the exception and the Grails version are details of the 
application's internals, so the page shows them only to a browser signed in 
with the address the application logs as it starts:
+
+[source,console]
+----
+Startup progress is shown at http://localhost:8080/?grailsStartupToken=… until 
the application is ready
+----
+
+Opening that address once signs the browser in for as long as the application 
runs, through restarts by Spring Boot DevTools, and takes the token back out of 
the address bar. A browser opened by the application, as described below, is 
signed in already. Anyone else reaching the port sees only the progress bar: 
the details are left out of the page and out of its data, rather than hidden in 
them. The sign-in is a cookie, so it covers every tab of the browser that 
signed in. The token is made afresh each time the JVM starts and is only ever 
written to the log, so seeing the details takes the same access as reading the 
log.
+
+Until the embedded server takes the port over, the page is served by the HTTP 
server built into the JDK, so it changes nothing about how the application 
itself serves requests. In the interactive shell, `grails run-app` keeps 
waiting while the page holds the port, and stops waiting once the embedded 
server has taken the port over, as it does for an application without the 
module, so it does not wait for `BootStrap`. The page is not served when the 
application:
+
+* is deployed as a WAR to a servlet container
+* uses a random port (`server.port: 0`) or SSL
+* finds its port already in use, in which case the application fails to start 
exactly as it would without the page
+
+These settings control the page:
+
+[source,yaml]
+----
+grails:
+    startup:
+        progress:
+            enabled: false       # whether to serve the page; by default, only 
in development mode

Review Comment:
   Done: the three are shown commented out, with a sentence above the block 
saying they have no fixed default.



-- 
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]

Reply via email to