Hacker News Reader

Comment by spoondan | Hacker News Reader

There's quite a bit of magic under the hood of DropWizard (or, rather, the components that make it up). My experience has been that a developer using DropWizard will rarely, if ever, encounter this magic: they don't need to be aware of it. But if the veil ever slips, the sheer amount of ugly machinery will shock and horrify.

View on HN

I can see that. We found that if we added the Spotify Docker Client to our test classpath we couldn't run the application from Eclipse anymore because our Jackson object mapper had the wrong Jersey modules.

This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.

It was a mess.

Classpath issues such as yours are very common in Java. I suppose that's why building a fat jar is part of the getting started section of the docs.

Although it is very easy to add dependencies via Maven or Gradle, this does not prevent you from shooting yourself into the foot. You have to manage dependencies, including transitive ones. If the application has too many conflicting dependencies, then use classloader isolation (e.g. OSGi).

It is a littlebit sad, that there are no javac warnings enabled by default that at least check known classes for conflicts in the classpath. An IDE should do that by default, too.

That's 100% Eclipse's fault however, nothing to do with Jersey or Jackson.

That's dynamic linking for you - you need to take the good with the bad

You just pointed out how a feature missing in your tooling can lead to problems. This has nothing to do with Dropwizard though.

Personally ,the worst I've ever run into is some hairy classpath issue, as one the children comments mentions. Although maybe I'm just lucky.

Where does bytecode manipulation or code generation happen in Dropwizard? Reflection for sure, but not any more so than any major web framework in a dynamically typed language.

Maybe you're referring to the SQL library they suggest (which I've admittedly never used heavily). But I don't see how you can have a SQL library without generating SQL.

I disagree. Dropwizard itself is really simple. The frameworks like Hibernate or HK2 are more complex, though. But there is definetely no magic involved.

Reply on news.ycombinator.com