Thoughts on the Spring Framework

One of my goals for the year was to learn more about the Spring Framework, a layered set of modules that intend to make enterprise Java development easier.

In September, I took a class on Spring. Last month, I put together a presentation to share what I learned with my colleagues.

The bootcamp
I attended the Core Spring bootcamp in New York City. If you’re looking to learn about Spring in a classroom environment, there is perhaps no better source than Interface21‘s consultants as they are the company behind the project.

The course materials were solid and the class revolved around a real-world application scenario. For each segment presented, corresponding before and after projects for the lab were available in a workspace used by the free, Eclipse-based Spring IDE that was distributed to the class.

A copy of Pro Spring was included with tuition, but I’ve found the newer Spring in Action, second edition a better read. The instructors also noted that the older Pro Spring book had information on AOP and transactions that weren’t up to speed with the latest 2.x versions of Spring.

As you would expect from a technology that in practice killed EJBs, the Spring bootcamp focuses on middle-tier applications. However, there was good coverage of Spring MVC, which I hope to a adopt for a new project built on WebSphere 6.1 and J2SE 5.0.

Like Baldwin home from Paris
Some time after the course I had the opportunity to present an overview of the Spring Framework to my department. The audience consisted of developers as well as project managers and other non-technical types, so the goal was to keep the presentation accessible as well as sufficiently informative.

To sum up the philosophy of Spring in a nutshell, I hit on three characteristics with real world parallels. I hope they went over well, and I think some of the other learning materials out there would benefit from a similar approach. It seems the ideas behind Spring could be conveyed easier than they often are (another reason I like Spring in Action).

  • Inversion of Control / Dependency Injection
    Give code what it needs, don’t make it ask
    Does your car buy its own gas? Should it have its own credit card? Or use yours?
  • Interchangeability through Interfaces
    Keep things “black box” enough that you can swap individual pieces out when you need to
    Your twenty year old lamp can take either a traditional incandescent light bulb or a new compact fluorescent light bulb which provides a 75% more efficient way to do the same thing in the same standard socket.
  • Aspect Oriented Programming
    Terrible name and difficult vocabulary for an easy-to-grasp concept
    Consolidate logging and access control code, don’t repeat it all over the place
    Imagine an assistant tracking your billable hours to several projects during the day for you while you focus on your real job.

Silly middle-tier guys, or, what’s with that goofy .htm extension?
I have one outstanding gripe about Spring. Spring MVC in particular. I let it slide in the class, but since the foolishness is repeated in other materials for learning Spring I felt I had to speak my mind.

In a lot of examples for configuration of the Spring MVC DispatcherServlet, folks will tell you that “.htm” is the preferred convention for the mapping requests to the front controller.

The argument goes that we should trick the search engines into thinking this is static HTML content and besides, the mapping reflects that even though the page is dynamic, it is indeed rendered in HTML. Furthermore, the “.do” convention from Struts is pure tomfoolery.

This is dogsqueeze.

I take exception with all those arguments. In fact, I’d go as far as to say the “.htm” extension for dynamic content is actually harmful:

  • Most developers deploy Java Web applications to an application server which is not also the front-end Web server. Application servers, such as WebSphere, are configured to serve only dynamic content, such as servlets and JSPs. The HTTP server, such as Apache, serves the static files such as HTML documents, stylesheets and images.

    What if you really did have a static file with a “.htm” extension deployed by one of your Web developers? Do you want to see her go bonkers when she can’t figure out why her file is not being found because you decided to map that extension to your servlet? WTF?

  • Do you really want to make the impression that you’re hosting your Fortune 500 or high volume e-commerce site on MS-DOS?
  • The “search-engine friendly” argument for the “.htm” extension goes out the window when you start using query string parameters anyway.
  • You’ve introduced goofiness at the cost of elegance, another tenet core to Spring. Sigh.

But honestly, if you’re going to go through with it anyway, just add the damn extra “l”, filename limitations (virtual as they may be) are a thing of the past.

  

5 Responses to 'Thoughts on the Spring Framework'

Subscribe to comments with RSS

  1. KiLVaiDeN said,

    02 November 2007 at 9:40 am

    Hi !

    First, I’d like to react to the Spring presentation you did : it’s quite exact, except for the fact that you should make a difference between “Inversion of Control” and “Dependancy Injection” because it’s not quite the same, but it’s a detail. I also think that AOP is a very important point of Spring, but maybe one point you forgot, is the abstraction level of utilities classes, that make your code “library independant”, for example take the ORM package of Spring, you could use it in such a way that nobody would know what kind of persistance library you are using.

    I wanted to post for an answer to the “.htm” debate. I totally agree with the fact that using “.htm” can be confusing if there is mixed static HTML content ( even though there is easy ways to get around this ) but then, does it really happen that often ?

    I believe that extension is really not that important for referencing. I’d even say that it’s irrelevant. So the argument of people saying that “.htm is good for referencing” is quite out of its time.

    BUT the fact that when a user goes to your website and doesn’t know what kind of technology you use to display the dynamic content because of the “.htm” extension, is quite interesting, because the more your hide from the public, the less risk you take when dealing with hackers.

    Cheers
    K

  2. Daniel Krook said,

    03 November 2007 at 12:12 pm

    Hi K,

    Thanks for your comments.

    The three points about Spring that I highlighted for the group were intended to convey the main ideas at a high level. So my goal there was to introduce the terms that are commonly used, without having to go into too much detail about the technical differences.

    That’s why I left that bullet as both “Inversion of Control / Dependency Injection,” since the audience may hear one or more of those terms used to describe the same concept. In that case it seems more helpful to keep them together.

    To add some more detail about the “.htm” convention… You may have noticed that this blog itself uses WordPress, a PHP application. It comes with the option to choose URLs that don’t show the file extension at all, thanks to a simple mod_rewrite rule.

    If I bothered to configure my Web server not to show its signature and this blog wasn’t so obviously build on WordPress, that would theoretically make it safer from hackers.

    This is a nice goal, but when applied to the using “.htm” to mask the server side implementation argument, it’s pretty weak… there are better ways.

    First off, if you are going to try to hide your implementation from search engines and hackers alike, just drop a file extension completely. This makes your URL smaller and more likely to contain a higher ratio of relevant semantic information. Second, you hide the implementation details if you decide to move your site in 5 years to some newer technology.

    Unfortunately, there are only two methods for mapping servlets by wildcard in your Web deployment descriptor… either provide a base piece of the URL, such as /servlet/*, or map everything before the file extension, such as *.do. Dropping the extension means you have to figure out some other pattern that needs to be repeated in your servlet URLs, or manually specify each servlet in web.xml by name.

    There is some leeway with URL structures that can be performed via servlet filters, but these can only be applied after the mapping in web.xml.

    So what do I recommend in place of the “.htm” extension? No extension at all, if possible. Then, maybe some mod_rewrite at the Web server level to dodge the other required URL pattern and maybe the context root. I must meditate on this some more…

    Anyway, thanks for your comments K.

    -Dan

  3. Kallin Nagelberg said,

    06 November 2007 at 8:11 pm

    I’ve been using Spring for sometime now. Even if you don’t use it’s uber-functionality, you may find that it includes many libraries for things such as IO that are just way easier than doing it through the java API.

    I do have a slight gripe with the “.htm is foolishness” argument though. In my view, the browser is making a request for HTML so it makes sense for .htm to be in the url. If you were requesting a .gif, you would probably have blah.com/myimage.gif. Why not the same for any other content? You don’t care if the image is coming out of a database, being decrypted and run through a set of filters, you only care about what you get. I would even say it should be .html, but that’s just nitpicking now :).

  4. Mike said,

    18 May 2008 at 11:49 am

    @ Daniel:
    Very nice article. Well thought out and well written.

    @ Kallin
    Actually a web browser does not “request” HTML, it requests the result of an URL. The primary mode of displaying the result is HTML. While this may seem like nitpicking, it is an important distinction, particularly in this day and age where it may not even be a browser requesting the URL.

    In any case, exposing an extension of any kind is just messy IMO.

  5. Leandro said,

    07 December 2009 at 7:31 pm

    “Second, you hide the implementation details if you decide to move your site in 5 years to some newer technology.”
    This is very interesting, because all references to the old pages would be lost. I’ll try to avoid to use extensions. =)

Leave a Reply