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

When a bean definition is overridden, detect whether the definition has changed and log accordingly [SPR-7607] #12263

Closed
spring-issuemaster opened this Issue Sep 30, 2010 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Sep 30, 2010

Dale Wyttenbach opened SPR-7607 and commented

In a large configuration the 'Overriding bean definition' log message may be generated hundreds of times.
These messages are all generated with log level INFO from DefaultListableBeanFactory.
When you have a lot of these messages, deciding which of them require your attention can be quite a chore.
It would be helpful if beanDefinition.equals(oldBeanDefinition) were checked, and in the case where they are not equal, a different, more insistent WARN-level log message were generated.


Affects: 3.0.4

Attachments:

Issue Links:

  • #15434 Reconsider whether to generally allow bean overriding by name
  • #5845 Load files in only once

Referenced from: commits e7dde74

2 votes, 6 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Nov 23, 2010

Dale Wyttenbach commented

This is somewhat related to https://jira.springframework.org/browse/SPR-1142: "Load files in <import resource=.../> only once"
If #5845 were addressed, then the 'Overriding bean definition' log message wouldn't be generated so much.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 9, 2011

Dale Wyttenbach commented

A perl script you can run against log output that filters out those messages reporting replacement of a bean definition from an identical resource path.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Mar 25, 2015

Juergen Hoeller commented

I suppose we could simply log at debug level for equal bean definitions... since that won't have any real effect anyway. And therefore restrict the info level logging to non-equal bean definitions (which it was intended for).

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Mar 25, 2015

Paul commented

Isn't the real fix in the linked ticket? You say

I suppose we could simply log at debug level for equal bean definitions... since that won't have any real effect anyway

Since it won't have any effect, why take the time to overwrite them? We're currently running a patched version of spring-beans with a very similar patch to what is in the linked ticket. One context load time went from 2 minutes 28 seconds to 25 seconds - other applications were even more drastic. Moving to java config is the long term solution, and we're working towards that, but with a large codebase it takes time.

For what it's worth, we haven't had to change any application code with the switch to the patched jar. I understand java config is the long term solution, but I don't understand why Pivotal would leave the linked ticket open and give the impression to legacy XML users that Spring doesn't scale well...

Side note - are the people commenting on #13410 really having a problem with the linked issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment