RestEasy 是正确的选择吗？
在 JAX-RS 实现中，RestEasy 似乎是最难获得帮助的。如果您查看 SourceForge 上该项目的邮件列表存档，您会发现几乎没有一个问题得到解答，或者至少我还没有看到一个得到解答的问题。在 JBoss 社区网站上，有关该项目的讨论很少。
难道是个没人要的孩子？我开始认为选择它作为我们项目的 JAX-RS 实现是一个错误。
Of the JAX-RS implementations it seems RestEasy is the most difficult to get help for. If you look at the mailing list archive for the project at SourceForge you will notice almost none of the questions are answered or at least I have not seen one that was answered. On the JBoss community site there is very little discussion regarding the project.
Is it an unwanted child? I am starting to think it was a mistake choosing it as the JAX-RS implementation for our projects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个很好的实现，但由于这是 JBOSS (RED)，他们需要资金来支持，因此没有支持。由于它支持 JAX-RS 规范，因此应该很容易切换。只需一点点努力:-)
It is a good implementation BUT since this is JBOSS (RED) they want money for support and hence no support. Since it supports the JAX-RS spec it should be easy to switch. Just a little effort :-)
Resteasy 在查找 Provider 的方式上存在问题。就我而言，我的 REST-Client 必须是 WAR1（部署在服务器 1 上），与部署在服务器 2 上的 WAR2 中的 RESTful 实现进行通信。
我遇到的大问题是 ResteasyProviderFactory 尝试扫描所有 jars 中的 Provider 并注册它们。 IO 操作（类加载器上的 getResource()）锁定了服务器进程中的几个 JAR 文件，因此 WAR1（客户端）的取消部署失败
希望这会有所帮助
Resteasy has problems in the way Providers are looked up. In my case, my REST-Client had to be WAR1 (deployed on server1) talking to RESTful implementation in WAR2 deployed on server 2.
The big problem I had was that ResteasyProviderFactory tries to scan all the jars for Providers and registered them. The IO operations (getResource() on Classloader) locks couple of JAR files in the server process because of which the undeployment of WAR1 (client) was failing
Hope this helps