DISQUS

I could not agree more.

There is no reason why you should bother programming in XML just to wire your system together. Although Spring might seem like a good fit here, you will most likely end up in a configuration nightmare caused y exposing spring-configuration files as part of your public interface.

The thing you are referring to Johannes as the module context is most likely the public API that you want to expose from your module. I have seen this quite a few other places as well. Although Spring framework classes like JdbcTemplate is a perfect example of a very good framework API, there is not reason why you should use spring to perform dependency injection when there is really no need to.

If you need to wire the dependencies between two modules A and B together, typically in web-application C, do it in java, create your own code to wire these dependencies together implementing a customized ApplicationContext intead of using spring.

I really wonder how we ended up in this mess. For years now, we laugh at code samples from the EJB era where we needed 10 lines of code just to invoke a stupid method on some java class using home/remote interfaces. Now when we see code fragments like:


<bean id="setSomeValueOnFoo" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetClass" value="Foo"/>
<property name="targetMethod" value="setBar"/>
<property name="arguments">
<list>
<value>baz</value>
</list>
</property>
</bean>



we say, "Wow cool, it works". I have very much respect for the creators of the spring-framework, and it provides excellent value when provided correctly. When it comes to dependency injection and XML, I really must say that I wonder how we ended up here....

Good writeup Johannes, what could be interestning as well is to add some practical examples related to common mistakes.

I often encounter the issue programs failing to establish a proper context in programs that raises exceptions.

Establishing such a context is trivial, but often omitted rendering the code much more difficult to debug. consider the following example of an instance method in an Account class:

public void validateAcount() {
if (isOverdrawn()) {
throw new IllegalStateException("Account is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
}

}

compared to the following version that has context (given a proper toString() implementation):

public void validateAcount() {
if (isOverdrawn()) {
throw new IllegalStateException("["+this+"] is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
}

}