Compare each jax-rs to realize _web

As someone said elsewhere, there is a strange phenomenon about buses: You wait a long time, one is not coming, but at the end of the three cars. Jax-rs implementations seem to have encountered similar problems. At present we have:
The merging of Cxf--xfire and Celtix (an open source ESB sponsored by Iona, originally hosted on ObjectWeb). Jersey--sun Company's Jax-rs reference implementation. Resteasy--jboss's Jax-rs project. restlet--may be the first rest frame, it jax-rs before. Although there are various controversies surrounding rest, it is indisputable that JAX-RS provides the rest support required by the Java language. If you're new to rest, what kind of implementation would you choose? Well, Solomon Duskis tried to answer the question. "I would like to compare the implementations of each jax-rs with the following" pure "jax-rs," he said Dzone. These areas include:
Maturity of product
Service-Side integration policies
Java Client API configurable capability Security performance Solomon Duskis said, "Jersey is used as a reference implementation." Resteasy is a playground for new ideas. CXF is an ' Enterprise Edition ' supported by Iona. The Restlet project was created to add a RESTful API option. ”

However, Bill Burke countered in a blog comment: Resteasy is not just a playground for new ideas. In fact, we will soon support it in JBoss (a TCK can be), and many of our major customers are urging us to provide resteasy support. In terms of usability, Solomon Duskis said: "The problem you face is to choose an implementation." I think jersey is really easy to get started, but Bill Burke will say Resteasy is also very simple. They can all be used in conjunction with EJBS.

However, using jersey, it's easy to build and run test services, especially if you download NetBeans. The first time I used jersey and NetBeans, I tested and ran in less than half an hour, including downloads, installation, and code browsing. Sun's people want to distinguish jersey from the traditional view of "reference fulfillment":  you should think of Jersey as a product that can be immediately put into use when you talk about "product use" (in fact, next month it will be with GlassFish v3 Prelude Edition bundle released). The Jersey team spent a considerable amount of time testing and improving the code to avoid the impression that it was a "reference implementation." :) Solomon Duskis intends to study these areas and then publish the results in a blog. An article called "Jax-rs Spring Integration" has been published.   Today's four JAX-RS implementations provide spring integration, even for JBoss Resteasy. He then made a fairly brief introduction to integration. But as Paul points out, Solomon Duskis cited outdated information when he told Jersey. This is a pity, because what we need is a thorough comparison. Solomon Duskis finally said that:  four implementations have a fairly good spring/jax-rs capability, but I think CXF is "the best of Spring integration in Jax-rs products." But obviously this is only his personal opinion, others will certainly have different opinions. Bill Burke, for example, asks:  I don't see how cxf is superior to other products in spring integration. I don't understand why all the extra CXF dedicated XML is placed in a spring XML document. The spring integration provided by Resteasy and Jersey is less intrusive than cxf. If I'm not mistaken. In response, Solomon Duskis replied that:  if each class has a simple configuration to meet more than 90% of the needs, then the annotation-driven approach is feasible. With less than 10% left, the same resource needs to be configured differently on different occasions. I know that according to the requirements of the features I have updated with the current deployment, I will need this scenario. To deploy the same resource with different configurations (such as different JDBC data sources, different service implementations, and so on) through the same spring XML document, CXF provides additional functionality. Basically, the tagging approach is good in most cases, but sometimes you have to use an externally configurable approach to decoupling (decoupling). XML scenarios are not like annotationsare as popular as they are, but they can be used for more complex configuration scenarios.