codeconsole commented on code in PR #16709: URL: https://github.com/apache/grails-core/pull/16709#discussion_r4342141492
########## grails-core/src/main/groovy/org/apache/grails/core/aot/GeneratedArtifactsAutowiredAnnotationBeanPostProcessor.java: ########## @@ -0,0 +1,75 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * https://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.grails.core.aot; + +import org.jspecify.annotations.Nullable; + +import org.springframework.beans.BeansException; +import org.springframework.beans.PropertyValues; +import org.springframework.beans.factory.BeanFactory; +import org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor; +import org.springframework.beans.factory.support.RootBeanDefinition; + +/** + * Injects through {@code @Autowired}, {@code @Value} and {@code @Inject} what the code generated ahead of time + * did not: an instance that code created only through the members its class adds to the type the definition + * names, and every other bean in full. + * + * @since 8.0.1 + * @see GeneratedBeanDefinitions + */ +public class GeneratedArtifactsAutowiredAnnotationBeanPostProcessor extends AutowiredAnnotationBeanPostProcessor { + + /** + * Spring's own, as the code was generated with: it finds the members that code injected, and injects in full + * another instance of a generated bean. + */ + private final AutowiredAnnotationBeanPostProcessor generatingProcessor = new AutowiredAnnotationBeanPostProcessor(); + + @Nullable + private BeanFactory beanFactory; + + @Override + public void setBeanFactory(BeanFactory beanFactory) { + super.setBeanFactory(beanFactory); + this.generatingProcessor.setBeanFactory(beanFactory); + this.beanFactory = beanFactory; + } + + @Override + public void postProcessMergedBeanDefinition(RootBeanDefinition beanDefinition, Class<?> beanType, String beanName) { + GeneratedBeanDefinitions.markMembersInjectedByGeneratedCode(beanDefinition, beanType, generatingProcessor); + super.postProcessMergedBeanDefinition(beanDefinition, beanType, beanName); + } + + @Override + public void resetBeanDefinition(String beanName) { + super.resetBeanDefinition(beanName); + generatingProcessor.resetBeanDefinition(beanName); + } + + @Override + public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) throws BeansException { + if (GeneratedBeanDefinitions.isAnotherInstanceOfGeneratedBean(beanFactory, beanName, bean)) { Review Comment: Fixed in 36bb2292ab. The autowired fallback now coordinates the way Spring does on a single definition: 1. It has Spring's common processor process a definition for the instance first, which registers the members the common processor injects. 2. It processes that same definition itself, so `checkConfigMembers` leaves a member annotated for both to the common processor. The regression is in `GeneratedArtifactsInjectionSpec`. A field and a non-setter method are each annotated `@Resource(name = 'named')` and `@Autowired`, and a second collaborator is marked primary. Before the fix, `configureBean` left the field holding the primary bean. Now the field and the method both get `named`, the method runs once, and the result matches a bean declared the ordinary way in the same context. A related problem is outside this PR. The instance the generated code itself creates gets the primary bean, and its method runs twice. That comes from Spring's code generation: both processors' `processAheadOfTime` use `getInjectedElements(...)` instead of the checked elements, so the generated code does both a resource lookup and an autowired resolution for such a member. I started the same generated code with no Grails processors registered, as a plain Spring Boot application on generated artifacts runs, and got the same result: `calls=[wire:2]` and the primary bean. So it's Spring Framework's behavior, and the processors here add nothing to it. I reproduced it with plain Spring Framework, with no Grails involved, on every line from 6.2.12 to 7.1.0-SNAPSHOT, and opened a fix there: spring-projects/spring-framework#37544. -- 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]
