Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Backward compatibility: initDefaultStrategies() is no longer invoked on subclasses of "MessageListenerAdapter" [SPR-15043] #19609
Tl;dr - This comment more succinctly states the concern.
We have an extension of "MessageListenerAdapter" in a widely-shared component. That component doesn't work with Spring versions 4.1.0 and higher due to it no longer invoking "initDefaultStrategies()". As apps that use that component upgrade past Spring v4.0.9 they're experiencing breakages.
Before we patch around the issue I wanted to check with the Spring team to make sure that this change was a deliberate design evolution choice and not a mistake.
As you can see in this API analysis report v4.1.0 of library "spring-jms" removed the protected method "initDefaultStrategies()" from MessageListenerAdapter. This commit was made in support of delivering #14515 and made MessageListenerAdapter extend "AbstractAdaptableMessageListener" and moved the initDefaultStrategies() call to that class. So far so good / I don't think this commit is an issue. This later commit was made in support of
Neither of the Jira tickets appears to speak to an intentional change of this behavior. If it was intentional your response(s) to this ticket will serve to document for others the "why" behind this backward-incompatible change.
If this change wasn't intentional and you fix it in a later version of Spring that simplifies my process and my software as I can just enable controls to prevent people from using the versions that lack the necessary code.
This comment explains why I think this change was unintentional.
Referenced from: commits afe0228
1 votes, 4 watchers
Juergen Hoeller commented
Hmm, in that immediate commit, it was only intentional to get rid of it in the abstract base class. I missed that it was originally declared in the (old)
That said, the original reason for that
Couldn't you simply call your method implementation from your subclass constructor? Or embed the body of that method right into the constructor? I'd recommend that in general. That said, you have a point about backwards compatibility, so I don't mind re-introducing that callback either... but probably just in deprecated form.
Gordon Daugherty commented
My preference is to re-introduce the callback, mark it as deprecated, and I'll change my component as you described. This way those affected have time to eliminate their usage of "initDefaultStrategies" between now and when the deprecated behavior is removed (again).
If I had a smaller team and/or was only running into this is 10 places I'd just roll out a new shared component but our portfolio is large enough that it takes a while to get everything updated. Until we do that we'll have individuals upgrade Spring and encounter this issue. If we choose not to patch the compatibility issue they'll find this ticket while researching their unsuccessful upgrade and will probably be irritated that we didn't choose to fix the source of the problem.