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

[spring-projects-issues]

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:

• SPR-7607.pl (325 bytes)

Issue Links:

• Reconsider whether to generally allow bean overriding by name [SPR-10808] #15434 Reconsider whether to generally allow bean overriding by name
• Load files in <import resource=... /> only once [SPR-1142] #5845 Load files in only once

Referenced from: commits e7dde74

2 votes, 6 watchers

[spring-projects-issues]

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-projects-issues]

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-projects-issues]

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-projects-issues]

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?