gsartori opened a new issue, #16461: URL: https://github.com/apache/grails-core/issues/16461
### Expected Behavior # Spring Security adds a long pause during application startup ## Environment * **Grails:** 8.0.0-RC1 * **Spring Boot:** 4.1.1 * **Spring Framework:** 7.0.9 * **Java:** 25.0.4.1 * **Profile:** `development` ## Observed behavior Startup pauses for several seconds after these messages: ```text Configuring Spring Security Core ... ... finished configuring Spring Security Core Configuring Spring Security LDAP ... ... finished configuring Spring Security LDAP ``` In a baseline run, the first datasource initialization log appeared about **8.4 seconds** after the application startup log. Spring Boot reported a total startup time of **11.849 seconds**. Disabling all Spring Security removes the pause. Disabling LDAP alone does not, suggesting that the delay is associated with **Spring Security Core** or work it triggers later in Spring context initialization. ## Investigation The plugin configuration itself does not appear to account for the delay. * `doWithSpring()` took about **76 ms** for Spring Security Core. * `doWithSpring()` took **less than 1 ms** for LDAP. A temporary bean timing probe recorded **587 beans**. The slowest intervals were mostly Grails and framework initialization: * `servletContainer`: about **2.45 s** * Grails URL mapping and Hibernate metadata bean chain: about **2.3–2.4 s** * `grailsSimpAnnotationMethodMessageHandler`: about **0.91 s** * `groovyPagesTemplateEngine`: about **0.55 s** * `gspTagLibraryLookup`: about **0.54 s** > These bean intervals include dependency creation and overlap, so they must **not** be added together. Individual Spring Security beans were comparatively fast: * Authentication filter: about **31 ms** * LDAP authentication provider: about **16 ms** * LDAP authenticator: about **8 ms** * LDAP context source: about **6 ms** No LDAP network wait was observed during startup. JFR evidence showed activity around: * Spring bean pre-instantiation * `EventListenerMethodProcessor` / `AnnotationsScanner` * Class loading * Grails/Hibernate metadata initialization This suggests that the pause occurs during **broader application-context initialization** rather than in the plugin's printed configuration methods, but the exact blocking call has not yet been identified. ## Configuration comparison The controller annotations were replaced with a centralized `InterceptUrlMap` containing equivalent role rules. This did **not** materially improve startup. ### Before the change * **Total startup time:** 11.849 s * **Application startup → first datasource initialization:** about 8.405 s ### With the final URL-map configuration * **Total startup time:** 11.812 s * **Application startup → first datasource initialization:** about 8.349 s Other post-change runs ranged from **11.997 s to 12.366 s** total. The small difference is within run-to-run variation. The pause remains at about **8.4 seconds**. ## Current assessment Spring Security is **correlated with the delay**, but no individual Spring Security bean or Core/LDAP configuration method accounts for several seconds. The evidence points to initialization work **triggered or made eager when Spring Security is enabled**. Further profiling is needed to identify the exact call or bean factory phase responsible. ### Actual Behaviour _No response_ ### Steps To Reproduce _No response_ ### Environment Information _No response_ ### Example Application _No response_ ### Version Grails 8.0.0-RC1 -- 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]
