申明： 强烈建议在阅读本文之前先阅读一下N. Alex Rupp老兄的文章，如果你赞同他的看法，可能你会觉得研究Struts就没什么意义了。

说明：本文所讲的Struts知识基于Struts 1.1版本，除非特别说明，本文中的Struts都特指Struts 1.1这个版本。

目录：

精细之处一：“利用Token解决重复提交”背后的前提
精细之处二：页面流转控制中的职责分配

精细之处一：“利用Token解决重复提交”背后的前提

我们知道，可以利用同步令牌（Token）机制来解决Web应用中重复提交的问题，Struts也给出了一个参考实现。服务器端在处理到达的请求之前，会将请求中包含的令牌值与保存在当前用户会话中的令牌值进行比较，看是否匹配。在处理完该请求后，且在答复发送给客户端之前，将会产生一个新的令牌，该令牌除传给客户端以外，也会将用户会话中保存的旧的令牌进行替换。这样如果用户回退到刚才的提交页面并再次提交的话，客户端传过来的令牌就和服务器端的令牌不一致，从而有效地防止了重复提交的发生。对应于这段描述，你可能会在你的Action子类中有这么一段代码：

if (isTokenValid(request, true)) {
// your code here
return mapping.findForward("success");
} else {
saveToken(request);
return mapping.findForward("submitagain");
}

其中isTokenValid()和saveToken()都是org.apache.struts.action.Action类中的方法，而具体的Token处理逻辑都在org.apache.struts.util.TokenProcessor类中。Struts中是根据用户会话ID和当前系统时间来生成一个唯一（对于每个会话）令牌的，具体实现可以参考TokenProcessor类中的generateToken()方法。

不知道大家有没有注意到这样一个问题，因为Struts是将Token保存在Session的一个属性中，也就是说对于每个会话服务器端只保存而且只能保存一个最新Token值。对于这一点，我的同事就提出了疑问：那如果我在同一个会话中打开两个页面，那么后提交的那个页面肯定不能提交成功了。他还给出了一个实际的例子：比如现在需要把两个客户A和B的地址都改为某个值，那用户就可能同时打开两个页面，修改A，修改B，提交A，提交B，按照Struts中的处理逻辑，B的修改提交就肯定不能成功，但是这个提交操作对于用户来说并不存在操作不正确的地方。

在这里，可能有人要问：怎么可能在同一个会话中打开两个页面呢？重新打开一个IE浏览器不是重新开始了一个会话吗？不错，这种情况下是两个会话，不存在任何问题。但是，你还可以通过菜单“文件”－“新建”－“窗口”（或者快捷键Ctrl+N）来复制当前窗口，这个时候你会发现该页面与原有页面同处在一个会话当中。其实，能够发现这个问题得归功于我的那位同事对IE习惯性的操作方法。

这下我的那位同事不满意啦，他于是开始动手修改Struts中的实现方式，让每个页面（至少某类页面）在服务器端都保存有一个唯一的Token值。这样，前面所讲的客户A，B同时修改的限制就不存在了。但是不久，我的那位同事就开始意识到他正在走向一条危险的道路。首先，如果每个页面都在服务器端保存一个Token值，则服务器端保存的数据量将越来越大。而且，如果考虑这种同一个会话中打开多个页面的情况的话，就好像打开了潘多拉魔盒，将会给自己带来无穷无尽的麻烦。比如，首先打开页面P1，然后利用Ctrl+N得到页面P2，P1提交，P2提交，目前为止一切正常。但是如果此时，在P1，P2中点击“后退”按钮，然后再提交P1， P2呢，情况会是怎样？如果在P2中提交完后执行其它操作，而在P1中回退后提交，情况又是怎么样呢？如果有P1，P2，P3，那情况又是如何呢？太复杂啦！我想你也会和我们有同感，你需要考虑许多种可能的组合，而且有的时候结果并不是你想象中的那样简单。

此路不通，还得回来看看Struts。其实经过以上一番折腾，我们可以发现在Struts中的Token机制背后隐藏着这样一个前提：不允许你（客户端）在同一会话中打开多个页面。注意是同一会话，如果打开两个IE浏览器，那已经是两个会话啦，不受该限制。其实，这个看似不合理的规定却自有其道理：一是它极大地简化了Token的实现，二个这种限定也符合大部分人的使用习惯。

精细之处二：页面流转控制中的职责分配

我们知道，Struts的执行过程大致如下：首先，控制器接收到客户端请求，将这些请求映射至相应的Action，并调用Action的execute方法，这中间可能还涉及到ActionForm的创建和填充。Action的execute方法执行完以后，返回一个ActionForward对象，控制器根据该ActionForward对象将请求转发至下一个Action或JSP。最后，产生视图响应客户。在大的层面上，Struts是采用了MVC这种架构，没什么特别之处。但从一些小的地方，我们还是可以看出Craig R. McClanahan老兄的一些考虑。我们看到Action与控制器之间传递的是ActionForward对象，由于Action的execute方法要求返回一个ActionForward对象，所以你会经常在Action子类中看到如下语句：

return (new ActionForward(mapping.getInput()));

或

return (mapping.findForward("success"));

其实返回的就是一个ActionForward对象。在Action中我们根据程序执行的不同情况，决定接下来的页面走向（比如返回到输入页面或者转到下一个页面），并将这些信息保存在ActionForward对象中。而接下来控制器就可以直接利用该ActionForward对象来进行页面的流转。下面是org.apache.struts.action.RequestProcessor类的processForwardConfig()方法的摘录，该方法调用发生在Action实例调用后。

protected void processForwardConfig(HttpServletRequest
request,
HttpServletResponse
response,
ForwardConfig forward)
throws IOException, ServletException {
…

String forwardPath = forward.getPath();
String uri = null;

// paths not starting with /
should be passed through without any  processing
// (ie. they're absolute)
if (forwardPath.startsWith("/")) {
uri = RequestUtils.forwardURL(request, forward);
// get module relative uri
} else {
uri = forwardPath;
}
if (forward.getRedirect()) {
// only prepend context path for relative uri
if (uri.startsWith("/")) {
uri = request.getContextPath() + uri;
}
response.sendRedirect(response.encodeRedirectURL(uri));
}
else {
doForward(uri, request, response);
}
}

注意： ForwardConfig是ActionForward的父类

该方法首先调用ForwardConfig的getPath()方法获得下一步流转的路径，在某些条件下还需要进行一些拼装得到正确的URI，最后根据该URI进行页面跳转。可见在processForwardConfig()方法中只是对ActionForward进行了一些“技术上”的处理，没有任何和业务相关的内容，这样就将控制器（ActionServlet）和Action完全分开来，两者互不影响，达到了功能模块之间松散耦合的目的。

模块间（系统间）松散耦合一直是OO设计所追求的，但是具体如何去实现这样一种松散耦合却不是那么容易做到的。Struts中的设计给了我们一些启示：模块间相互关联影响因素的传递可以用对象的形式来包装起来。其实，个人觉得Struts中的做法还可以稍微有一点点改进，就是在ActionForward中提供一个getURI()方法来给出最终的URI岂不是更好？

参考：

1、Beyond MVC: A New Look at the Servlet Infrastructure

2、Allen Holub的Build user interfaces for object-oriented systems系列文章,可以从这篇文章中学到很多面向对象设计方面的知识，虽然作者并不认为MVC是一种面向对象的方法，但是我们这些MVC的实践者仍然可以从中学到面向对象的知识。

3、Struts 1.1的介绍性文章：深入Struts 1.1

4、Apache Struts Website

5、关于重复提交问题的讨论及其解决方案，可以参考《Core J2EE Patterns》一书（中文版《J2EE核心模式》）。

Deepak Alur,John Crupi,Dan Malks: Core J2EE Patterns－Best Practices and Design Strategies

1．Portal用例
读者可以在下面三个网站上注册自己的用户，体会Portal的功能。
http://my.msn.com
http://my.yahoo.com
http://my.liferay.com

My MSN的功能最灵活强大，用户可以任意拖放操作栏目(column)和内容版块(content)的位置和个数。
My Liferay只能选择固定的栏目(column)布局，但可以在本栏目(column)内移动内容版块(content)的位置。
My Yahoo只能选择固定的栏目(column)布局，而且不能移动内容版块(content)的位置。

Portal的结构分为三层。
(1) Page
(2) Column，或者称为Pane
(3) Content，或者称为Portlet

我们来看看Portal的整个操作流程。
(1) 每个Column的下方都有一个[Add Content]按钮，让用户选择加入自己喜欢的内容。
从这里，我们知道，Portal系统里面有一个公用的Common Portlet Repository，供用户选用。

JSR168 Portlet规范里面定义了Portlet Deployment Discriptor。Common Portlet Repository以这个Portlet Deployment Discriptor的格式存放。

开源项目JetSpeed的XReg文件用来存放Common Portlet Repository的定义。

(2) 加入Content之后，用户的Page和Column里面就多了这个Content。下次用户登陆的时候，就会看到自己订制的Portal版面。
从这里，可以看出，Portal系统会纪录用户的个人Portal配置信息 � User Portal Config。

开源项目JetSpeed的PSML文件用来存放User Portal Config的定义。

——- 综上。
Add Content的整个流程为：
Common Portlet Repository –> Add Content –> Personal Portal Config

Display Portal的整个流程为：
从Personal Portal Config读取用户配置的Portlet ID –> 根据Portlet ID，从Common Portlet Repository查找详细的Portlet定义 –> 根据这个详细的Portlet定义显示这个Portlet。

2．Portal实现
我们考虑如何用Java来实现Portal。

2.1 Dynamic Include
首先，我们采用最简单的思路，我们用100个JSP文件(1.jsp, 2.jsp, 3.jsp, … 100.jsp等)，代表100个Portlet。
用户页面MyPage.jsp包含用户选定的多个Portlet。
现在，假设用户选取的Portlet为1.jsp, 3.jsp, 7.jsp等3个Portlet，那么我们如何在MyPage.jsp中显示这些Portlet？最直观的做法是，用jsp:include。比如：

由于<jsp:include>只能指定固定的jsp文件名，不能动态指定jsp文件名。我们需要把<jsp:include>翻译为Java code � RequestDispatcher.include();
下面我们换成这种写法。

进一步改进MyPage.jsp。

其中的fileNames的内容可以各种各样，只要RequestDispatcher能够处理。
比如Velocity，fileNames = {“1.vm”, “3.vm”, “7.vm”};
比如URL，fileNames = {“/portlet1.do”, “/portlet3.do”, “/portlet4.do”};
我们可以看到，如果我们从用户配置中读取fileNames的内容，这就是一个简单的Portal实现。

2.2 Portlet Interface
下面我们来扩展这个例子。
假设每个Portlet都规定实现一个Portlet接口。

上述代码是Portal显示Portlet的核心流程的一个简化版本。
JSR168 Portlet规范里面定义了真正的Portlet接口定义。

2.3 Portlet Action
Portlet的操作包括，最大化/最小化/恢复/关闭/编辑/帮助/上下移动，等等。
这些操作都有对应的Action类。
开源项目JetSpeed的module/actions/controls目录下面包含Maximize, Minimize, Close等Action类。
开源项目Liferay的portal/action目录下面包含Maximize, Minimize, Close等Action类。

Portal的操作不仅包括上述Portlet的操作，而且包括其它更高级别的操作。
比如，Add/Move Page, Add/Move Column, 换Layout, 换Skin，之类。

2.4 Portlet Cache
我们操作Portlet的时候，往往只操作某个特定的Portlet，或者只是变化Portlet的位置。这时候，页面中大多数的Porlet的内容是不变的，只有一小块Portlet变化。
我们需要把Portlet的内容缓存起来。Portlet接口有一个render(request, response)方法，我们可以订制定制response类，截获portlet的输出，保存到Portal系统的内容Cache当中。
比如，前面提到liferay开源项目，其StringServletResponse类把Portlet的输出保存到一个String当中。

• (一蓑烟雨任平生)Portal Server的机制与一般的Web Framework是独立的，Portal Server有自己的容器或者引擎来对Portlet进行处理，每个Portlet类似于Servlet。Portlet现在有两种标准，一种是以Jetspeed为主的老版本，IBM的Websphere Portal Server原先的核心API也采用Jetspeed的API，另一种是目前JCP组织制订的JSR 168标准，BEA和IBM都在自己的产品里实现了该标准，但还没有成熟。IBM的WSAD开发工具里对Portal有两种项目类型，分别支持这两种标准。

  可以将Portal做为表现层的一种类型集成到你的Web Framework中。

• (一蓑烟雨任平生)Jetspeed是一个门户的应用管理系统，应用程序是构建在Turbine这个Web Framework上面的，可以认为Jetspeed是个用Turbine Framework开发的一个应用程序。
• (whitehorse)portal 包括 portal server 和 portlet container ;JSR-168定义了portlet 通用api ，portlet container 的提供商需要遵循这个API,这样开发出的portlet 可以在任何一个实现jsr-168规范的portlet container下顺利移植。
  portal server 是各个开发商自行提供的，用来接受用户用求转发给相应的portlet，调整portal page 布局，单点登录等等;
  portlet container就是在servlet container上又包装了一层，portlet 类似于servlet;
  portal server 的实现一般采用 web framework 技术来构建； 比如liferay采用了struts + tiles;exo poral 采用了 jsf 等等。portlet开发在遵循规范的基础上可以采用web framework .
• (kingkii)free portal server: Jetspeed, liferay, Jportal, etc
• (flyisland)

• baichenhong 写道:

  我觉的Portal的作用就是整合，故名意思 门户 嘛就是把所有的集成起来放到一起，你有oa,erp,crm 但是你觉得分开使用很不方便，那么好我可以把他们整合到一起，只要你登陆一次就可以使用所有的系统，这应该是一个很有用的东西

  你短短一句话包含的东西可是超级多。

  所谓集成分为很多层次的，Portal关注的是用户集成，包括访问界面、访问手段等。访问界面的集成并不要求应用程序一定要部署在一起。

  至于“只要你登陆一次就可以使用所有的系统”，一般称之为单点登陆“Single Sign-on”。Portal服务器基本都提供了认证框架，在此框架下开发的新应用实现SSO是很简单的；但如果对异构的系统进行SSO，这又是一个复杂而庞大的话题了。

• (tommy_kin)拖放布局不是Portal的核心技术，只是一个personalize的功能而已，Portal功能在于应用的集成。所谓一站式访问。

• javaeye论坛内关于Portal讨论的连接
  http://forum.javaeye.com/viewtopic.php?t=5506&highlight=Portal
  http://forum.javaeye.com/viewtopic.php?t=4413&highlight=Portal
  http://forum.javaeye.com/viewtopic.php?t=5159&highlight=Portal
• 主流企业门户应用性能评测
  http://www2.ccw.com.cn/04/0430/d/0430d31_1.asp几种Portal技术的比较与评述
  http://www.ccw.com.cn/cio/research/info/htm2004/20040813_13UNG.asp

  4款EIP软件评测揭晓
  http://www.zdnet.com.cn/bizstrategy/eb/tech/story/0,3800029745,39156*043,00.htm

  How the portals scored
  http://www.infoworld.com/article/04/04/30/18FEportalbl_1.html

  Enterprise Portals Suites
  Portal Power
  http://www.networkcomputing.com/shared/article/printFullArticle.jhtml?articleID=18900467

• 远程门户网站 Web 服务（WSRP）
  http://www-900.ibm.com/developerWorks/cn/webservices/ws-wsrp/index.shtml
• Portlet技术发展的思考
  http://www.blogbus.com/blogbus/blog/diary.php?diaryid=204304
  WSRP实践&想法
  http://www.blogbus.com/blogbus/blog/diary.php?diaryid=117666
  Portal展现机制研究
  http://www.blogbus.com/blogbus/blog/diary.php?diaryid=357938
• Enterprise Portals Suites
  Portal Power
  http://www.networkcomputing.com/shared/article/printFullArticle.jhtml?articleID=18900467

创建人：王艺
创建时间：2003年6月15日星期日

第一步：
对象的可视范围：request、session、application、page。
Request：在一个请求周期内有效。就是从你点击页面上的一个按钮开始到服务器返回响应页面为止（包括响应页面）。
Session：在一个用户与服务器建立连接的整个过程中有效。
Application：在整个web应用程序内有效。
Page：仅在一个jsp页面内有效。

第二步：
ActionForm在你确定的有效期（可视范围）内是唯一的。

第三步：
在每次为ActionForm赋值前调用它的reset方法。作用是使ActionForm中的值恢复初始状态。在应用中我们可以通过在reset中为变量赋初值的方式，使得页面上的某个对象有显示值。

第四步：
可视范围与赋值前的初始化结合。
由于第二步所述特性，如果可视范围是request，则reset方法并不是很重要，因为你每次调用时都会产生一个新的ActionForm实例，所以你所操作的ActionForm不会与别人分享同时也就不会受别人的影响；如果可视范围是session，由于在session范围内此ActionForm是唯一的，所以你在session范围内需要用到此ActionForm的地方调用的都是同一个ActionForm，要是你没有在reset中对变量赋初值那么前一次调用ActionForm是为它赋的值将在此次调用时有效，这到也没什么。但是，如果恰巧再次调用时你仅仅需要为ActionForm中的一部分变量赋值，那么其余的变量将保持上一次得到的值，这样你就得到了一个“新旧混合体”，我想这多半不是你所期望的；如果可视范围是application，那其影响就更是不难理解了，这时不但是你自己会影响你自己，使用应用的其他用户的操作也会影响到你。

第五步：
知道了reset方法的作用和ActionForm在scope内唯一的特性后就为我们灵活处理ActionForm的行为提供了基础。比如说你现在需要跨过多个页面收集数据信息，这时你就可以把scope设置为session，并且不实现reset方法��这样在每个页面put数据时都不会将之前收集的数据清空，最后在你收集完数据后在Action中调用ActionForm中你自定义的初始化方法，如：resetField。
在具体的我也想不出了，还是要大家在应用时多多体会这些特性，这样才能把架构的威力发挥到最大。

CSS制作标签卡Tab效果

亚马逊网站应该不会陌生吧？对它页面上方标签卡（Tab）方式的导航条（如下图）还有印象么？

__

__amazon.com这种方式得导航引起了相当多人的效仿。那么，它是如何做到的呢？有过网页设计经验的人应该不难明白，如果不知道细节的话，通过察看源代码就能知道，它实际上是通过在表格中插入事先制作好的作为标签卡的图片来制作的，标签卡的效果通过颜色来控制，比如上图中的“YOUR STORE”这张图片和底下子栏目的颜色一致，背景都为深蓝色，这样看上就向一张卡片了。

__不过，现在网页设计的趋势是XHTML+CSS来完成。那么，如果不用图片加表格的方法，有没有办法仅仅利用CSS来制作呢？有的，可以通过项目列表的CSS设定来做到。

__

__这张图，就是利用这种方法来制作的。

__下面，我们就分别来学习CSS的标签卡制作。

利用列表元素制作标签卡

__通常情况下，项目列表的排列方式是垂直的，并在前头带有特定的项目符号，如下：

• 项目列表一
• 项目列表二
• 项目列表三
• 项目列表四

__它所对应的HTML代码是这个样子：

__<ul>
<li>项目列表一</li>
<li>项目列表二</li>
<li>项目列表三</li>
<li>项目列表四</li>
</ul>
__那是否你曾想到过，项目列表也可以不垂直排列，而是水平分布呢？在Html中无论如何是做不到这点的。可是CSS却提供了这种方法。

__首先，我们把项目列表放入到div标记中，如下：

__<div id=”horizonlist”>

__<ul>
<li>项目列表一</li>
<li>项目列表二</li>
<li>项目列表三</li>
<li>项目列表四</li>
</ul>

__</div>

__然后，我们为这个id为horizonlist的Div设定如下样式：

#horizonlist {//*设定div的Box属性*//
border: 1px solid #000;
margin: 2em;
width: 80%;
padding: 5px;
font-family: Verdana, sans-serif;
}

#horizonlist ul, #horizonlist li {//*设定限制于horizonlist的div内的ul和li的属性*//
display: inline;
margin: 0;
padding: 0;
color: #339;
font-weight: bold;
}

__此样式作用于所给项目列表的结果如下：

__可以看到，此时的项目列表成了水平放置，而且列表前的符号自动消失。之所以这样，关键在于属性display的设置值inline的作用。display用来改变元素的显示值，可以将元素类型线上，块和清单项目相互变换，其中取值inline的作用是“删除元素前后的分行符，使其并入其它元素流中”。在这里，inline取消了每个列表项目后的换行，而成为一行显示。

__顺着这个思路下去，如果我们给每个列表项目设定Box属性，那不就有了类似标签卡的效果出来了么：

__我们来看看这个例子的代码：

__<div id=”tabdemo”>
<ul>
<li>项目列表一</li>
<li>项目列表二</li>
<li class=”selected”>项目列表三</li>
<li>项目列表四</li>
</ul>
</div>

__和上面的例子不同，这里的项目列表三多了类名“selected”，用来表示当前被选中的标签卡。

__相应的CSS属性设定如下：

__#tabdemo ul li {
margin-left: 0;
margin-bottom: 0;
padding: 2px 15px 5px;
border: 1px solid #000;
list-style: none;//*不显示列表符号*//
display: inline;//*取消项目之间的分行*//
background-color: #ffc;
}

#tabdemo ul li.selected {//*设定被选中的列表的效果*//
border-bottom: 1px solid #fff;
background-color: #fff;
list-style: none;
display: inline;
}

__如果你希望每个标签卡之间有一定的距离，可以修改#tabdemo ul li此设定中的margin-left属性值，比如改为2，就可以看到类似早先给出的那张蓝色标签卡的样子。

__接下来我们来进一步修饰上面这个标签卡，先来看效果果。

__可以看到，每个标签卡之间不再紧贴一起，底下出现了一条连续的横线，当鼠标移动到每个标签卡的时候，出现了浮动的效果。

__一起来分析一下代码：

__<div id=”container”>

<ul id=”beautytab”>
<li><a xhref=”http://blogger.org.cn/blog/#” mce_href=”http://blogger.org.cn/blog/#” class=”selectedtab”>标签卡一</a></li>
<li><a xhref=”http://blogger.org.cn/blog/#” mce_href=”http://blogger.org.cn/blog/#”>标签卡二</a></li>
<li><a xhref=”http://blogger.org.cn/blog/#” mce_href=”http://blogger.org.cn/blog/#”>标签卡三</a></li>
<li><a xhref=”http://blogger.org.cn/blog/#” mce_href=”http://blogger.org.cn/blog/#”>标签卡四</a></li>
</ul>

</div>

__这个标签卡放在id为container的块div中。列表的id为beautytab，其中的列表项目标签卡一设定了一个类“selectedtab”，表示当前被选的标签卡类。

__对应的CSS设定如下：

__#container
{//*设定包含列表的div的Box属性*//
width: 500px;
padding: 30px;
border: 1px solid #ccc;
background: #fff;
}

#beautytab
{//*设定项目列表Ul元素的属性，其中background用来设定连贯于各个列表项目下的横线，否则它们会彼此分离，用了一张事先准备好的图片，让它放置在底部，水平重复*//
height: 20px;
margin: 0;
padding-left: 10px;
background: url(’/Upload/editor/bottom.gif’) repeat-x bottom;
}

#beautytab li
{//*设定各个列表项目的属性，display属性设定取消项目间的分行，list-style-type设定取消列表项目前的符号*//
margin: 0;
padding: 0;
display: inline;
list-style-type: none;
}

#beautytab a:link, #beautytab a:visited
{//*设定标签卡中超链接的文字的属性*//
float: left;
background: #f3f3f3;
font-size: 12px;
line-height: 14px;
font-weight: bold;
padding: 2px 10px 2px 10px;
margin-right: 4px;
border: 1px solid #ccc;
text-decoration: none;
color: #666;
}

#beautytab a:link.selectedtab, #beautytab a:visited.selectedtab
{//*设定当前被选中的标签卡中超链接的属性*//
border-bottom: 1px solid #fff;
background: #fff;
color: #000;
}

#beautytab a:hover
{//*设定超链接鼠标浮动效果*//
background: #fff;
}
__如果手头上有漂亮的修饰图片，我们还可以进一步制作出类似下图的漂亮雅致的标签卡来。

__

__至于如何制作，用兴趣的人可以自己动手做做看。

Java打包详解

lightsword 于 2004年 10月08日 发表

兄弟，对java着迷吗，或者是为了自己的生计，不论怎样都欢迎你进入精彩java世界兄弟，对java着迷吗，或者是为了自己的生计，不论怎样都欢迎你进入精彩java世界，welcome！可能你刚刚对每个人说：Hello World！也或者……ok！这已经足够了。那就让我们开始吧，开始这个魔幻世界的旅程：

jar文件听说过吗，没有？或者陌生！好，没关系，这就是我们的第一站：打包发布。

为什么会有这个玩意呢，首先，这是jar的全称：JavaTM Archive (JAR) file，是的，就是java存档文件。这有点类似zip文件，想一想它是干什么的用的呢，压缩！？没错就是要压缩，将我们原先零散的东西放到一下，重新组织，所有这些目的只有一个：方便！好了，不用管他是怎么压缩的，我们的重点是哪些是我们要压缩的(输入)，还有压缩成了什么(输出)，进而将它发布(部署)。

那我们的输入(要压缩的东西)主要是class文件，还有辅助的资源(这其中可能有图片，jsp文件，html文件等等)。Jar技术在jdk1.1版本中就已存在，在1.2中又有了增强。接下来说说jar的好处吧，这是官方的描述：安全，快速下载，压缩，猎取包，版本化包，可携。

说了这么多，我们现在开始实施。

先打开命令提示符(win2000或在运行筐里执行cmd命令，win98为DOS提示符)，输入jar �help,然后回车(如果你盘上已经有了jdk1.1或以上版本)，看到什么：

用法：jar {ctxu}[vfm0Mi] [jar-文件] [manifest-文件] [-C 目录] 文件名 …

选项：

-c 创建新的存档
-t 列出存档内容的列表
-x 展开存档中的命名的（或所有的〕文件
-u 更新已存在的存档
-v 生成详细输出到标准输出上
-f 指定存档文件名
-m 包含来自标明文件的标明信息
-0 只存储方式；未用ZIP压缩格式
-M 不产生所有项的清单（manifest〕文件
-i 为指定的jar文件产生索引信息
-C 改变到指定的目录，并且包含下列文件：

如果一个文件名是一个目录，它将被递归处理。

清单（manifest〕文件名和存档文件名都需要被指定，按’m’ 和 ‘f’标志指定的相同顺序。

示例1：将两个class文件存档到一个名为 ‘classes.jar’ 的存档文件中：
jar cvf classes.jar Foo.class Bar.class

示例2：用一个存在的清单（manifest）文件 ‘mymanifest’ 将 foo/ 目录下的所有文件存档到一个名为 ‘classes.jar’ 的存档文件中：
jar cvfm classes.jar mymanifest -C foo/ .

来个小例子试试看：
我们只有一个HelloWorld，如下：

public class HelloWorld{
public static void main(String[] args){
System.out.println(“Hi, Hello World!”);
}
}

我将这个java文件存到C盘跟目录下，ok，接下来，

在先前打开的命令提示符下(跳转到C盘提示符下)，我们输入javac HelloWorld.java，然后继续输入：jar cvf hello.jar HelloWorld.class，回车后去你的C盘看看，多了什么，没错 hello.jar 。

基本的步骤我们现在都知道了，你可以自己去尝试一下随着jar后面的参数的不同，结果有什么变化。

紧接着我们看看如何运行我们的jar包。

在进入正题之前，你要先打开我们刚刚做好的jar包看看，多了什么呢，META-INF目录？再看看里面是什么，还有一个MANIFEST.MF文件是不是？用文本编辑器(我这里是UltraEdit)打开它看看：
Manifest-Version: 1.0
Created-By: 1.4.2 (Sun Microsystems Inc.)

就是这样。这里我们对它进行修改，加一句：Main-Class: HelloWorld (在第三行)。这个就是我们之前写的那个类，也就是我们的入口类。也即，
Manifest-Version: 1.0
Created-By: 1.4.2 (Sun Microsystems Inc.)
Main-Class: HelloWorld

接下来，我们在命令提示符里执行：
jar umf MANIFEST.MF app.jar

这样我们使用了我们自己的MANIFEST.MF文件对原来默认的进行了更新。你不妨可以再进去看看是不是添上了Main-Class: HelloWorld这一句。

Ok，这个最后的一步了，来验证我们做的一切，在命令提示符中输入：
java -jar hello.jar(执行)

出现了什么，��Hi, Hello World!
我们再来看看jar文件在tomcat中发布，注意：在tomcat中我们就不能再用jar这种格式，而改war格式，它是专门用于web应用的，其实整个过程下来基本上和jar是类似的：

先准备我们要打包的资源。

找到存放tomcat的webapps目录，进到其中，新建一个文件夹，这里命名为hello，再进去新建WEB-INF文件夹，再进去新建classes文件夹，此时我们也将我们唯一的servlet，HelloWorld.java放到这里，在与classes目录同级下建立一文件web.xml。Ok，目前我们初步建立了一个简单的web应用。

在命令提示符下进到先前创制的hello目录下，执行 jar cvf hello.war * ，我们便得到hello.war。将它拷贝至webapps目录下，ok，来看最后一步，打开tomcat的目录conf中的server.xml，加入：
reloadable=”true”/>
大功告成！运行它，启动tomcat，后在浏览器中输入http://localhost:8080/hello/HelloWorld，有了吗？

好了，就这么多，希望对你有点帮助。

补充：
############

jar基本操作：

############

1. 创建jar文件
jar cf jar-file input-file(s)
c—want to Create a JAR file.
f—want the output to go to a file rather than to stdout.
eg: 1)jar cf myjar.jar query_maintain_insert.htm
2)jar cvf myjar.jar query_maintain_insert.htm
v—Produces verbose(详细的) output.
3)jar cvf myjar.jar query_maintain_insert.htm mydirectory
4)jar cv0f myjar.jar query_maintain_insert.htm mydirectory
0—don’t want the JAR file to be compressed.
5)jar cmf MANIFEST.MF myjar.jar yahh.txt
m—Used to include manifest information from an existing manifest file.
6)jar cMf MANIFEST.MF myjar.jar yahh.txt
M—the default manifest file should not be produced.
7)jar cvf myjar.jar *
*—create all contents in current directory.
2. 察看jar文件
jar tf jar-file
t—want to view the Table of contents of the JAR file.
eg: 1)jar vft yahh.jar
v—Produces verbose(详细的) output.
3. 提取jar文件
jar xf jar-file [archived-file(s)]
x—want to extract files from the JAR archive.
eg: 1)jar xf yahh.jar yahh.txt(仅提取文件yahh.txt)
2)jar xf yahh.jar alex/yahhalex.txt(仅提取目录alex下的文件yahhalex.txt)
3)jar xf yahh.jar(提取该jar包中的所有文件或目录)
4. 修改Manifest文件
jar cmf manifest-addition jar-file input-file(s)
m—Used to include manifest information from an existing manifest file.

5. 更新jar文件

jar uf jar-file input-file(s)
u—want to update an existing JAR file.

C =F(N,I,A)

其中F(N,I,A)是N,I,A的一个确定的三元函数。如果把时间复杂性和空间复杂性分开，并分别用T和S来表示，那么应该有：

T =T(N,I,A) (2.1)

和 S =S(N,I,A) (2.2)

通常，我们让A隐含在复杂性函数名当中，因而将（2.1）和（2.2）分别简写为

T =T(N,I)

和 S =S(N,I)

由于时间复杂性和空间复杂性概念类同，计算方法相似，且空间复杂性分析相对地简单些，所以下文将主要地讨论时间复杂性。

下面以T(N,I)为例，将复杂性函数具体化。

根据T(N,I)的概念，它应该是算法在一台抽象的计算机上运行所需的时间。设此抽象的计算机所提供的元运算有k种，他们分别记为O₁,O₂ ,..,O_k；再设这些元运算每执行一次所需要的时间分别为t₁,t₂,..,t_k 。对于给定的算法A，设经过统计，用到元运算O_i的次数为e_i，i=1,2,..,k ，很明显，对于每一个i，1<=i<=k，e_i是N和I的函数，即e_i=e_i(N,I)。那么有：

(2.3)

其中t_i，i=1,2,..,k,是与N,I无关的常数。

显然，我们不可能对规模N的每一种合法的输入I都去统计e_i(N,I),i=1,2,…,k。因此T(N,I)的表达式还得进一步简化，或者说，我们只能在规模为N的某些或某类有代表性的合法输入中统计相应的e_i , i=1,2,…,k，评价时间复杂性。

下面只考虑三种情况的复杂性，即最坏情况、最好情况和平均情况下的时间复杂性，并分别记为T_max(N )、T_min(N)和T_avg(N )。在数学上有：

(2.4)

(2.5)

(2.6)

其中，D_N是规模为N的合法输入的集合；I ^*是D_N中一个使T(N,I ^*)达到T_max(N)的合法输入，是D_N中一个使T(N,)到T_min(N)的合法输入；而P(I)是在算法的应用中出现输入I 的概率。

以上三种情况下的时间复杂性各从某一个角度来反映算法的效率，各有各的用处，也各有各的局限性。但实践表明可操作性最好的且最有实际价值的是最坏情况下的时间复杂性。下面我们将把对时间复杂性分析的主要兴趣放在这种情形上。

一般来说，最好情况和最坏情况的时间复杂性是很难计量的，原因是对于问题的任意确定的规模N达到了T_max(N)的合法输入难以确定，而规模N的每一个输入的概率也难以预测或确定。我们有时也按平均情况计量时间复杂性，但那时在对P(I)做了一些人为的假设（比如等概率）之后才进行的。所做的假设是否符合实际总是缺乏根据。因此，在最好情况和平均情况下的时间复杂性分析还仅仅是停留在理论上。