I was on site at a customer last week and a question came from the crowd, "Why isn't getConfigLocations() abstract anymore?" After working in front of customers for a while, it becomes rare that you're speechless, and yet I was. To be honest, my first thought was that there was no way the customer could be right. But lo and behold, in revision 1.3 of AbstractSingleSpringContextTests it clearly states that getConfigLocations() is no longer abstract. I hadn't created any new integration tests against 2.0.1, so I hadn't even seen the change.

Surprised by this, I put in an email to Juergen to find out what was up and this is what he had to say.

This change was for people who override "contextKey()" and "loadContext(Object)", obtaining some other form of ApplicationContext (not the default ClassPathXmlApplicationContext). In that case, "getConfigLocations()" doesn't make sense, since it is only relevant for the default implementation of "contextKey()". So anybody overriding those hooks had to provide an empty "getConfigLocations()" method, which was a bit silly... If we always wanted people to provide config locations, we shouldn't have exposed those protected "contextKey()" and "loadContext(Object)" methods in the first place.

So the short story is that you can still override the getConfigLocations() method the way you always have, you just won't have a reminder in the form of an abstract method.

A special thanks to Gregory Kick for bringing this up.