Tying app architecture to Spring DI is impossible. The principal philosophy of Spring is loose coupling (the opposite of “tying”). Have you ever seen a bean in a Spring-based app? They have no Spring classes whatsoever. They merely have properties whose types are app interfaces. These beans have no knowledge the outside world beyond the interfaces of the app services they require.
When making statements about “tying”, please stick to the aspects of Spring where this can actually occur: programmatic transaction management; use of Spring DAO templates and supports, etc. Also, remember that these are aspects purely optional, as is most everything in Spring.
Also, Spring XML config looks nice and complicated in your examples, but remember that most of those XML stanzas will occur only once (transaction manager definition, etc.). The overwhelming majority of XML stanzas that developers will add to a Spring XML config are stupidly simple:
<bean id="myService" class="mypackage.MyServiceImpl">
<property name="anotherService" ref="anotherService"/>
<property name="yetAnotherService" ref="yetAnotherService"/>
I also agree with the other posters that annotations in a bean is a half-baked way of accomplishing DI. Once you add an EJB3 specific annotation to your POJO, it’s not really a POJO anymore, is it? I don’t know enough about it, but why didn’t they design EJB3 similar to Spring. Couldn’t they have come up with a solution that included the flexabillity, lightness, and non-intrusive nature of Spring with the scalability and distributability (not a word) of EJB3?