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.

Dynamic Web Projects in Eclipse

As I fixed a maven war project to more effectively use the Web Tools Project (WTP), I realized I could share the configuration I used with the hope to help others get some light as needed.  I'll be assuming you are familiar with the .classpath file as well as the .project file (which Eclipse uses heavily) to setup the dynamic web project.  Furthermore, I'll assume you are familiar with the notion of a "nature" within the Eclipse environment.  Lastly, I would like to refer readers to the official Eclipse FAQ.  In particular, I would like to refer you to the section where the sharing of the .project and .classpath files in version control (e.g. subversion, git, etc) is considered a good practice. Note that these tips will also work with the Springsource Tool Suite (STS)

Developing on Windows and jps

  In the last few months, I have been forced to develop using a Windows environment. I must admit I miss most of my linux/unix command prompt usage, among which is the "jps" tool.  For those of you not familiar with it, jps is a "process status" tool and is part of the jdk.  According to the documentation, this is an unsupported tool and comes with no guarantee, however I've found it to be a simple tool that can come in handy in certain situations as the one I'm about to describe.

  During my initial maven build, the test phase was throwing exceptions due an incorrect configuration.  As I tried to delete the target directory, windows reported the folder was in use.  Cygwin's "ps" command didn't reveal much.  Window's "Task Manager" wasn't really saying much either.  This is where "jps" brought light.  Jps reported the SurefireBoot.jar still hanging in there (apparently due to some unrelease resource). Unfortunately, the problem became even more serious as the reported PID was not that simple to kill (using Cygwin's kill command).