codeconsole commented on code in PR #16094:
URL: https://github.com/apache/grails-core/pull/16094#discussion_r3781984527
##########
grails-core/src/main/groovy/grails/boot/config/GrailsAutoConfiguration.groovy:
##########
@@ -88,6 +96,29 @@ class GrailsAutoConfiguration implements
GrailsApplicationClass, ApplicationCont
return classes
}
+ /**
+ * The artefacts written down while the application's code was generated,
or {@code null} where
+ * nothing was written down and they are to be found the usual ways.
+ *
+ * <p>Both usual ways need something an image does not have: one walks the
classpath, the other
+ * reads a list the compile-time transform builds as it goes, which is
empty in anything the
+ * transform did not itself compile. So an image found no artefacts at
all, and an application
+ * could only start by naming its own -- a list to keep in step with
itself forever after.</p>
+ *
+ * <p>They were found while the code was generated, on an ordinary JVM
where both ways work, and
+ * left here.</p>
+ */
+ protected Collection<Class> artefactsWrittenDownAheadOfTime() {
Review Comment:
It is guaranteed on both paths, and now said so in the javadoc (b22be60):
- `GrailsEarlyPluginRegistrationPostProcessor.scanApplicationSource` calls
`setApplicationContext` on the instance it creates, before `classes()`.
- The `@Bean` method is invoked on this configuration class after Spring has
applied `ApplicationContextAware`.
It already had to hold before this PR: the scan branch of `classes()`
resolves through `new PathMatchingResourcePatternResolver(applicationContext)`,
so a null context would have failed there.
Also changed to read `getBeanFactory()` rather than
`getAutowireCapableBeanFactory()`, which refuses a context that has not been
refreshed — this is asked while the definitions are still being contributed,
which is why the classes are left as a singleton at all.
`GrailsAutoConfigurationArtefactsSpec` covers `classes()` rather than the
method behind it.
##########
grails-url-mappings/src/main/groovy/org/grails/plugins/web/mapping/UrlMappingsGrailsPlugin.groovy:
##########
@@ -155,6 +156,25 @@ class UrlMappingsGrailsPlugin extends Plugin {
}
}
+ /**
+ * Whether the mappings are to be reloadable, which decides how the holder
is defined.
+ *
+ * <p>Not while the code is being generated, whatever the machine
generating it looks like.
+ * Reloading swaps the mappings behind a proxy, and the proxy produces its
{@code UrlMappings}
+ * through a target source rather than declaring the type -- so Spring can
only learn what it
+ * produces by building it, which is exactly what reading a generated
definition avoids.
+ * Generated that way nothing could be autowired by that type, and the
application did not
+ * start. An image cannot reload anything in any case.</p>
+ */
+ protected boolean isReloadEnabled() {
Review Comment:
`grails.env=production`, set on the task by the Gradle plugin, is the
load-bearing one. The other two are gone in 1714f2b:
- The `AOT_PROCESSING` check here is redundant: with the environment already
not a reloading one it changes nothing. That check, the two seams it was
reached through and their tests are removed, and `UrlMappingsGrailsPlugin` is
byte-identical to the merge base again.
- The manual `systemProperty 'grails.env', 'production'` in
`grails-test-examples/aot` repeated what the plugin does; removed. The guide no
longer asks for it either, and the Limitations note in the description is stale.
Verified by removing each in turn and running
`:grails-test-examples-aot:check`.
The equivalent check in `GroovyPagesGrailsPlugin` is *not* redundant and
stays. `isDevelopmentEnvironmentAvailable()` asks whether `grails-app` is on
disk, which the environment does not change. Removing it does not fail the
build — it writes
```java
addPropertyValue("baseResource", "file:/home/build/app/")
```
into the generated definitions, which starts cleanly on the machine that
generated it and looks for its pages somewhere that exists nowhere else. There
is now a check on the example application's generated sources that fails the
build if anything writes a build path into them.
--
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]
