The GitHub Actions job "CI" on grails-core.git/spike/grails-beans-dsl has 
succeeded.
Run started by GitHub user codeconsole (triggered by codeconsole).

Head commit for run:
100b9dbf77d65a32cef2f1698113052fa9f59ac7 / Scott Murphy Heiberg 
<[email protected]>
Apply the configured Spring placeholder prefix

grails.spring.placeholder.prefix never took effect. The configurer bean
is a BeanFactoryPostProcessor, so its configuration class is created
during invokeBeanFactoryPostProcessors - before
AutowiredAnnotationBeanPostProcessor is registered - and the
@Value("${grails.spring.placeholder.prefix:#{null}}") field it read was
therefore always null, leaving GrailsPlaceholderConfigurer on the
default ${ prefix. Confirmed by reflection against a refreshed context:
the field held null and the configurer's placeholderPrefix stayed ${.

The bean is now contributed by a static factory method taking the
Environment and reading the property from it directly. A static @Bean
method is Spring's documented shape for a BeanFactoryPostProcessor
precisely because it needs no enclosing instance, and the Environment is
a resolvable dependency at that point in the lifecycle, so the prefix
arrives. It is also what Boot's own PropertyPlaceholderAutoConfiguration
does. The @Value field is gone; javap confirms the generated method is
public static and takes an Environment.

The two assertions this bug previously made impossible are restored in
CoreAutoConfigurationSpec - a configured prefix now resolves @{foo.bar},
and it displaces the default so ${foo.bar} is left literal - replacing
the test that pinned the broken behavior. Spring's Environment is
imported directly and grails.util.Environment aliased to
GrailsEnvironment in doWithSpring, matching UrlMappingsGrailsPlugin.

Report URL: https://github.com/apache/grails-core/actions/runs/30241743535

With regards,
GitHub Actions via GitBox

Reply via email to