I am using Guice as my dependency injection framework. I'd like something that I can add that will make creating REST services easier.
I've had a look at guice-servlet and it works well for directing paths to HTTP servlets, but that's all it appears to do, I was expecting a JAX-RS like annotation syntax to work but it doesn't.
Having not actually used JAX-RS I've googled around and it appears that Jersey is the reference implementation for this but it looks like it uses its own dependency injection framework and doesn't work well with Guice. In addition it has 5+MB worth of dependencies which seems alot for what I am after.
Is Guice designed in such a way that it doesn't lend itself to JAX-RS, if so what else should I be doing?
I think that maybe the guice-servlet module has misguided you. Guice is a DI framework. Period. The real goal of the guice-servlet module is not providing the servlet's and filter's shortcut declaration but giving support for the special scopes request and session. Those nice shorcut declarations are syntatic sugar.
Chosing a JAX-RS implementation in Java is a bit out of the question. You have several options (Jersey, Resteasy, Spring...). If you are going full JavaEE then you don't have to choose. You just use the annotations (and the DI) out of the box.
If you are not using a JavaEE server (just a web server like Tomcat or any other fancy thing like an Android app) then you must choose your implementation. If you are using DI also (which I recommend) then there is one more decision to make.
So you are not using JavaEE and you want to implement some REST API using JAX-RS and dependency injection. You do some research and end up choosing Jersey and Guice. Good choice, I've chosen those in my last projects too. Yes, the dependency graph of Jersey is a bit bloated. I know, it could be way better.
Now your problem is how to make it work together because Jersey uses it's own DI framework (HK2) which is a bad thing.
You have a lot of references on SO about Jersey-Guice integration. Your best bet is the Guice HK2 bridge.
What? You want a direct reference on SO? No problem, here is a good one. Don't forget to upvote the answer. ;-)
Jersey and Google Guice integration
Related
I am learning the REST architecture these days. I have developed many small small projetcs using jersey. My question is what exaclty is JAX_RS ? I understand that JAX-RS is a set of interfaces (all the javax.ws.rs.* classes) which contains annotations like GET,POST and a lot more. Jersey is one of the bundle which has classes which implement those methods. My doubt is if we download java , do the JAX_RS interfaces come with that ? I have used maven to build REST. There i have seen a lot of entries being added to pom which does my job, but i want to get the actual feel of what exactly is this JAX-RS. Any help is appreciated ! sorry if this is foolish !
JAX-RS is just a specification. A specification specifies how such a framework should work (in a PDF file), and provides different Java interfaces and annotations and enums (like javax.ws.rs.* classes), but no functional code.
The URL for JAX-RS specification are:
JAX-RS 1.1 (you probably use this one) https://jcp.org/en/jsr/detail?id=311
JAX-RS 2.0 https://jcp.org/en/jsr/detail?id=339
Along with the specification there are implementations of that specification, which is functional code (java jars), that you can use in your applications. Such implementations are JERSEY and RestEasy (usually applications use only one).
Now what you need is a JAX-RS tutorial. Take the first two results from google:
http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html (I find this one very good)
http://www.vogella.com/tutorials/REST/article.html (this one is very comprehensive, IMHO)
I've created a RESTful web service using jersey and JAX-RS annotations. It's also documented using enunciate and looks great. However, SOAP support has been requested as an option. I noticed in this outdated enunciate example JAX-WS and JAX-RS annotations in the same class. Is this possible? I've tried it myself and enunciate generates documentation correctly, but the services don't actually work.
I'd prefer to have the exact same class support both interfaces rather than two separate classes (one soap one rest) pointing to the business logic class. This would prevent possibly having code in two places.
Here's the example on outdated software versions:
http://docs.codehaus.org/display/ENUNCIATE/A+Rich+Web+service+API+for+Spring
I'm using
Jersey 1.8
Spring 3.0.5
Weblogic 11g
Thanks!
/Chip
I'm not sure what might not be working, but a lot of the Enunciate example modules use both the SOAP and REST annotations on the same class.
Here's one for Jersey/JAX-WS.
Here's one for JBoss WS/RestEasy.
Here's one for CXF.
We ended up making a separate service for SOAP than the REST service. We also found it best to have interfaces for each that enunciate could generate from. This way we could control what documentation it generated. It also started functioning smoother. Still having a problem with the namespaces though as they're all default and ns0 is generated but enunciate links are to ns2/3/4/5/etc. So many links are broken.
I know Scala Lift applications can be put into a Java EE server. And Scala Lift seems to compete/substitute JSF as presentation layer of Java EE.
Will I be able to use EJBs and JPA in a Lift application? And if yes, could it be also possible to use JSF alongside Lift as a fallback, like URLs with one prefix go to Lift and with another to JSF?
Yes, you can use EJB and JPA in a Lift app. Just call your java methods from within Lift snippets. Just like any Java application, if it is on the classpath, you can use it.
As to your second question, anything is possible. The only sane way I can think about doing what you're describing would be to configure your servlet filters (in WEB-INF/web.xml) to pass some requests to Lift and others to JSF. You could also cook up a way to do this within either JSF or Lift, essentially proxying certain requests from one to the other. It is hard to imagine a use case that would justify such ugliness, but it is possible.
For example, Play-framework supports RESTful services like this: RESTful on Play! framework
How does this compare to something like Jax-RS Jersey implementation? Does a framework like Play run circles around Jersey because of all it's cool bells and whistles, and it does REST too?
Developer productivity is important, but so is a proper implementation. Perhaps using an MVC framework for REST only services is 'wrong'?
Note, only RESTful services, no UI components at all.
Even though it's not "wrong" to use an MVC framework for RESTful services, there are some pros and cons versus using a JAX-RS implementation.
(Disclaimer: I have only used Jersey and Play! for fun, and not on production-grade systems, so I have tailored my comments more generally to MVC vs. JAX-RS. Keep in mind that these are broad generalizations.)
MVC frameworks--at least the ones that are considered developer friendly and "slick"--typically save you from having to build a persistence layer (the model part). Most also simplify "routing" requests using either scaffolding via convention or some form of configuration. The downsides are that you have to conform to some conventions for your controllers and usually have to write a view for each resource (or build layers of abstractions to avoid rewriting the same code).
JAX-RS excels at defining the routing (using Java annotations) as well as eliminating any restrictions on the service class. In my experience, that has greatly reduced the amount of boilerplate code and developer overhead. Jersey and Apache CXF also handle the XML or JSON serialization using JAXB annotations, which eliminates the need to figure out the view in an MVC context. The downside here is that you have to figure out your own ORM or persistence layer, which could be good or bad depending on whether you're building on top of existing data or creating a greenfield system (or using something other than an JPA/RDBMS e.g. NoSQL data store).
My own personal comment: Play! is a really cool framework, but I'd choose CXF (or Jersey) over an MVC framework any day for building out a RESTful service. In my experience, this frees up the developer to focus on the logic needed for the service, and opens up options for different database approaches. Right tool for the right job.
As a rule of thumb: For Scala, use Play. For Java, use Jersey.
You can use Jersey/Scala and Play/Java; I've done both. It works. It isn't bad. But unless you have a particular reason to do that, I wouldn't mix ecosystems. Java and Scala are interoperable but they have different ecosystems, I would avoid adding Java-isms if you are using Scala or Scala-isms and dependencies if you are running straight Java.
Jersey and Play are generally close for REST services. Neither really has any killer features over the other.
Jersey defines URL mappings in annotations, Play defines them in a service wide route file. And they bundle or have varying quality of integration with different libraries for things like XML, JSON, database, testing, mocking, dependency injection libraries and app server deployment.
The Java world has JMS, Spring, JUnit, jdbi/hibernate/jpa, Jetty/Grizzly. The Scala world has Akka, specs2/ScalaTest, Anorm/slick. Jersey is a better fit for the first world, Scala for the second. You can definitely cross that, but it will be a little less elegant and might require more glue coding.
JAX-RS is a standard and implementations can be created by different vendors. Jersey is one such implementation. The other frameworks may make use of JAX-RS but are not standards. So it is not a one-to-one comparison.
I have never heard of Play before but it does look interesting, more akin to Rails and Django than Jersey. What I like about Jersey is that it can be integrated into existing Java web applications by simply adding the JARs and declaring some things in the web.xml. What I find confusing about Jersey and JAX-RS is the routing.
Play seems to make routing easier, however, correct me if I'm wrong, seems like it is an all-or-nothing framework and cannot be used alongside other servlets in the same web application.
I'm starting new project. The client interface is based on GWT (and GXT) I have no say it's predetermined. However I can pick and choose as far as server side so I can have some fun and hopefully learn something new in the process. Some requirements are :
Exchange with server will be through use of JSON, most if not all of UI will be generated by GWT (JS) on the client, so the client/serve exchange will be limited to data exchange as much as possible
No Hibernate (it's not really supported on the proprietary db I will be connecting to). In the past projects people would use JDBC or iBATIS
Some sort of IoC (I'm thinking Guice just to stick with Google)
Some sort of Security framework based on LDAP. In the past we would use Spring security (Acegi) but it wasn't ideal and we had to customize it a lot
So basically should I stick with tried-and-true Spring/Acegi or try something based on Guice? And what that "something" would be and how mature is it?
Have a look at Apache Shiro. It seems to be gaining ground, with no reference to Spring.
If you'd like to do IOC on client and server, go with Guice. You can use Guice on the server, and its brother GIN on the client.
Since nether of the above answers gave me any practical ideas (or almost any) here's formula I ended up with:
Maven + GXT + GWT and Guice + iBaGuice