-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BeanPostProcessorChecker] WARN o.s.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker #1236
Comments
Hi, Can you please follow what's in https://github.com/apache/shiro/tree/main/samples/spring-boot-3-web sample? |
run the sample/spring-boot-3-web,Warning still exists chang to spring boot 3.2.0
the pom is: |
use spring boot 3.1.5 also show the message info:
|
Thank you for your detailed explanation. There is something indeed new in how SpringBoot 3 initializes beans. Thank you! |
Found some prior discussions about this https://issues.apache.org/jira/browse/SHIRO-743 and spring-projects/spring-boot#16097 Looks like this is a long-standing issue, if any Spring experts want to take it on... please do! |
Thank you for your reply, shiro hava a Improvement, have plan to fix? |
No plan, we need help with this from the community. |
ok, thanks |
Reopened since this is a real issue |
@joshlong Would you know of someone who can help Shiro with this issue? |
It's based on this issue: |
Thanks @rasa-app I have tried to create a PR, but still I cannot get rid of the warnings unfortunately. |
Not stale |
I recently attempted to integrate Shiro in Spring-Boot 3.2.5 and it seemed to run normally at the time so I didn't pay much attention, but I noticed these warnings too. If you want to reproduce it, you might check out the demo I originally wrote:https://github.com/SilenceLurker/shiro-test |
Shiro team needs help on this. None of us are Spring experts that can deduce what's going on here. |
I will spend some time trying to resolve this, but I cannot guarantee a solution. These warnings don't seem to have caused any project failures or functional abnormalities during my testing, so I think many others might have this issue but don't pay much attention to it. That demo might provide some ideas or something else to others, so let's just leave it there. |
Thank you! We appreciate any help we get here. |
@SilenceLurker Shiro no longer uses JIRA for issue tracking so you don’t need to create the JIRA account |
Got it, and, based on my recent attempts, I suspect that the issue might be related to Spring-Boot3 using the Spring6 framework, whereas Spring-Boot2 uses the Spring5 framework. It seems that the RMI functionality has been removed (I noticed that the content is relatively simple and could potentially be manually added back in to temporarily resolve this issue). Additionally, the compatibility of Spring-Boot3 with Spring-Boot2 doesn't seem to be ideal, especially for parts that rely on the Spring5 framework. My current approach is to create a version of Shiro for Spring-Boot3 and replace the internal javax dependencies with jakarta dependencies (Spring-Boot2 uses javax, while in Spring-Boot3, it has been changed to Jakarta). This might solve the issue. I'm still trying and not sure if it will work, but adding a version specifically for Spring-Boot3 would be more user-friendly for those developing with Spring-Boot3 (so they don't have to manually exclude javax dependencies one by one). I believe that creating an additional version to support Spring-Boot3 is simpler than trying to make the existing shiro-spring-boot support both Spring-Boot2 and 3.(Translated by GPT4o) |
Shiro uses |
It seems that I initially found a tutorial that wasn't very good, which involved manually removing javax related dependencies one by one when importing dependencies. I will look further to find the source of the issue.(Translated by GPT4o) |
Thank you. See https://shiro.apache.org/jakarta-ee.html especially the BOM section. That automatically removes javax dependencies |
I am not sure if this is the issue, but I noticed that ShiroFilterFactoryBean implements both FactoryBean and BeanPostProcessor interfaces. This could be the cause. However, I have not tried separating them into two classes, each implementing one of the interfaces. In terms of the Spring lifecycle, the order seems to be FactoryBean -> Bean -> BeanPostProcessor. Implementing both might cause issues. The FactoryBean documentation suggests that the implementation class should not be used as a normal bean ("NB: A bean that implements this interface cannot be used as a normal bean. A FactoryBean is defined in a bean style, but the object exposed for bean references (getObject()) is always the object that it creates."). This suggests that users should not manually create beans for its implementing class. While debugging in the Spring-Boot 2 environment, I noticed similar issues in the call stack, but Spring-Boot 2 seems less strict in its checks compared to Spring-Boot 3, hence no warnings. However, customizing a ShiroFilterFactoryBean or AuthorizationAttributeSourceAdvisor may still trigger these warnings in Spring-Boot 2 (with the former being more severe).(Translated by GPT4o) |
Maybe... can you see if separating it has any effect? |
I have already started trying to do this, but it seems to be more complex than I initially thought. I might need two to three days, or even longer, to handle it to ensure compatibility with the existing content as much as possible.(Translated by GPT4o) |
I haven't successfully completely separated them yet. I'm stuck on some tests, but I wrote another example to try it out and confirmed that the issue is indeed caused by simultaneously implementing both the FactoryBean and BeanPostProcessor interfaces and registering them as Beans in the Configuration(Try running this minimal reproduction project, and you will see similar warnings, just in a smaller number: https://github.com/SilenceLurker/BeanWarningExample). I believe the simplest solution to resolve these warnings is to split the original ShiroFilterFactoryBean class. I will try to separate them simply for a while longer, but if it takes too long, I will consider redesigning this part based on the original functionality.(Translated by GPT4o) |
Good news and bad news: The good news is that by separating the implementation of ShiroFilterFactoryBean for FactoryBean and BeanPostProcessor, and injecting a shared instance of an additional entity class into both, we can eliminate these warnings without changing the original functionality. This approach requires resetting the test cases by configuring the original Map into the newly created entity class for storing corresponding information and injecting this entity into the FactoryBean (ShiroFilterFactoryBean) and the BeanPostProcessor implementations. This issue took me a considerable amount of time to resolve. However, the downside is that when users configure ShiroFilterFactoryBean, the Bean created in the Configuration will no longer be ShiroFilterFactoryBean but the newly created entity class (which will be automatically injected into the FactoryBean and BeanPostProcessor implementations via @Autowired). In my tests, this setup appears to function correctly without generating warnings (though I haven't conducted exhaustive testing because I am busy with my graduation project). Unfortunately, if users try to create a Bean of AuthorizationAttributeSourceAdvisor in the Configuration class, warnings still appear. I haven't found the cause of this issue yet. Does anyone have any ideas?(Translated by GPT4o) |
It seems that the implementation class of BeanPostProcessor should not be instantiated as a bean in a Configuration class. If the BeanPostProcessor is annotated with Component and handled automatically by Spring Boot, the corresponding warnings tend not to appear. However, in a simple Spring Boot project containing only one Configuration class with a single BeanPostProcessor bean, similar warnings can still emerge, although they are relatively few in an empty project. Whether a similar issue exists in AuthorizationAttributeSourceAdvisor has not yet been explored.(Translated by GPT4) |
Based on the content above, it may not be necessary to separate the original implementations. Instead, simply modifying them to be managed via the Component annotation might suffice. However, additional adjustments might be needed in the AutoConfigure settings to ensure these components are properly scanned and injected. Likely, an additional class will be required to store the relevant filter information. This way, users only need to use a Configuration class to configure and inject a new information class bean into ShiroFilterFactoryBean, without needing to configure ShiroFilterFactoryBean itself as a bean.(Translated by GPT4) |
At present, the dependency has not been resolved, and I have also encountered this issue |
Search before asking
Question
my pom:
4.0.0
The text was updated successfully, but these errors were encountered: