4 ms·
Yes. Most of the unnecessary complexity has just been moved from bad APIs with XML configuration to bad APIs with runtime scoped annotations, code generation an
by asdf1234 10y ago
Yes. Most of the unnecessary complexity has just been moved from bad APIs with XML configuration to bad APIs with runtime scoped annotations, code generation and byte code manipulation. It's still a huge mess.
- avita1 10y agoI use Dropwizard in my day-to-day and I've never ran into any code generation or byte code manipulation.
- ianai 10y agoInteresting because they made it sound pretty horrific.
- spoondan 10y agoThere'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.
- CHY872 10y agoI 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.
- i2shar 10y agoClasspath 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.
- quicksilver03 10y agoThat's 100% Eclipse's fault however, nothing to do with Jersey or Jackson.
- StreamBright 10y agoYou just pointed out how a feature missing in your tooling can lead to problems. This has nothing to do with Dropwizard though.
- einrealist 10y agoAlthough 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.
- sorokod 10y agoThat's dynamic linking for you - you need to take the good with the bad
- einrealist 10y agoI disagree. Dropwizard itself is really simple. The frameworks like Hibernate or HK2 are more complex, though. But there is definetely no magic involved.
- avita1 10y agoPersonally ,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.
- asdf1234 10y agoYes you have. Jersey, Jackson and almost every Java database abstraction that's higher than JDBC uses one if not both. Dropwizard is one of the better Java libraries in this regard but it's still there.