6 comments

• 

  Bjørn Bjerkeli

  1 year ago

  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....
  reply
• 

  Per Spilling

  1 year ago

  Have you had a look at this?
  http://blog.interface21.com/main/2006/11/28/a-j...
  reply
• 

  Johannes Brodwall

  1 year ago

  Hi, Per
  
  Rod showed me the pure Java configuration about a year ago. Since we're still in the process of adopting Java 5, I have not used it yet, so I can't comment on it.
  
  But getting teams to stop using Spring XML will be a Good Thing. And the annotation based configuration could potentially help.
  reply
• 

  Kukenspeil

  1 year ago

  I completely agree. The whol project is a disaster and lots of it has to do with the complete clusterfuck of spring XML.
  reply
• 

  Christian Rørdam

  1 year ago

  I totally agree with you, Johannes and Bjørn. There is absolutely no reason why you should program in XML if you can do it in Java. I think there is a general misunderstanding among many people that separating the wiring code (or the business rules for that matter) from the rest of the code means that one should use a different format. Rubbish! Just put it in a separate place.
  
  I haven't tried the annotation style, but I don't like the idea, as it is intrusive. I think the best thing is to have a separate module/package with Java code that wires up the other modules.
  reply
• 

  Johannes Brodwall

  1 year ago

  Hi, Christian
  
  Thanks for the comment. I think your sentiments here are right on the money. XML (or DSLs, for that matter) is not the solution. I hope that new language features like annotations will make it easier to raise the abstraction level in Java, instead of trying to invent a new notation. For some things (e.g. @Transactional), annotations is probably the best solution, for other things, it can help make the wiring code more maintainable, but, like you say, it may not belong in the business logic.
  reply