Tomcat上开发Web应用如何保证兼容性

最近，协助伙伴将Tomcat上开发的应用向Apusic移植时发现了一个兼容性问题。

应用中代码为：HashMap params = （HashMap） requestgetParameterMap（）；

而getParameterMap（）在JCP规范中的定义为：public javautilMap getParameterMap（）

Returns a javautilMap of the parameters of this request Request parameters are extra information sent with the request For HTTP servlets， parameters are contained in the query string or posted form data请求的参数将返回一个javautilMap请求参数是请求发送的特别信息。对于HTTP servlets来说，参数包含在查询字符串或者发出的表单数据中。

Returns： an immutable javautilMap containing parameter names as keys and parameter values as map values The keys in the parameter map are of type String The values in the parameter map are of type String array一个不可更改的javautilMap包含参数名称（关键字）和参数值（映射值）。参数映射中的关键字是String类型。参数映射中的值是String数组类型。

可见规范中定义的返回值只是Map类型，而没有强制为HashMap Apusic在实现的时候也是Map作为返回值，而Tomcat返回时（参考orgapachecatalinaconnectorRequestjava）就是一个扩展自HashMap的ParameterMap类，因此开发时如何作为Map来用也不会出现问题，但是如果强制转换成HashMap就可能会与其他应用服务器产品无法正确兼容。

Tomcat是一款非常不错的开源Web服务器，许多公司在软件开发时都使用Tomcat作为Web容器，并且Tomcat也较好的对Servlet和JSP规范进行了支持，因此许多在Tomcat上开发的应用都可以向其他商业应用服务器上进行移植。

但是，Tomcat因为未去通过规范测试，因此可能会存在没有完全参考规范实现的部分，因此在开发中建议开发人员去上去下载一个规范来进行参考，开发过程中尽可能按照规范给定的参数和返回值来使用系统的核心功能，从而避免在移植中出现不必要的问题。

附注：出现问题也不可怕，总有许多方式可以解决，就如上文出现的Map与HashMap的问题。其实网上有许多Map向HashMap转换的代码，可以增加个过渡参数将得到的Map进行一次转换就可以不修改其他业务代码了。

tomcat严格上说是servlet和jsp容器，但也有人叫它服务器，这没什么不行，pageencoding是设定这个jsp用什么编码保存，默认是iso-8859-1，一般改成utf-8，便于网络传输，charset有点像一大堆编码的集合，可以对很多编码进行操作，这就是我对你的问题的理解

第一步：将C++项目放到tomcat的webapps路径下；

第二步：返回tomcat的上级路径，进入“bin”路径；

第三步：如果是windows系统选择“startupbat”，如果是linux等系统，选择“startupsh”；

第四步：打开浏览器，输入”http://localhost:8080/项目root“运行即可。

tomcat是一种web服务器，也可以称作运行在服务器（物理意义上的计算机）上的一种软件包。用来对服务器上的HTML文档提供访问权限控制。

以上的说法可能太专业化，一时难以理解。其实用通俗的语言来讲，万维网本质上就是“超文本文档”（HTML文档）组成的一个通过超级链接互相访问交互网络。你从甲计算机上的文档A通过超链接访问乙计算机上的文档B，而B必须放在Web服务器（Tomcat）里才能被访问。

Apache tomcat是一个强大的Web服务器

在处理静态页面、处理大量网络客户请求、支持服务的种类以及可配置方面都有优势，高速并且强壮。但是没有JSP/Servlet的解析能力。

整合Apache和Tomcat可以看作是用Tomcat做Apache的jsp/servlet解析插件，将两者优势结合起来

不过Tomcat作为一个Web服务器，本身具备了基本的Web服务功能，在SUN的力推下，将来或许越来越强壮到不需要借助Apache优势的地步。

（Jakarta Tomcat服务器是在SUN公司的JSWDK（javaServer Web DevelopmentKit,是SUN公司推出的小型Servlet/JSP调试工具）的基础上发展起来的一个优秀的Servlet/JSP容器，它是Apache-Jakarta软件组织的一个子项目。它不但支持运行Servlet和JSP，而且还具备了作为商业java Web应用容器的特征。）

IBM WebSphere 交付了应用基础设施和集成软件，用来帮助公司完成随需应变世界中的最关键任务：

快速创新的能力 - 灵活的操作环境能够轻松支持公司的业务增长。

更高的生产力 - 工具能够帮助公司流线化和扩展业务流程，以便为人员提供适时、适当的信息，从而提高员工的生产率。

改善的业务弹性 - 可靠的、高性能的应用基础设施支持今天的随需应变世界的 24x7 运转。

IBM WebSphere 软件交付了以灵活的方式集成分散应用程序和系统的能力，从而加速创造价值的进程，并帮助公司最大限度提高现有资源的利用率。

WebSphere软件平台的核心是WebSphere应用服务器，提供特定的配置来满足大范围的各种不同的重要应用的需要，包括事务管理、安全、集群、性能、可用性、连接性和可伸缩性。应用服务器是一个中间件，可以将Web应用功能和核心业务系统以及企业数据库连起来。WebSphere应用服务器提供了一个将这些应用和数据扩展到Web的平台。

WebSphere Business Integration Server Foundation扩展了WebSphere的功能，它提供了一个基于标准的整合平台，能够在面向服务的架构（SOA）中建立和部署复合的应用。复合的应用是通过其他的软件功能模块来建立的，通过Web 服务技术将它们整合到一起。在高性能的环境下，例如一个很大的大学的计算和信息系统实验室，也同样使用WebSphere Extended Deployment作为他们基础设施的一部分。

Tomcat和WebSphere的比较

1、 JAVA支持的对比

如果只是简单的将产品对J2EE的支持版本一一列出，我们可能发现两个产品好象区别不是很大。但是如果仔细分析一下二者细微的区别，我们会有许多有趣的发现：

1）Enterprise JavaBeans：EJB当前最新的版本是20。在WebSphere中，全部支持EJB11的规范，对于20中的规范支持大多数。而BEA号称全部支持20的规范。如果仅从版本号来看，好象BEA占了一些优势，其实不然。我们首先应该明白EJB到底是做什么用的。EJB是面向分步式应用、面向分布式事物处理的Java规范。如果我们回顾计算机应用的发展历史，会发现IBM在分步式应用、面向对象的理论、数据库的处理（无论关系型还是非关系型）等面向大规模的企业应用处理方面有着举足轻重的地位。IBM不但最早发明了关系数据库——DB2，而且有业界最早、应用最广泛的事物处理中间件——TXSeries（即CICS）。IBM承诺的是给用户提供稳定、可靠的产品，而不是一味地追求版本的变化。在J2EE的规范制定中，IBM参与了其中80%的技术工作，尤其是在关键的领域：JTA/JTS、EJB、Java Connector等方面。另外一个方面，IBM提供了强大的EJB开发、测试、部署工具——VisualAge For Java Enterprise Edition。它能帮助用户最快地开发出满足自己需要的EJB。为了简化EJB的开发，IBM提供了强有力的封装工具——Access Bean。反观BEA，对于J2EE规范的制定并没有做出什么贡献，虽然号称支持EJB20，但是它并不真正支持两阶段提交！而且不提供对CICS、IMS、SAP等主机资源CMP（Container-Managed Persistence）类型的EJB的支持

2、RMI/IIOP：该标准在EJB 11中是可选项，但在EJB 20中是必须实现的规范。IBM在WebSphere中提供了牢固的产品来完全支持，IBM的产品从JDK就开始使用RMI/IIOP，已经有进两年的时间，有很多成功的应用。BEA没有产品级的支持，在WebLogic中仅有一些有限的实现，它强迫用户使用其私有的协议——T3，因为它的速度比WebSphere慢了将近4倍，在其clustering中根本不能使用IIOP!

欢迎阅读《How Tomcat Works》这本书。这本书解剖了Tomcat4112和5018版本，解释了它的servlet容器的内部运行机制，那是一个免费的，开源的，最受欢迎的servlet容器，代号为Catalina。Tomcat是一个复杂的系统，由许多不同的组件构成。那些想要学习Tomcat运行机制的朋友大部分知道从何入手。这本书会提供一个蓝图，然后为每一个组件构造一个简化版本，使得可以更加容易的理解这些组件。在这之后才会对真实的组件进行解释。

你应该从这份简介开始阅读，因为它解释了这本书的结构，同时给你勾画了这个项目构造的简洁轮廓。“准备前提软件”这一节会给你一些指示，例如你需要下载什么样的软件，如何为你的代码创建目录结构等等。

本书为谁而作

这本书是为任何一个使用Java技术进行工作的人而准备的。

假如你是一个servlet/jsp程序员或者一个Tomcat用户，而且对一个servlet容器是如何工作这个问题你感兴趣的话，这本书就是为你准备的。

假如你想加入Tomcat的开发团队的话，这本书就是为你准备的，因为你首先需要学习那些已存在的代码是如何工作的。

假如你从未涉及web开发，但你对一般意义上的软件开发感兴趣的话，你可以在这本书学到一个像Tomcat一样的大型项目是如何进行设计和开发的。

假如你想配置和自定义Tomcat，你也应该读读这本书。

为了理解书中的讨论，你需要了解Java面向对象编程技术以及servlet编程。假如你对这些不熟悉的话，这里有很多书籍可以参考，包括Budi的《Java for the Web with Servlets, JSP, and EJB》。为了让这些材料更容易理解，每一章开始都会有便于理解所讨论主题的必要的背景资料介绍。

Servlet容器是如何工作的

servlet容器是一个复杂的系统。不过，一个servlet容器要为一个servlet的请求提供服务，基本上有三件事要做:

创建一个request对象并填充那些有可能被所引用的servlet使用的信息，如参数、头部、cookies、查询字符串、URI等等。一个request对象是javaxservletServletRequest或javaxservlethttpServletRequest接口的一个实例。

创建一个response对象，所引用的servlet使用它来给客户端发送响应。一个response对象javaxservletServletResponse或javaxservlethttpServletResponse接口的一个实例。

调用servlet的service方法，并传入request和response对象。在这里servlet会从request对象取值，给response写值。

当你读这些章节的时候，你将会找到关于catalina servlet容器的详细讨论。

Catalina架构图

Catalina是一个非常复杂的，并优雅的设计开发出来的软件，同时它也是模块化的。基于“Servlet容器是如何工作的”这一节中提到的任务，你可以把Catalina看成是由两个主要模块所组成的：连接器(connector)和容器(container)。在Figure I1中的架构图，当然是简化了。在稍后的章节里边，你将会一个个的揭开所有更小的组件的神秘面纱。

现在重新回到Figure I1，连接器是用来“连接”容器里边的请求的。它的工作是为接收到每一个HTTP请求构造一个request和response对象。然后它把流程传递给容器。容器从连接器接收到requset和response对象之后调用servlet的service方法用于响应。谨记，这个描述仅仅是冰山一角而已。这里容器做了相当多事情。例如，在它调用servlet的service方法之前，它必须加载这个servlet，验证用户(假如需要的话)，更新用户会话等等。一个容器为了处理这个进程使用了很多不同的模块，这也并不奇怪。例如，管理模块是用来处理用户会话，而加载器是用来加载servlet类等等。

Tomcat 4和5

这本书涵盖了Tomcat4和5这两者有一些不同之处:

Tomcat 5支持Servlet 24和JSP 20规范，而Tomcat 4支持Servlet 23和JSP 12。

比起Tomcat 4，Tomcat 5有一些更有效率的默认连接器。

Tomcat 5共享一个后台处理线程，而Tomcat 4的组件都有属于自己的后台处理线程。因此，就这一点而言，Tomcat 5消耗较少的资源。

Tomcat 5并不需要一个映射组件(mapper component)用于查找子组件，因此简化了代码。

设置好环境变量，不行先卸掉Tomcat，再卸掉JDK，重新再来一遍

可能性：你文件应该是在windows编辑好的，然后传到服务器上的吧，用ftp的时候记得用二进制的方式传输，ascii码容易出问题

用UEDIT32编辑文件，转化编码由xxx转为linux/unix