matrei commented on PR #15518: URL: https://github.com/apache/grails-core/pull/15518#issuecomment-4106346153
>> Does bean registration have to correlate with plugin load ordering, or can we let the features available for the Spring context handle that for us? @Conditional*, @Lazy, ObjectProvider<T> etc. > The existing architecture supports loading the beans in the order defined by the plugin load order. So yes. This is kind of muddled waters with modern Spring conventions. I think we moved some bean registration to `@Configuration` for a reason with Spring Boot 3, and this move decoupled bean registration from plugin load order. There may be workarounds we can put in place for 8 or 9 where we bring this back, but for 7 we are where we are. >>> The issue with the plugin is you can't load "before" that plugin since its beans, etc will be loaded prior, so we're only adding a plugin to show in the modules. >> What would be the use case for loading before dataBinding? > Does that matter? The issue is defining a plugin implies that one can load before/after it. This isn't supported currently. We have multiple other plugins in `grails-core` using `@AutoConfiguration` that suffer the same issue. If there is no use case to load before `dataBinding`, why break the convention? >> Is there a use case nowadays for having one plugin evict another? I see this as problematic in conjunction with @Configuration as beans will already be registered when eviction starts. Doesn't it make more sense to just remove the plugin dependency in the application. Maybe we can stop startup with a message if "evicted" (incompatible) plugins are on the classpath? > Isn't this debating the architecture of the plugins (I agree they need reworked). I'm just going for a consistent behavior. It was an open question. I don't have the answer, maybe someone else does. >> I don't see any plugin "traits" in grails-web-common. (I may be missing something) > That library defines a grails.factories file which is often shipped a long side plugins since it's used to populate GrailsArtifacts. I wouldn't consider this a plugin "trait" in an of itself. As you say, there are multiple modules having a `grails.factories` file. > I'm trying to understand why we would care that this is a plugin? In my mind: 1. It has historically been a plugin. 2. Keeping it consistent what a plugin is. -- 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]
