Spring: @Autowired Constructors

Since the introduction of Spring 2.0, I have seen a trend where developers use the @Autowired annotation very often. I must admit, I like a combination of annotations with some XML declaration, however I'm still debating whether making a decision of using @Autowired scales well in the long run. I would like to show how this feature can seem unintuitive.  Furthermore, even tools like SpringSource Tool Suite can get confused at times.

Spring 3.0 and <mvc:annotation-driven />

I have used Struts1 and Struts2 extensively for years.  With that background, I can appreciate some of the things that Spring-MVC brings to the table such as Dependency Injection, clean integration with Bean Validator (JSR-303), smooth Integration with different View Technologies, among others. Furthermore,  Spring-MVC has been making improvements through out each release that has made it a more robust framework, including the latest REST support. Like every framework, there is always a "gotcha" in a feature and such is the case for <mvc:annotation-driven />.

<mvc:annotation-driven /> is a nice feature, however depending on how you are used to organize your Spring-MVC files, it can prove to be confusing. I'll try to explain my findings as clear as I can.

XML Validation within Eclipse

  Working with XML can be a wonderful experience. Most people I know (in the industry) don't consider XSD/DTD validation a task that is challenging enough so as to spend time and/or effort to either learning it or writing to it. This feeling changes rapidly as tooling support (e.g. IDEs) produces hiccups when XML validation generates errors that can not be understood by the same engineering staff.  For example, have you ever had the infamous problem reported through Eclipse's console:

cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'custom-filter'.


  By default Eclipse has XML validation on. This means that it will look for a DTD of XSD to validate your XML file. The message above indicates that there's an XML element named custom-filter that can not be resolved with any of the XSD that Eclipse is aware within it's catalog registry.