4 ms·

The article mentioned DropWizard (covered more in part 1). DropWizard is a very nice (the best?) way to write RESTful web services in Java. Coda Hale, that auth

The article mentioned DropWizard (covered more in part 1). DropWizard is a very nice (the best?) way to write RESTful web services in Java. Coda Hale, that author, has glued together some of the best Java libraries with very sensible configurations, almost to the point of saying "look stupid, this is how you're supposed to do it (in Java)". The application configuration patterns (ugh... I said "patterns"), clear separation of resources, built-in metrics, and health checks is worth studying (at least for journeymen like me). Check it out: http://dropwizard.codahale.com/ http://dropwizard.codahale.com/

rudiger 14y ago
How does this compare to using Spring application development framework (with Maven, of course)? My understanding is that the Spring framework is how you're "supposed to do it" in Java, and it certainly is very popular. http://www.springsource.org/ http://www.springsource.org/
- eckyptang 14y ago
  I've done a fair bit with Spring in Java. Unfortunately the promises seem to fall short of delivering as your application scales up in complexity. I've experienced a number of problems with annoying little bugs and some odd brick walls with transaction management (between JMS/Hibernate). I'd rather build something with Java EE6 if I had the choice now, or ASP.Net MVC+WCF+NHibernate if I had the choice of platform.
  - mbell 14y ago
    > I'd rather build something with Java EE6 if I had the choice now Don't, its a nightmare.
    - eckyptang 14y ago
      Thanks for the heads up :) anything in particular that kills it for you?
      - mbell 14y ago
        1) WELD CDI has no good testing story. The only option that allows CDI to work is to use Arquillian which deploys and undeploys an entire WAR for every test class, it other words it takes hours to run integration tests. Unit tests are livable using Mokito and its ability to mock injections. 2) JSF + WELD have holes between there specs. CDI can manage JSF session and request scoped beans and you can use conversation scoped beans in JSF. However they never got around to figuring out view scoped beans (which IMO is one of the most useful things in JSF). As a result you have to use some third party to make them work together. There are a number of other spec holes but I'll use this one as an example. This means using SEAM 3 or CODI CDI extensions to fill the gaps. I went with SEAM 3 as it theoretically had a good lineage given that a lot of what was done in SEAM 2 ended up being the EE6 spec. What the SEAM 3 project did however, was to write a half assed version of all their extensions, then summarily announced they were all ditching the project to go work on Apache Deltaspike, which is basically the same extensions with a different name. Currently the SEAM 3 extensions are in various states of broken depending on the extension and your use case, and of course Delta Spike isn't ready yet (still in Apache Incubator). I've removed most of SEAM 3 from my app at this point, the remaining module is SEAM Faces which is unfortunately plugging the hole in JSF View Scope working with WELD. Also unfortunate is that there is and has been a bug in SEAM Faces for months now that causes the data JSF stored in the session to be unserializable. So I'm stuck with sticky sessions. SEAM modules also fill in the hole with Hibernate's stupid session management, i.e. opening a transaction in the RENDER_RESPONSE phase so lazy loading works. Several times now I've run into bugs, gone to research them and found they weren't fixed because people from the involved modules were arguing over the EE6 spec. I could probably yap for awhile here but It may be easier to say this, I started my current product last April(2011), it started as a "pure" EE6 app. I ran into so many EE6 bugs and just pure stupidity in places that I've been moving away from it ASAP. I've replaced Hibernate with Ebean, ditched 90% of SEAM, setup an API with Jersey/Jackson and we're now pushing all front end stuff to Rails or Backbone apps which just talk to the API. I'd never write another webapp with EE6. Jetty/Jersey/Jackson is great for web services, especially with groovy. If you need to handle the front end tasks, use play or grails.
        eckyptang 14y ago
- stickfigure 14y ago
  Spring and Dropwizard are really not comparable. Spring is a large, invasive framework which covers many different facets of enterprise application design. Dropwizard is a set of commonly-used libraries (jetty, jersey, jackson, slf4j, a couple others) with a little bit of glue to stitch them together.
  - KevinEldon 14y ago
    Very well stated. You said it in half the words I did. I especially like your point about Spring being "invasive". For me, Spring MVC was so invasive I couldn't justify using it... the LDAP, JDBC, and Security components work usable without too much interference though.
- KevinEldon 14y ago
  As I understand it Spring offers a complete enterprise application development framework, while DropWizard focuses on delivering production quality RESTful web services with minimal developer work. I've used Spring a little, it's nice... very full featured; in fact I still have production code using Spring's JDBC and LDAP libraries and Spring Security... they've worked out very well for me. I think Spring is the Rails to DropWizard's Sinatra. They're both very good, but if you need less and DropWizard can cover what you need it's a lot easier to use and probably uses the libraries you'd want to use anyway (unless you know a lot of Spring or JEE already).
- brown9-2 14y ago
  There is never just one answer on what libraries/frameworks to choose, and anyone who tells you that there is just one way you are "supposed to do it" probably isn't worth listening to :) With that said, I am a big fan of Spring and I don't consider it "intrusive" as some other commenters do. But if you aren't interested in using it as a DI container then you may find it easier to just get closer to the other libraries used (i.e. Jersey etc) and avoid any helper code.
- strlen 14y ago
  > http://www.springsource.org/ http://www.springsource.org/ http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... Does that answer your question?

rudiger 14y ago

How does this compare to using Spring application development framework (with Maven, of course)? My understanding is that the Spring framework is how you're "supposed to do it" in Java, and it certainly is very popular. http://www.springsource.org/ http://www.springsource.org/

eckyptang 14y ago
I've done a fair bit with Spring in Java. Unfortunately the promises seem to fall short of delivering as your application scales up in complexity. I've experienced a number of problems with annoying little bugs and some odd brick walls with transaction management (between JMS/Hibernate). I'd rather build something with Java EE6 if I had the choice now, or ASP.Net MVC+WCF+NHibernate if I had the choice of platform.
- mbell 14y ago
  > I'd rather build something with Java EE6 if I had the choice now Don't, its a nightmare.
  - eckyptang 14y ago
    Thanks for the heads up :) anything in particular that kills it for you?
    - mbell 14y ago
      1) WELD CDI has no good testing story. The only option that allows CDI to work is to use Arquillian which deploys and undeploys an entire WAR for every test class, it other words it takes hours to run integration tests. Unit tests are livable using Mokito and its ability to mock injections. 2) JSF + WELD have holes between there specs. CDI can manage JSF session and request scoped beans and you can use conversation scoped beans in JSF. However they never got around to figuring out view scoped beans (which IMO is one of the most useful things in JSF). As a result you have to use some third party to make them work together. There are a number of other spec holes but I'll use this one as an example. This means using SEAM 3 or CODI CDI extensions to fill the gaps. I went with SEAM 3 as it theoretically had a good lineage given that a lot of what was done in SEAM 2 ended up being the EE6 spec. What the SEAM 3 project did however, was to write a half assed version of all their extensions, then summarily announced they were all ditching the project to go work on Apache Deltaspike, which is basically the same extensions with a different name. Currently the SEAM 3 extensions are in various states of broken depending on the extension and your use case, and of course Delta Spike isn't ready yet (still in Apache Incubator). I've removed most of SEAM 3 from my app at this point, the remaining module is SEAM Faces which is unfortunately plugging the hole in JSF View Scope working with WELD. Also unfortunate is that there is and has been a bug in SEAM Faces for months now that causes the data JSF stored in the session to be unserializable. So I'm stuck with sticky sessions. SEAM modules also fill in the hole with Hibernate's stupid session management, i.e. opening a transaction in the RENDER_RESPONSE phase so lazy loading works. Several times now I've run into bugs, gone to research them and found they weren't fixed because people from the involved modules were arguing over the EE6 spec. I could probably yap for awhile here but It may be easier to say this, I started my current product last April(2011), it started as a "pure" EE6 app. I ran into so many EE6 bugs and just pure stupidity in places that I've been moving away from it ASAP. I've replaced Hibernate with Ebean, ditched 90% of SEAM, setup an API with Jersey/Jackson and we're now pushing all front end stuff to Rails or Backbone apps which just talk to the API. I'd never write another webapp with EE6. Jetty/Jersey/Jackson is great for web services, especially with groovy. If you need to handle the front end tasks, use play or grails.
      - eckyptang 14y ago
stickfigure 14y ago
Spring and Dropwizard are really not comparable. Spring is a large, invasive framework which covers many different facets of enterprise application design. Dropwizard is a set of commonly-used libraries (jetty, jersey, jackson, slf4j, a couple others) with a little bit of glue to stitch them together.
- KevinEldon 14y ago
  Very well stated. You said it in half the words I did. I especially like your point about Spring being "invasive". For me, Spring MVC was so invasive I couldn't justify using it... the LDAP, JDBC, and Security components work usable without too much interference though.
KevinEldon 14y ago
As I understand it Spring offers a complete enterprise application development framework, while DropWizard focuses on delivering production quality RESTful web services with minimal developer work. I've used Spring a little, it's nice... very full featured; in fact I still have production code using Spring's JDBC and LDAP libraries and Spring Security... they've worked out very well for me. I think Spring is the Rails to DropWizard's Sinatra. They're both very good, but if you need less and DropWizard can cover what you need it's a lot easier to use and probably uses the libraries you'd want to use anyway (unless you know a lot of Spring or JEE already).
brown9-2 14y ago
There is never just one answer on what libraries/frameworks to choose, and anyone who tells you that there is just one way you are "supposed to do it" probably isn't worth listening to :) With that said, I am a big fan of Spring and I don't consider it "intrusive" as some other commenters do. But if you aren't interested in using it as a DI container then you may find it easier to just get closer to the other libraries used (i.e. Jersey etc) and avoid any helper code.
strlen 14y ago
> http://www.springsource.org/ http://www.springsource.org/ http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... Does that answer your question?