Skip to content
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

Mybatis config error leads to endless loop, and no std error output [SPR-12397] #17005

Closed
spring-projects-issues opened this issue Oct 29, 2014 · 1 comment
Assignees
Labels
in: core type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 29, 2014

veggie opened SPR-12397 and commented

I have found an issue which kept spring looping during its initialization wihout any error messge printed on console.

The version of mybatis-spring I used is 1.2.2 along with spring 4.1.0.RELEASE.

I guess all typo errors in mybatis mapper xml files including mybatis-config.xml may cause this problem.

The error logs can be displayed only by setting log level to debug in AbstractBeanFactory class, but this is really an undesirable action because the log would be deluged with unwanted debuging logs from startup phase or web requests.

I wonder if there is a better way to solve this problem, or it's just designed this way.

In the attachment, the breakpoint will be repeatedly hitted as long as the loop exists, but all the exceptions were suppressed.

My team members and me have encountered this issue many times. Considering this is the time consuming mistake that anyone could easily make, I really want to know how to fix it. many thx


Affects: 4.1 GA

Attachments:

Issue Links:

  • #18406 Lot of undesired WARN logs after migration from Spring 3 to Spring 4

Referenced from: commits db2601d

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 30, 2014

Juergen Hoeller commented

Alright, I'm raising the log level to "warn" there.

That said, please note that this only happens for FactoryBean implementations that do not return a non-null type from their getObjectType() implementation, which is rare. In the case of the Mybatis MapperFactoryBean, the object type is getting determined through a customizable property which simply won't be set for early type checks. If the implementation would fall back to some base type, anything non-null, from getObjectType() when called early, you wouldn't run into this situation to begin with.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants