I think it's probably an important book in the history of Software Engineering (not to be confused with CS). The book unfortunately spawned at much bad design as it did elegance.
If it's just a funny-looking giant-panda-family relative then it gets a different genus and we figure out how to save it. If it's a racoon-family relative we see how quickly we can hunt the thing into extinction.
In the end I think it's the modern form of detente that content providers are playing with Apple, the king of digital distribution -- sometimes I have to buy my wife crap that I don't want just so that she'll continue to sleep with me. It's a balancing act. How much will you put up with to get what you want. Apple wants it because content distribution keeps people buying their hardware. That's what they really want.
In the end Apple is a hardware company that only writes software or adds features to sell more hardware and maximize shareholder value. The display port is a nuisance, but they'd rather sell you an Apple TV to play your protected content from. Or a new cinema display. They'll skip the HDMI because it's expensive to license for laptops and cuts into their profit margins. Prices of iPods haven't dropped while the price of flash has plummeted. You get the picture. Meanwhile they have more cash in the bank than just about any other tech company out there.
There are lots of American-born CS people working in the cleared world, but that's about the only place you see them anymore.
1. that more men than women were willing to make the commitment in terms of time and flexibility demanded by high-powered jobs
2. that there were differences in the innate abilities of men and women (more specifically, men's higher variance in innate abilities or preferences relevant to science and engineering).
3. that the discrepancy was due to discrimination or socialization.
The feminist movement shouted him down as Harvard President, but never truly rebutted his arguments.
1.6/1.7 is completely a dumb argument to make, when there are far better ones.
Wow, someone who actually knows what they're talking about when posting here. That's kinda like someone RTFA.
Hibernate is good by me, though I've enjoyed using Kodo/BEA/EJB3.0 in the past for OR mapping as well. Even old school JDBC in session beans is often good enough for most things.
Personally I usually hate Spring IOC because all of the simple compile-time problems with typos and capitalization on imports turn into runtime configuration problems because those typos now exist in one of 500 random XML files (and the last one that you would think to look in). That and you often have a billion stupid interfaces with one and only one implementation class. Add to that NooB's who think everything has to be a session EJB with still another Facade EJB in front of it because they think Rod Johnson said it was supposed to be that way, and you realize that frameworks aren't necessarily going to make the architecture better, they just create more places for dumb developers to screw up (not that the original poster is doing that). Spring works well for developing a system that needs to support a lot of app server specific junk on multiple app servers (like LDAP single sign on stuff and JMX voodoo), multiple implementations of the same interfaces (like a product company writing client specific stuff), as well as for transaction management beyond pure JDBC transactions while running standalone JVM's outside of an app server. Almost no one needs that, so usually Spring is more hassle than it's worth. (particularly when trying to configure in Axis2 web services and other solutions that like to roll their own classloaders).
Good software engineers know which competing frameworks to use, when each is appropriate for the assigned task, when to forego a framework and roll your own. Good architects know all of that, plus when the developer is designing a Rolls Royce when a Toyota is appropriate, which frameworks play well together, which is appropriate for the developers on the team both present and future, as well as when architectural decisions should be made, because switching frameworks or architectural refactoring midstream becomes insanely expensive and wasteful. Bottom line -- code reuse in and of itself may make the coding easier to implement and maintain, but having a sound architecture appropriate to the project is even more important. Just using Spring, hibernate, struts, axis, GWT or whatever flavor-of-the-week framework is popular and throwing together some junit and canoo tests doesn't mean that your solution doesn't flat-out suck. If anything, the richness of frameworks borne of the maturity of a language requires more wisdom and discernment, not less.
As to the actual post itself -- It appears the dev isn't very familiar with the frameworks chosen, and needs to do a little digging in the mailing lists and doc. There's very few things that aren't possible with Spring/Hibernate with a little ingenuity. If the problems are with technical limitations of Spring Web Services such as WS-ReliableMessaging or WS-StandardOfTheWeek then use contract-first with Axis2. It's easy to swap it out.