I am trying to set up Jersey with JAX-RS for my RESTful web application but I am overwhelmed by the amount of options.
I'm currently working in Eclipse and deploying to an Apache Tomcat 7 server. I'm using Maven to manage the project dependencies. I am also very new at this.
The Jersey options are very vague in their descriptions and I'm wondering if someone who has been here before can advise me on which dependency/package I need.
Jersey-Maven Page: https://jersey.java.net/documentation/latest/modules-and-dependencies.html
If you do not have a good reason to use Tomcat, I suggest that you use a fully compliant Java EE container such as Wildfly instead. That way you will have all the Java EE API:s available out of the box, and you will not have to worry about downloading the right version of libraries and so on.
Related
When starting a new JavaEE Project in IntelliJ you are prompted to include either Implementations or Specifications in your project. Can anyone explain whats the difference here, lets say in context to Hibernate/JPA
Usually, if you develop with a full featured Java/Jakarta EE application server, like GlassFish you only need to add dependency on specification JARs and the application server will provide their implementations.
Different application servers provide different set of supported Java EE standards. For instance, GlassFish provides almost everything while Tomcat provides servlet-api and websocket-api and that's it.
If you choose more lightweight server, like Tomcat, to develop and deploy you should choose Java EE libraries (implementations) because Tomcat will not provide you JPA or JMS library.
Full list of Jakarta specifications (APIs): https://jakarta.ee/specifications/
I am required to pick up java (with basic previous experiences) + 1 specific application framework, having spending most of my times in Python and Django. Chose Spring mainly due to my requirements.
May I know what could be the equivalent of Django's development server in Java so I can easily run and check my Java code?
You can deploy a web app using Spring to any Java EE app server. I'd say that the simplest choice would be Tomcat, the Apache servlet/JSP engine.
I would also suggest Jetty which is a lightweight servlet container like Tomcat, but keep in mind the problems regarding deployment of Java EE applications mentioned in this thread Can Jetty be used as a Java EE lightweight application server?.
Another alternative is Glassfish.
If you are working with netbeans then Glassfish is a good fit since there is very good integration between the two.
I've been working with web services in .NET for years, but am new to java-based web services. I have some background working on web applications (struts, faces), but it's been a few years. I need to develop a set of web services which will be deployed to Websphere 6.1 (Java SDK 1.5). Ideally, I'd like to develop using Eclipse (Indigo SR 1 - Java EE) and test in Tomcat (Tomcat 6). I'm familiar with these tools and have them installed. I'm planning on starting with the contract (WSDL) which I've written in Eclipse.
Where should I go from here? I think I need to somehow generate POJOs with JSR 181 annotations. How do I generate them from Eclipse (or should I use a different tool)? What needs to happen so that Tomcat and Websphere will discover the web service classes in my WAR and make them available as web services?
I was hoping to find a tutorial to walk me through this, but I'm not really sure what I'm looking for. I suspect that there are many ways to do this. I'm looking for an approach that will work well in Websphere 6.1 (Java 1.5) but will be easy to develop in Eclipse using Tomcat.
I have a very small Java codebase that I would like to expose as a REST service that responds in JSON format (to be used by a Ruby on Rails project).
I have only notions about Java web servers / web frameworks. What would be:
a. a suitable Java MVC and
b. a java server
to ease my deployment? I am interested in:
easy to build(wrap) the solution
easy to maintain / configure the server
stable (not experimental)
We use CXF extensively. It is very simple standard JAX-RS annotation based. There is a good tutorial to set it up quickly. It works with or without Spring, but easier with spring, this is my preference. The other option would be Spring REST it is very similar to Spring MVC which is very easy if you know spring already, but on the other hand it is not JAX-RS based.
you might want to give Grails a try - it:
shares some similarities with RoR
comes bundled with an application server so it's very easy to get up and running
allows very simple deployment to a Java application server (e.g. Tomcat, Jetty)
has built-in support for JSON
has recent stable releases
is under active development
http://www.restlet.org/
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
https://github.com/dhanji/sitebricks (my favorit)
For the server part of the problem, build your code so that it is a servlet and then deploy in a container like Tomcat or Jetty. (There are many others too, but Tomcat and Jetty work very well and are pretty easy to use.)
For the framework, I'd recommend CXF (I've had good success with it in my project) as it keeps the amount of configuration you need to write small (typically just add annotations to mark which methods are to be exposed; the annotations are standardized as JAX-RS), but many others are valid choices too.
We are looking at which REST framework to use and where to run it.
Given an existing WebSphere (6.1.0.17) environment would you use Jersey of Wink?
Or would you recommend a different platform?
As a third option why not use Spring's own RESTful features in Spring MCV. This is easy to code, test and maintain and (obviously) works for Spring right out of the box. The ease of managing code based on Spring REST is due to an architecture based on MVC, IoC and annotations. And you can choose best in class solutions to enhance your solutions such as XStream for serialization, Jackson JSON Support, and Springs own REST Template for a REST Client or unit-tests.
At its heart Spring MVC's REST features deal with REST as an Architecture not a Protocol and blends it well with other proven approaches such as IoC and MVC. When considering a framework the following REST litmus test is useful: see innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html.Springs approach checks more of the boxes, thanks to it's effective content delivery.
One thing all these frameworks fall down on is HATEOAS support, a way of in which the REST response contain links that correspond to all the actions that the client can currently perform from this resource. Most frameworks promises to introduce this soon, but a critical eye will be needed to understand what the best approach to this will be.
When delivering JAX-RS solutions such as Wink and Jersey, I've found more emphasis on conforming to a Java standard and less flexibility in the architecture (such as using other 3rd party packages). If conforming to JAX-RS is a requirement consider Restlets, Wink or Jersey. Otherwise, maybe it's worth considering Spring MVC's REST support.
I've deployed this kind of solution to WAS 7 without any issues or dependency conflicts.
I have no experience in using Wink, but I can share some of my experience in using Jersey running on Websphere.
The pros... very easy to use, it took me 5 minutes to get familiarized and I'm ready writing my first hello world. Jersey does automatically generate WADL for you based on your Resources package, albeit pretty basic... but you can customize the WADL documentation yourself.
The cons... sigh, I like Jersey, but with Websphere, it almost made me cry. First (this is not related to Websphere), I'm using Spring in my project and the Jersey release I use is 1.2. The problem is that release uses Spring 2.5 whereas I'm using Spring 3.x. So, I pulled out Jersey's Spring 2.5 to use Spring 3.x. Everything works fine. However, the Jersey test framework started to fail. I'm not able to boot up the built-in Grizzly server to test my web services anymore. Second, I'm currently tied to Websphere 6.1 which uses JDK 5. I believe all Jersey releases after 1.2 are compiled with JDK 6... that means, I'm out of luck until my company upgrade to WAS 7.
It is indeed a very stable Rest framework, very easy to use... but in my case, I'm just bummed out because all existing unit tests for the web services are currently commented out because I upgraded my Spring release to 3.x. I'm sure the latest Jersey release should be using Spring 3.x by now, yet I can't use them because I'm still using JDK 5 in WAS 6.1.
So, it's up to you to decide. By the way, I'm still using Jersey 1.2 in my project running in WAS 6.1.
On websphere 6.x the prefered method is jersey because it is easier to implement and it supports JAX-RS 1 and 2. (Watch out for the JVM version issues, Websphere 6 might not support the latest version)
Now starting in Websphere 8.x IBM introduced Apache Wink that will actually bring dependency and classloader issues if used together with jersery (because of the same interface implementations for JAX-RS 1 and 2).
There are a lot of examples on how to overcome this issues and make it work but I don't believe is worthy and perhaps Wink will have a better performance within websphere.
IBM recommends to use Apache wink. In fact, IBM has his own implementation of Apache wink.
I vote for Wink.
The reasons:
It's developed by HP and IBM guys. So I believe that IBM guys tested it with Websphere.
Actually AFAIK Wink is built-in in the Websphere 7.*
Also see this video