codeconsole commented on code in PR #16184:
URL: https://github.com/apache/grails-core/pull/16184#discussion_r3962836435
##########
grails-web-url-mappings/src/main/groovy/org/grails/web/mapping/DefaultLinkGenerator.groovy:
##########
@@ -76,7 +76,13 @@ class DefaultLinkGenerator implements LinkGenerator,
PluginManagerAware {
GrailsPluginManager pluginManager
- @Autowired
+ /**
+ * The mappings a link to a controller and action is created from. An
application that maps no
+ * URLs - one routing with Spring MVC, say - has none, and still generates
links to a resource
+ * or to a path, so this is the one kind of link it cannot generate rather
than a reason for it
+ * not to start.
+ */
+ @Autowired(required = false)
Review Comment:
Reverted in d9c95450a5: `@Autowired` is required again, the null check and
the `LinkGeneratorSpec` cases are gone, and `grails-web-url-mappings` is
identical to 8.0.x.
`GspAutoConfiguration` contributes `new DefaultUrlMappingsHolder([])` under
`@ConditionalOnMissingBean(name = "grailsUrlMappingsHolder")`, ordered after
`UrlMappingsAutoConfiguration` so a holder from there wins.
`grails-gsp-spring-boot` is only on a standalone application's classpath, so no
Grails application sees the bean. Covered by
`UrlMappingsHolderConfigurationSpec`, and the example application no longer
declares the holder itself.
##########
grails-gsp/grails-web-gsp-taglib/src/main/groovy/org/grails/web/pages/StandaloneTagLibraryLookup.java:
##########
@@ -39,7 +42,12 @@
* @author Lari Hotari
* @since 2.4.0
*/
-public class StandaloneTagLibraryLookup extends TagLibraryLookup implements
ApplicationListener<ContextRefreshedEvent> {
+public class StandaloneTagLibraryLookup extends TagLibraryLookup
+ implements SmartInitializingSingleton,
ApplicationListener<ContextRefreshedEvent> {
+
+ /** What {@link Artefact} marks a tag library with, the way a Grails
plugin declares one. */
+ private static final String TAG_LIB_ARTEFACT = "TagLib";
Review Comment:
Done in 3c8fe2eac2.
##########
grails-core/src/main/groovy/grails/boot/config/GrailsEarlyPluginRegistrationPostProcessor.java:
##########
@@ -120,6 +127,20 @@ public void
postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) t
return;
}
+ // Two things make a context a Grails application: GrailsApp launched
it, which it records by
+ // stashing the sources it was given, or one of its sources is a
Grails application class.
+ // This initializer is registered for every Spring Boot application
with grails-core on its
+ // class path, and the plugin lifecycle is not something the rest of
them asked for: it would
+ // contribute a GrailsApplication, a plugin manager and the beans of
every plugin found, over
+ // the top of whatever the libraries they did ask for auto-configure
for themselves.
+ boolean launchedByGrails =
+
applicationContext.getBeanFactory().getSingleton(APPLICATION_SOURCE_CLASSES_BEAN_NAME)
!= null;
+ Class<?>[] applicationSources =
resolveApplicationSourceClasses(registry);
+ if (!launchedByGrails &&
!containsApplicationClass(applicationSources)) {
Review Comment:
Javadoc updated in 99cf46fb57.
The `@SpringBootTest` case is documented rather than restored. The only
build-time marker separating a Grails application from a Boot application is
`META-INF/grails.build.info`, and `GrailsGradlePlugin` writes it for plugin
projects too — keying the gate off it would let any application with a Grails
plugin on its classpath back into the lifecycle, which is what the gate exists
to prevent.
The upgrade note now covers the case with its migration: name the
application class alongside the configuration, `@SpringBootTest(classes =
[Application, SomeConfig])`. `resolveApplicationSourceClasses` recovers a
`GrailsApplicationClass` from the registry, so that context is a Grails
application again; `EarlyPluginRegistrationOrderingSpec` covers that path. If
you would rather restore the behaviour instead, say so and I will look for
another signal.
--
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]
