Java RESTful Web Service实战（第2版） 1.4 Jersey项目概要

<b>1.4　jersey项目概要</b>

jersey是jax-rs标准的参考实现，是java领域中最纯正的rest服务开发框架。本节将带读者走近jersey的世界。

jersey项目是glashfish项目的一个子项目，专门用来实现jax-rs（jsr 311 &amp; jsr 339）标准，并提供了扩展特性。

<b>1.4.1　获得jersey</b>

jersey项目的地址是https://jersey.java.net。该网站同时提供了jax-rs和jax-rs2两个并行版本，分别是jax-rs1.1（截至本书发稿，最新版本是jersey1.19）和jax-rs2（截至本书发稿，最新版本是jersey2.22.1）。读者可以通过单击latest

jersey user guide获取和阅读最新版本的用户手册，这是官方发布的第一手参考资料。

jersey项目的下载地址http://jersey.java.net/download.html。该页面自上而下的内容分别如下。

jax-rs标准列表链接（jax-rs 2.0 api）。

jersey最新参考实现的jar包下载（jersey

jax-rs 2.0 ri bundle）。

jersey最新参考实现的示例代码下载（jersey

2.22.1 examples bundle）。

通过maven模板（archetype），使用jersey最新版本创建rest服务的命令。

jersey最新参考实现的模块和依赖（jersey 2

modules and dependencies）。

jax-rs1.1的参考实现包下载。

jersey源代码的托管地址是https://github.com/jersey/jersey，我们可以通过git命令，将jersey主干代码迁出到本地。示例如下。

git clone

https://github.com/jersey/jersey.git

<b>1.4.2　jersey问答</b>

stackoverflow是专业的程序员问答系统，jersey的问题列表地址是：http://stackoverflow.com/questions/tagged/jersey。该链接在jersey官网首页底部被列出，可见jersey对问答系统的重视。另外，邮件列表也是一种知识共享的途径，读者可以自行订阅，地址是：https://jersey.java.net/mailing.html。

<b>1.4.3　jersey项目管理</b>

jersey使用jira作为项目管理平台，相应的地址是：https://java.net/jira/browse/jersey。jira和stackoverflow不同的是，jira平台是jersey团队日常开发的管理平台，即jersey官方的缺陷管理平台，用于上报缺陷和改进意见，而不是社区性质的交流平台。通过这个平台我们可以从中了解到jersey项目的进展情况。jersey是一个非常活跃的项目，不仅可以从github源代码的提交活动中看到该项目频繁的更新，在jira中也可以看到该项目推进的速度。

这里为喜欢开源社区活动的读者举个例子。在撰写本书第1版的开始，jersey2.0并不支持与spring的集成，因为jersey的ioc容器由glashfish的另一个子项目hk2来支持。随后，我在jira上发现一个jersey2.x支持与spring集成的任务被创建了（https://java.net/jira/browse/jersey-1957），此后我经常观察其进展状态，最终看到了这个功能在jersey2.2中以扩展包的形式发布了。

因此，在使用jersey的过程中，如果读者遇到jersey本身的问题，可以跟踪jersey的jira平台检索、查看bug的修复状态，包括将在哪个版本修复，有什么样的临时解决办法（workaround）。同时，跟踪jira也可以了解新版本的发布情况，包括新增哪些功能，升级对哪一部分带来性能、安全的提升等。换句话说，jira展示了jersey项目的缺陷修复和新功能发版的计划（roadmap）。

<b>1.4.4　jersey许可</b>

开发者使用开源软件的前提是了解它的许可证版本，否则可能会带来侵权问题。相信在正规的公司，大家都有被开发管理部门的人“恐吓”的经历。开发者需感谢这样的团队所做的工作，他们为公司规避了商业侵权的风险，因为引用的源代码如果出自“传染性”许可，该项目是不能用于闭源的商业用途的。

jersey的许可证说明地址是：https://jersey.java.net/license.html。从中我们可以了解到jersey使用的是双许可证：cddl（common

development and distribution license，开源通用开发和分发许可证）1.1和gplv2（类路径例外）许可证。双重许可是依照两套（或更多套）不同的条款和条件分发相同软件的作法。在为软件授予双重许可时，接收人可以选择他们希望依照哪种条款获得软件。使用双重许可的两个常见动机是遵循商业模式和保持许可证兼容性。gplv2.0许可证为无法依照cddl许可证使用jersey的供应商提供了一个额外选项。jersey许可证使整套产品和包保持一致（glassfish项目同样依照cddl和gplv2（类路径例外）授予双重许可）。

阅读指南

类路径例外是由自由软件基金会的gnu/类路径项目制订的。它允许将依照任何许可证提供的应用程序链接到依照gplv2许可的软件中包含的库，而该应用程序不受gpl要求公开其本身的限制。

为什么需要使用类路径例外？因为作为“基于gpl程序的作品”的一部分提供的所有代码还应获得gpl许可。因此，需要指定gpl许可证例外的情况，以便明确将链接到gpl实现的任何应用程序从该许可要求中排除。类路径例外就实现了这一目的。

<b>1.4.5　jersey的模块</b>

jersey框架是由核心模块、容器模块、连接器模块、media模块、扩展模块、测试框架模块、安全模块以及glassfish bundle模块等8个大的模块组成。详情请读者浏览官方文档：https://jersey.java.net/documentation/latest/modules-and-dependencies.html。

jersey核心模块包括3个子模块，分别是通用包、服务器端实现包和客户端实现包。jersey提供了3种http容器，分别是grizzly2、jdk-http和simple-http，grizzly2同时提供了servlet容器。jersey客户端底层依赖于连接器来实现网络通信，如果标准的客户端模块功能不能满足业务需求，读者可以考虑引入grizzly连接器包或者apache连接器包。

jersey在2.6版本做了一次包重构，清除了对guava和asm的自然依赖。如果你的项目需要做jersey版本迁移，则需要注意这一点。新的包名为：jersey.repackaged.com.google.common和

jersey.repackaged.objectweb.asm。

<b>1.4.6　glashfish项目</b>

glashfish项目地址为https://glassfish.java.net。glashfish著名于世的是java ee服务器项目oracle

glassfish server，该项目还同时包含java ee中的一系列标准规范的参考实现，这些参考实现集成于glashfish server，为其java ee容器提供支持。其中对应jax-rs2的实现项目是jersey。

为什么要在jax-rs2的介绍中提及和罗列glashfish项目集呢？因为jersey处于glashfish生态环境中，glashfish又是java ee生态环境的参考实现。通过了解glashfish项目，我们可以更好地设计和实现rest服务。

这里所列的项目是除jersey以外，其他的glashfish项目，排列顺序并不严谨，大体上以其与jersey的紧密关系降序排列。

hk2项目：jsr-330参考实现，项目地址为http://hk2.java.net。hk2是轻量级di架构，实现ioc和di的内核。是jersey实现容器内管理bean的基础。

grizzly项目：中文直译为灰熊。jsr-356参考实现，项目地址为https://grizzly.java.net。grizzly是一个异步io的、高效而健壮的服务器，可以被用作http服务器、servlet容器，支持ajp、comet、websocket以及相对于restful的另一种web service实现（jax-ws）。

eclipselink项目：该项目实现了多个jsr标准，包括jsr-338/jpa2.1、jsr-222/jaxb2.2、jsr-235/sdo2.1.1、jsr-353/java

api for processing json。项目地址为http://www.eclipse.org/eclipselink。eclipselink是jpa2.1的一个实现，同时它还实现了其他的jsr作为扩展。jpa2.1是java ee 7的成员，是对jsr317（jpa2.0）的升级。jpa2.1的实现中，最常用的是jboss的hibernate，该项目从4.3开始实现jpa2.1。也就是说hibernate4.2是jpa2.0的最后一个版本。读者在开发的时候要注意依赖项目版本对标准的支持。jpa标准还有其他的实现，请参考http://en.wikipedia.org/wiki/java_persistence_api。

metro项目：该项目是jsr中多个标准的官方实现集，目的是实现全栈式的web service。包括jsr-224/jax-ws 2.2、jsr-222/jaxb2.2、jsr-206/jaxp 1.4.6、jsr-067/saaj1.3。项目地址为https://metro.java.net。metro项目中的多个标准作用各有不同。

jax-ws标准结合了xml-rpc，使用soap协议来实现web

service。在jax-ws的实现中，不可不提的另外两个实现分别是apache的cxf和axis。

wsit的前身是tango，是一种jax-ws和.net互操作的技术，实现了ws*标准。

saaj规范的作用是基于soap协议xml格式传递带附件的soap消息。

jaxp标准涵盖了java对xml过程式处理的诸多技术，包括dom、sax和stax，同时该标准定义了解读xml样式的xslt。

jaxb标准是java处理xml和pojo映射的技术，是jersey中处理传输数据的重要依赖。

open mq项目：地址https://mq.java.net。open mq是jms 2.0的参考实现。jsr-343是java ee 7的成员，旨在简化jms的api。关于消息队列的实现数量，恐怕是其他任何一个标准都望尘莫及的。几乎每一个有能力开发服务器软件、中间件的公司都有自己的mq，请参考http://en.wikipedia.org/wiki/message_queue。

mojarra项目：jsr-344/jsf2参考实现，项目地址为https://javaserverfaces.java.net。jsf是一种全栈式的、事件驱动的b/s开发模式框架，它包括浏览器端的丰富组件，服务器端覆盖java ee的各种特性。jsf相对于spring，借鉴了其核心思想ioc和aop，同时给出了标准规范。这有点类似jpa借鉴了hibernate的o/r mapping思想并标准化。jsf的另一个实现是apache的myfaces，当前版本为2.0.18。另外，jboss的richfaces是基于jsf的扩展中最为完善和常用的。更多有关jsf的内容和原理，请参考笔者的拙作《jsf2和richfaces4使用指南》。

openjdk项目：项目地址为http://openjdk.java.net。openjdk是开源的jdk，从版本1.7开始成为官方jdk的先行版本，因此是java开发者窥探java发展的第一线的最好资源，同时也是活跃的linux发行版本ubuntu和fedora等默认安装的jdk版本。

当前使用的jdk版本号的升级规则是从jdk5.0发布开始的，java升级发布一直采用两种方式发布更新。

有限升级（limited update）包含新功能和非安全修正。

重要补丁升级（critical patch update，cpu）只包含安全修正。

有限升级发行序号为20的倍数，即一个偶数；重要补丁升级顺延上一个cpu的版本号加5的倍数并取奇数（必要时加1）。

举例来说，下一个有限升级的版本号为7u40，那么接下来的3个cpu版本号依次为40+5=7u45，45+5+1=7u51和51+5=7u55。再下一个有限升级的版本号为7u60，随后的cpu版本号依次为7u65、7u71和7u75。

这种命名规则会为重要补丁升级保留几个版本序号，以便新的cpu版本号可以取区间值之和而不是在最新版本号上顺延。