I am working on the source tree of several other folks. While some key folks were away on vacation, it became necessary to change the db login password. No biggie; just find the environment file and change it. Right?
Not quite. Each application under the main tree has its own config directory with Spring, Hibernate and properties files, all with their own copy of the login information. Of course, the same set of files appears in every branch as well. After a few trial and error you-gotta-be-kidding-me's, I finally would up grepping, checking out, editing, checking in many dozens of property, Hibernate, Spring and shell script files to get it done in time for an overdue delivery.
Then I went about creating a central environment file, and by some slight-of-hand coding, calls to sqlplus, Hibernate and Spring would implicitly get rerouted to something that went to the central file to grab the password.
Aside: it turns out that the only thing we use Hibernate for is to implicitly convert between objects and db-rows, and the only thing we use Spring for is to specify which classes to load. And, this is the kicker, all the code that uses it is auto-generated. In other words, they dragged in the overhead of both the Spring and Hibernate frameworks, and got absolutely none of the potential benefits (all the db un/marshalling could have been auto-generated from our dictionary as well, and specifying which class to load could have been a simple environment variable).