The simplest Gradle example I can come up with

gradleI’m just now getting into Gradle, and I had a little trouble just Googling a simple build script that would get me up and running with a basic Spring MVC web application quickly.

In case you’re looking for the same, here’s what I came up with:

[code lang=”groovy”]
apply plugin: ‘war’
apply plugin: ‘jetty’

sourceCompatibility = 1.6
version = ‘1.0’

repositories {
mavenCentral()
}

dependencies {
providedCompile ‘javax.servlet:servlet-api:2.5’
compile (‘org.springframework:spring-webmvc:3.2.2.RELEASE’,’javax.servlet:jstl:1.2′)
testCompile (‘junit:junit:4.11’, ‘org.springframework:spring-test:3.2.2.RELEASE’)
}

jettyRunWar.contextPath = ”
[/code]

For the record, I’m only focusing on Spring because that’s what I work on most of the time these days.

  • The first section declares plugins. I think this declaration block is quite a bit more expressive than Maven, where you have to declare plugins at various points in the pom.xml in a really verbose way. With Gradle, it’s pretty simple (query if I’m losing power?): you can quickly tell from my script that I want to package the project as a war (for Tomcat/servlet container deployment) and that I want to be able to run Jetty locally to test it.
  • Next, similar to Maven, Gradle needs access to a repository of artifacts. Gradle gives you access to the Maven Central Repository by declaring mavenCentral() as a repository. It’s definitely easier to read than a pom, but again, query whether I’m losing some configuration power here.
  • Finally, we need to declare our dependencies. If you understand the Maven coordinate scheme, then Gradle is a little easier than the verbose pom.xml. Plus it’s easier to see what dependencies go into what build cycle. For example, I’m declaring the servlet API at compile time, but I’m not declaring JSTL or Spring MVC until the actual compilation (yes, yes, I know my Spring MVC is a little out of date). NOTE: it seems like Intellij got the dependency wrong when it created my initial gradle file. The JSTL dependency actually needs to be bundled into the WAR to get the “newer” JSTL syntax.

So there you go, it’s not that different from Maven:

  1. Tell Gradle what plugins you want to run.
  2. Tell it where to get its artifacts.
  3. Tell it what artifacts you want.
  4. Save it as build.gradle and then run gradle tasks to see what you can do with it.

Good luck out there.

Debug deep dive into doDispatch() in Spring MVC

I’ve been stuck at home with sick kids so I just decided to take a debugging deep dive into the doDispatch() method of Spring MVC’s dispatcher servlet (DispatchServlet, the so-called “front controller“). Since this is my blog and I get to write whatever I want no matter how trivial, I thought I’d share two impressions, each of which are informed by a lack of sleep.

One impression: is Spring’s strength also its weakness?

I think of Spring as coming of age in era of enterprise Java when many competing frameworks were trying to be all things to all people. Spring beat J2EE in some early battles because it successfully appealed to all audiences while not imposing too much heavyweight configuration for most enterprise developers, which probably comes as a surprise to new today’s new developers. These days, developers are either annoyed or intimidated by its flexibility.

Its flexibility remains awesome, however. As an application developer, you can customize a HandlerMapping object, HandlerAdapter, HandlerExceptionResolver, ViewResolver, LocaleResolver, LocaleContextResolver, ThemeResolver, MultipartResolver, and a FlashMapManager. Just take a look at the DispatchServlet itself. It invokes the strategy pattern to use stategy objects on nine major configuration options:

Some of this annoyance and intimidation (and of course, I get both annoyed and intimidated too) comes from Spring’s impenetrable naming scheme. In its pursuit of being all things to all web developers, something like HandlerAdapter is so vague that it’s meaningless the first time you see it. And that’s easy compared to something like DelegatingFilterProxy or SerlvetInvocableHandlerMethod (which is a class, BTW). Spring has precise, but intricate and opaque (to the average developer) naming conventions.

So I guess my point on this impression is that I wish there was something like Spring Lite MVC that didn’t make me think about all these configuration options; I’m thinking of a light implementation that simply let me write some @RequestMapping decorated classes and some JSPs and call it a day. If I want to go further, I will.

Maybe Spring Boot will cure my worries, but is it too “opinionated” to build a simple MVC-CRUD-based web app without learning what the Spring folks’ “opinion” is?

Second impression: is Spring’s flexibility leaving optimization on the table?

Obviously, flexibility implies (requires?) a performance trade off. And if you’ve worked with Spring MVC, you know that a big part of its power is its ability to resolve a web request to @RequestMapping annotations you’ve used to decorate your controllers–without having to write XML. What you might not realize is (a) how deep in the stack trace you are and (b) that Spring MVC performs as if it’s the first time it’s ever seen your application for every single request. The first problem comes from Spring’s verbosity and their designers’ OO elegance. I’ll defer that issue to them.

It seems to me that the second issue could be solved with a little real world caching though. In mapping a simple request, say to “/” from a web browser, Spring MVC goes through a fairly tortured and exhaustive reflection-informed search of all annotations of all your classes for the right @RequestMapping mapping to a given request — every time! While that might only be a few dozen or a few hundred loops in any given Spring MVC solution, it still seems wasteful to me. Wouldn’t a simple @Cacheable annotation fix this — at least in part? Of course, if I’ve overlooked something and I’m wrong on this point, please let me know!