Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java REST framework Dropwizard 1.0 released

dropwizard.io

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Java REST framework Dropwizard 1.0 released

#71

Post by i2shar »

CHY872 wrote: post #70
spoondan wrote: post #45

Earlier quoted context omitted.

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.

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 discov…

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.

Re: Java REST framework Dropwizard 1.0 released

#72

Post by dozzie »

dustingetz wrote: post #39
teen wrote: post #32

Earlier quoted context omitted.

Couldn't agree more. REST is just a very leaky abstraction layer, when what you really want is RPC, with some reusable / composable typed models.

I don't know, RPC is declaring for no abstraction at all, just raw access to code that can do anything. REST provides strong abstractions, they are just slow, and to make the app fast we have to compromise them. But that's the same for relational databases and ORM; I think really REST isn't the problem, but instead SQL. And RPC is like writing bits with butterflies.

Erm... Abstractions? In REST? What abstractions?

Re: Java REST framework Dropwizard 1.0 released

#73

Post by quicksilver03 »

CHY872 wrote: post #70
spoondan wrote: post #45

Earlier quoted context omitted.

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.

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 discov…

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

Re: Java REST framework Dropwizard 1.0 released

#74

Post by dozzie »

nu2ycombinator wrote: post #33
dozzie wrote: post #25

Earlier quoted context omitted.

More like set of worst practices. You have some API exposed in plenty of endpoints instead of one, and on top of that you embed one of the call arguments in the URL itself. And no, it doesn't make designing API easier if you preallocate "read", "create", and "delete" operations to separate HTTP methods, and then put all the other operations in POST. "Create" and "delete" in many cases don't even make any sense to gua…

Well there are no hard and fast rules. Any set of best practices are opinionated. You can have different of opinions if they are not suited for your use case. All the REST frameworks you found are designed around the those ideas. For making your APIs rest you do not need any framework you can design your APIs along those guidelines. Again how far your apis need to be REST complaint again it is upto common sense.

> Any set of best practices are opinionated.

"Best practices" are supposed to work sensibly in most cases. REST only works in a small subset (read/create/delete and nothing more), other cases being stuffed collectively under HTTP POST umbrella, so you need some RPC protocol anyway. This is very far from working sensibly.

Re: Java REST framework Dropwizard 1.0 released

#76

Post by _pmf_ »

CHY872 wrote: post #69
_pmf_ wrote: post #67

Earlier quoted context omitted.

Jetty has been around for a while; a response handler is a one liner (well, a Java one liner, which translates to 7 lines ...). With Spark[0] (not to be confused with Apache Spark ...), you can get a Sinatra-like routing library on top of Jetty (while you still can deploy the webapp in a more heavyweight container if you need to). I think Spark is in spirit much like Dropwizard, but a bit more lightweight. [0] http:/…

(opinion: i've spent a year writing Dropwizard based apps, but only two evenings writing Spark based apps). I think that Spark comes at the cost of customisability - 2-way SSL is a chore, you have to parse your own message bodies, you don't get straightforward logging out of the box - there's a base set of features and functionality that I couldn't find in Spark. The thing that impressed me about Dropwizard is that y…

I've only used Spark in a very local context (small company internal projects), so I'll definitely take into account your experience when doing something bigger.

Re: Java REST framework Dropwizard 1.0 released

#77

Post by StreamBright »

spapas82 wrote: post #19
crypto5 wrote: post #16

Earlier quoted context omitted.

Dropwizard has templating engines integration and form validation.

I'm aware of that. However, have you tried using them in any non-trivial project? (for example, a project that supports authentication ?)

We are actively using it for things like that. What is your actual problem, could you show some code?

Re: Java REST framework Dropwizard 1.0 released

#78

Post by StreamBright »

CHY872 wrote: post #70
spoondan wrote: post #45

Earlier quoted context omitted.

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.

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 discov…

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

Re: Java REST framework Dropwizard 1.0 released

#79

Post by einrealist »

spoondan wrote: post #45
ianai wrote: post #41

Earlier quoted context omitted.

Interesting because they made it sound pretty horrific.

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.

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

Re: Java REST framework Dropwizard 1.0 released

#80

Post by einrealist »

CHY872 wrote: post #70
spoondan wrote: post #45

Earlier quoted context omitted.

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.

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 discov…

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.

Post reply on HN