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) |
Search before asking
Question
my pom:
4.0.0
The text was updated successfully, but these errors were encountered: