jetty的基本架构
Jetty 的基本架构
Jetty 目前的是一个比较被看好的 Servlet
引擎，它的架构比较简单，也是一个可扩展性和非常灵活的应用服务器，它有一个基本数据模型，这个数据模型就是
Handler，所有可以被扩展的组件都可以作为一个 Handler，添加到Server 中，Jetty 就是帮你管理这些 Handler。
Jetty 的基本架构
下图是 Jetty 的基本架构图，整个 Jetty 的核心组件由 Server 和Connector 两个组件构成，整个
Server 组件是基于 Handler 容器工作的，它类似与 Tomcat 的 Container 容器，Jetty 与 Tomcat
的比较在后面详细介绍。Jetty 中另外一个比不可少的组件是Connector，它负责接受客户端的连接请求，并将请求分配给一个处理队列去执行。
图 1. Jetty 的基本架构Jetty 中还有一些可有可无的组件，我们可以在它上做扩展。如 JMX，我们可以定义一些 Mbean 把它加到 Server 中，当Server 启动的时候，这些 Bean 就会一起工作。
图 2. Jetty 的主要组件的类图从上图可以看出整个 Jetty 的核心是围绕着Server 类来构建，Server 类继承了 Handler，关联了
Connector 和 Container。Container 是管理 Mbean 的容器。Jetty 的 Server 的扩展主要是实现一个个
Handler 并将 Handler 加到 Server 中，Server 中提供了调用这些 Handler 的访问规则。
整个 Jetty 的所有组件的生命周期管理是基于观察者模板设计，它和Tomcat 的管理是类似的。下面是 LifeCycle 的类关系图每个组件都会持有一个观察者（在这里是 Listener 类，这个类通常对应到观察者模式中常用的 Observer 角色，关于观察者模式可以参考《Tomcat系统架构与设计模式，第2部分:设计模式分析》一文中关于观察者模式的讲解）集合，当 start、fail 或 stop 等事件触发时，这些 Listener 将会被调用，这是最简单的一种设计方式，相比 Tomcat 的 LifeCycle 要简单的多。Handler 的体系结构
前面所述 Jetty 主要是基于 Handler 来设计的，Handler 的体系结构影响着整个 Jetty 的方方面面。下面总结了一下 Handler 的种类及作用：
图 3. Handler 的体系结构（查看大图）Jetty 主要提供了两种 Handler 类型，一种是 HandlerWrapper，它可以将一个 Handler
委托给另外一个类去执行，如我们要将一个 Handler 加到 Jetty 中，那么就必须将这个 Handler 委托给 Server
去调用。配合 ScopeHandler 类我们可以拦截 Handler 的执行，在调用Handler 之前或之后，可以做一些另外的事情，类似于
Tomcat 中的 Valve；另外一个 Handler 类型是 HandlerCollection，这个Handler 类可以将多个
Handler 组装在一起，构成一个 Handler 链，方便我们做扩展。
回页首Jetty 的启动过程
Jetty 的入口是 Server 类，Server 类启动完成了，就代表 Jetty
能为你提供服务了。它到底能提供哪些服务，就要看 Server 类启动时都调用了其它组件的 start 方法。从 Jetty
的配置文件我们可以发现，配置 Jetty 的过程就是将那些类配置到Server 的过程。下面是 Jetty 的启动时序图：
图 4. Jetty 的启动流程因为 Jetty 中所有的组件都会继承 LifeCycle，所以Server 的 start 方法调用就会调用所有已经注册到
Server 的组件，Server 启动其它组件的顺序是：首先启动设置到 Server 的 Handler，通常这个 Handler 会有很多子
Handler，这些 Handler 将组成一个 Handler 链。Server 会依次启动这个链上的所有 Handler。接着会启动注册在
Server 上 JMX 的 Mbean，让 Mbean 也一起工作起来，最后会启动Connector，打开端口，接受客户端请求，启动逻辑非常简单。
回页首接受请求
Jetty 作为一个独立的 Servlet 引擎可以独立提供 Web 服务，但是它也可以与其他 Web
应用服务器集成，所以它可以提供基于两种协议工作，一个是 HTTP，一个是 AJP 协议。如果将 Jetty 集成到 Jboss 或者
Apache，那么就可以让 Jetty 基于 AJP 模式工作。下面分别介绍 Jetty
如何基于这两种协议工作，并且它们如何建立连接和接受请求的。
基于 HTTP 协议工作
如果前端没有其它 web 服务器，那么 Jetty 应该是基于 HTTP 协议工作。也就是当 Jetty 接收到一个请求时，必须要按照 HTTP 协议解析请求和封装返回的数据。那么 Jetty 是如何接受一个连接又如何处理这个
连接呢？
我们设置 Jetty 的 Connector 实现类为
org.eclipse.jetty.server.bi.SocketConnector 让 Jetty 以 BIO 的方式工作，Jetty
在启动时将会创建 BIO 的工作环境，它会创建 HttpConnection 类用来解析和封装 HTTP1.1
的协议，ConnectorEndPoint 类是以 BIO 的处理方式处理连接请求，ServerSocket 是建立 socket
连接接受和传送数据，Executor 是处理连接的线程池，它负责处理每一个请求队列中任务。acceptorThread 是监听连接请求，一有
socket 连接，它将进入下面的处理流程。
当 socket 被真正执行时，HttpConnection 将被调用，这里定义了如何将请求传递到 servlet 容器里，有如何将请求最终路由到目的 servlet，关于这个细节可以参考《 servlet 工作原理解析》一文。
下图是 Jetty 启动创建建立连接的时序图：
图 5. 建立连接的时序图Jetty 创建接受连接环境需要三个步骤：
创建一个队列线程池，用于处理每个建立连接产生的任务，这个线程池可以由用户来指定，这个和 Tomcat 是类似的。
创建 ServerSocket，用于准备接受客户端的 socket 请求，以及客户端用来包装这个 socket 的一些辅助类。
创建一个或多个监听线程，用来监听访问端口是否有连接进来。
相比 Tomcat 创建建立连接的环境，Jetty 的逻辑更加简单，牵涉到的类更少，执行的代码量也更少了。
当建立连接的环境已经准备好了，就可以接受 HTTP 请求了，当Acceptor 接受到 socket 连接后将转入下图所示流程执行：
图 6. 处理连接时序图Accetptor 线程将会为这个请求创建ConnectorEndPoint。HttpConnection
用来表示这个连接是一个 HTTP 协议的连接，它会创建 HttpParse 类解析 HTTP 协议，并且会创建符合 HTTP 协议的
Request 和 Response 对象。接下去就是将这个线程交给队列线程池去执行了。
基于 AJP 工作
通常一个 web 服务站点的后端服务器不是将 Java 的应用服务器直接暴露给服务访问者，而是在应用服务器，如 Jboss
的前面在加一个 web 服务器，如 Apache 或者
nginx，我想这个原因大家应该很容易理解，如做日志分析、负载均衡、权限控制、防止恶意请求以及静态资源预加载等等。
下图是通常的 web 服务端的架构图：
图 7. Web 服务端架构（查看大图）这种架构下 servlet 引擎就不需要解析和封装返回的 HTTP 协议，因为 HTTP 协议的解析工作已经在Apache 或 Nginx 服务器上完成了，Jboss 只要基于更加简单的 AJP 协议工作就行了，这样能加快请求的响应速度。
对比 HTTP 协议的时序图可以发现，它们的逻辑几乎是相同的，不同的是替换了一个类 Ajp13Parserer 而不是 HttpParser，它定义了如何处理AJP 协议以及需要哪些类来配合。
实际上在 AJP 处理请求相比较 HTTP 时唯一的不同就是在读取到 socket 数据包时，如何来转换这个数据包，是按照
HTTP 协议的包格式来解析就是 HttpParser，按照 AJP 协议来解析就是Ajp13Parserer。封装返回的数据也是如此。
让 Jetty 工作在 AJP 协议下，需要配置 connector 的实现类为
Ajp13SocketConnector，这个类继承了 SocketConnector 类，覆盖了父类的 newConnection
方法，为的是创建 Ajp13Connection 对象而不是 HttpConnection。如下图表示的是 Jetty 创建连接环境时序图：与 HTTP 方式唯一不同的地方的就是将 SocketConnector 类替换成了
Ajp13SocketConnector。改成 Ajp13SocketConnector 的目的就是可以创建 Ajp13Connection
类，表示当前这个连接使用的是 AJP 协议，所以需要用 Ajp13Parser 类解析 AJP 协议，处理连接的逻辑都是一样的。如下时序图所示：基于NIO 方式工作
前面所描述的 Jetty 建立客户端连接到处理客户端的连接都是基于 BIO 的方式，它也支持另外一种 NIO 的处理方式，其中 Jetty 的默认connector 就是 NIO 方式。
关于 NIO 的工作原理可以参考 developerworks 上关于 NIO 的文章，通常 NIO 的工作原型如下：
Selector selector = Selector.open();
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking( false );
SelectionKey key = ssc.register( selector, SelectionKey.OP_ACCEPT );
ServerSocketChannel ss = (ServerSocketChannel)key.channel(); SocketChannel sc = ss.accept();
sc.configureBlocking( false );
SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ ); Set selectedKeys = selector.selectedKeys();
KETTLE 开源ETL软件】【安装配置与使用说明】 2015 年09 月
修订记录
目录 修订记录 (2) 1.安装与配置 (4) 1.1ETL 与K ETTLE概述 (4) 1.2K ETTLE的下载与安装 (7) 1.2.1Windows下安装配置 ............................................ Kettle 8 1.2.2Linux 下安装配置.................................................. Kettle 10 1.2.3Kettle 下安装..................................................... JDBC数据库驱动15 1.2.4下配置资源库连接 (15) 1.2.5Kettle 下 Hadoop Plugin 插件配置 (17) 2.KETTLE组件介绍与使用 (19) 2.1K ETTLE SPOON使用 (19) 2.1.1组件树介绍 (20) 2.1.2使用示例.......................................................... 1 23 2.1.3使用示例.......................................................... 2 37 2.1.4使用Kettle 装载数据到..................................... HDFS 48 2.1.5使用Kettle 装载数据到 (iv) 52 2.1.6使用 Kettle 进行 hadoop的 mapreduce图形化开发 (52) 2.2K ETTLE PAN的使用 (63) 2.3K ETTLE KITECHEN的使用 (64) 2.4C ARTE添加新的ETL执行引擎 (65) 2.5E NCR加密工具 (68)
一.Jetty 的基本架构 Jetty 目前的是一个比较被看好的 Servlet 引擎，它的架构比较简单，也是一个可扩展性和非常灵活的应用服务器，它有一个基本数据模型，这个数据模型就是 Handler，所有可以被扩展的组件都可以作为一个 Handler，添加到 Server 中，Jetty 就是帮你管理这些Handler。 整个 Jetty 的核心组件由 Server 和 Connector 两个组件构成，整个 Server 组件是基于Handler 容器工作的，它类似与 Tomcat 的 Container 容器，Jetty 与 Tomcat 的比较在后面详细介绍。Jetty 中另外一个比不可少的组件是 Connector，它负责接受客户端的连接请求，并将请求分配给一个处理队列去执行。 它的所有组件都是基于 Handler 来实现 Jetty 中还有一些可有可无的组件，我们可以在它上做扩展。如 JMX，我们可以定义一些Mbean 把它加到 Server 中，当 Server 启动的时候，这些 Bean 就会一起工作。 Jetty 可以基于 AJP 协议工作，在正常的企业级应用中，Jetty 作为一个 Servlet 引擎都是基于 AJP 协议工作的，所以它前面必然有一个服务器，通常情况下与 Jboss 集成的可能性非常大 Tomcat 和 Jetty 都是作为一个 Servlet 引擎应用的比较广泛，可以将它们比作为中国与美国的关系，虽然 Jetty 正常成长为一个优秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然难以撼动。相比较来看，它们都有各自的优点与缺点。 Tomcat 经过长时间的发展，它已经广泛的被市场接受和认可，相对 Jetty 来说 Tomcat 还是比较稳定和成熟，尤其在企业级应用方面，Tomcat 仍然是第一选择。但是随着 Jetty 的发展，Jetty 的市场份额也在不断提高，至于原因就要归功与 Jetty 的很多优点了，而这些优点也是因为 Jetty 在技术上的优势体现出来的。 架构比较 从架构上来说，显然 Jetty 比 Tomcat 更加简单
Eclipse插件——RunJettyRun的安装与使用 关于Jetty与Eclipse的集成，网上很多都是使用Eclipse的一个自动安装功能——Software Update。个人不太喜欢这种方式。这种安装方式有点问题：第一，需要网络流畅；第二，安装很慢。 所以，我选择手动安装的方式。只需要下载一个很小的jar包。 也许有人会说，MyEclipse不是已经以 Servers 的形式集成了Jetty了吗？就像Tomcat一样。 以插件的形式集成的Jetty的好处是：不用部署（deploy）项目，直接选中项目，右键 - Run As / Debug As 就可以运行。 话不多说。开始Jetty的HelloWorld之旅吧！ 下载 插件下载地址：runjettyrun_1.3.1.jar 安装 1、将下载的runjettyrun_1.3.1.jar文件复制到 D:\eclipse \plugins 目录下。 2、重启Eclipse。 3、菜单栏选择 Run Run Configurations，出现如下图的界面。可以看到，多了一个 Jetty Webapp 分支。
使用 1、新建一个 Web Project 。可取名 JettyTest 。 2、选中项目中的 Java EE 5 Libraries ，右 键 > Build Path > Remove from Build Path 。（注意：这个一定要删掉。不然项目启动不起来。）
3、在项目自动生成的 index.jsp 文件里，
标签中加入以下代码：Jetty Netty对比性能测试 测试工具：Apache2 ab 测试客户端：192.168.12.143 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz * 8 内存:16,406,980k total 测试服务器：192.168.199 CPU:Intel(R) Xeon(R) CPU E5520 @ 2.27GHz * 16 内存: 49,432,720k total JVM: java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode) JVM启动参数： -Xss128k -Xms2048m -Xmn1024m -Xmx2048m -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc -XX:+PrintGCDetails 其他： Netty: bossExecutor, workerExecutor均使用单独的CachedThreadPool启动：NioServerSocketChannelFactory(Executors.newCachedThreadPool(), Executors.newCachedThreadPool(); 业务交给单独的CachedThreadPool处理。 Jetty:版本：jetty-hightide-8.0.0.M2，默认配置。 AB:总共发送40000个请求。 并发量测试 无业务，返回数据小于1KB。并发与吞吐量：
jetty的基本架构 Jetty 的基本架构 Jetty 目前的是一个比较被看好的 Servlet 引擎，它的架构比较简单，也是一个可扩展性和非常灵活的应用服务器，它有一个基本数据模型，这个数据模型就是 Handler，所有可以被扩展的组件都可以作为一个 Handler，添加到Server 中，Jetty 就是帮你管理这些 Handler。 Jetty 的基本架构 下图是 Jetty 的基本架构图，整个 Jetty 的核心组件由 Server 和Connector 两个组件构成，整个 Server 组件是基于 Handler 容器工作的，它类似与 Tomcat 的 Container 容器，Jetty 与 Tomcat 的比较在后面详细介绍。Jetty 中另外一个比不可少的组件是Connector，它负责接受客户端的连接请求，并将请求分配给一个处理队列去执行。 图 1. Jetty 的基本架构Jetty 中还有一些可有可无的组件，我们可以在它上做扩展。如 JMX，我们可以定义一些 Mbean 把它加到 Server 中，当Server 启动的时候，这些 Bean 就会一起工作。 图 2. Jetty 的主要组件的类图从上图可以看出整个 Jetty 的核心是围绕着Server 类来构建，Server 类继承了 Handler，关联了 Connector 和 Container。Container 是管理 Mbean 的容器。Jetty 的 Server 的扩展主要是实现一个个 Handler 并将 Handler 加到 Server 中，Server 中提供了调用这些 Handler 的访问规则。 整个 Jetty 的所有组件的生命周期管理是基于观察者模板设计，它和Tomcat 的管理是类似的。下面是 LifeCycle 的类关系图每个组件都会持有一个观察者（在这里是 Listener 类，这个类通常对应到观察者模式中常用的 Observer 角色，关于观察者模式可以参考《Tomcat系统架构与设计模式，第2部分:设计模式分析》一文中关于观察者模式的讲解）集合，当 start、fail 或 stop 等事件触发时，这些 Listener 将会被调用，这是最简单的一种设计方式，相比 Tomcat 的 LifeCycle 要简单的多。Handler 的体系结构 前面所述 Jetty 主要是基于 Handler 来设计的，Handler 的体系结构影响着整个 Jetty 的方方面面。下面总结了一下 Handler 的种类及作用：
Jetty的首页地址是https://www.doczj.com/doc/0318615898.html,/jetty/，点击Downloads 进入下载介绍页面，由于Jetty7之后，托管服务有Eclipse接替，所以jetty6.1之前（包含6.1）继续由Codehaus提供下载服务，在该页面的下方有如下信息： 版本 Java HTTP Servlet JSP Status Notes Jetty-8 eclipse 1.6- HTTP/1.1 RFC2616 3.0 2.2 Development Standardized async Jetty-7 eclipse 1.5- HTTP/1.1 RFC2616 2.5 2.1 Almost stable org.eclipse.jetty Jetty-6.1 1.4-1.6 HTTP/1.1 RFC2616 2.5 2.1 or 2.0 Stable Async SSL, AJP, cometd, testing Jetty-6 1.4-1.5 HTTP/1.1 RFC2616 2.5 2.1 or 2.0 Deprecated Continuations, IOC, NIO, dynamic buffers, smaller, faster, better Jetty-5.1 1.2-1.5 HTTP/1.1 RFC2616 2.4 2.0 Stable J2EE 1.4 Compliance tested, optimizations, geronimo integration. Jetty-5.0 1.2-1.4 HTTP/1.1 RFC2616 2.4 2.0 Deprecated Schema, JettyPlus Jetty-4.2 1.2-1.4 HTTP/1.1 RFC2616 2.3+ 1.2 Mature JettyPlus Jetty-4.1 1.2-1.4 HTTP/1.1 RFC2616 2.3 1.2 Deprecated JAXP1.1, AJP13(mod_jk) Jetty-4.0 1.2 HTTP/1.1 RFC2616 2.3 1.2 Deprecated Jetty-3.1 1.2 HTTP/1.1 RFC2068 2.2 1.1 Ancient JMX Jetty-3.0 1.2 HTTP/1.1 RFC2068 2.2 1.1 Fossilized Jetty-2.4 1.1 HTTP/1.0 RFC1945 2.1 1.0 Legendary Jetty-1.0 1.0 HTTP/1.0 RFC1945 - - Mythical 本书讨论的Jetty版本是6.1，也是目前使用最多的稳定版本，我们到https://www.doczj.com/doc/0318615898.html,/jetty/jetty-6.1.22/下载6.1系列最新的6.1.22版本：
Jetty 源码分析 在文库看到一个关于jetty源码分析的PDF文档，发现该文档根本不全，遂在 网上又找到了关于此文档内容的网站，将其网页内容拷贝了出来，供大家浏览！ 一、总括 你了解Jetty 吗，就像我们所熟知的Tomcat一样, Jetty是一个免费的开放源码的100%纯Java的Http服务器和Servlet容器。 Jetty具备以下特点： 快速高效 。Jetty是最快的Servlet服务器之一 。Jetty可以处理上千个并发连接 小巧嵌入 。Jetty的jar只有600多K 。可动态嵌入到应用程序，适合开发web2.0等应用 应用广泛 。开源项目有Geronimo, JBoss, JOnAS等 。商业项目有IBM Tivoli, Sonic MQ and Cisco SESM等 可到Jetty网站 https://www.doczj.com/doc/0318615898.html,/jetty/查看最新信息 本文将通过对Jetty最新稳定版Jetty5.1.5RC2 源码的研究，向读者展示Jetty在设计方面使用的不同设计理念, 希望对广大开发者在设计自己的系统时有所帮助。 Jetty按照功能可以分为四个主个主要的部分,HttpServer, HttpContext,HttpHandler,HttpListener,详见如下类图:
<图1-1> 二、HttpServer及配置 对于初次接触Jetty的人一定会对上图感到迷惑，其实在Jetty中HttpServer是一个服务器的核心控制类, 我们可以看到，其它的组件类都是由该类扩展开来，HttpServer的作用就是在一系列的监听器类和处理器类之间搭起了一个桥梁,有效的控制着消息在系统内的传递,如下图: <图1-2 > HttpServer职责是接受从HttpListener传递过来的request(请求),HttpServer通过对request的Host(主机)或Path(路径)进行匹配,然后分发给相应的HttpContext(可以理解为一个web application)。
Java web入门之一：搭建JFinal框架 一、创建项目 1、启动eclipse，切换至java EE视图 2、创建Dynamic Web Project项目，项目名自定，示例项目名为webdemo，Target Runtime 选None，Dynamic web module version选择2.5
3、修改Default Output Folder，推荐输入WebRoot\WEB-INF\classes 特别注意：此处的Default out folder必须要与WebRoot\WEB-INF\classes目录完全一致才可以使用JFinal集成的Jetty来启动项目。
4、修改Content directory，推荐输入WebRoot 注意：此处也可以使用默认值WebContent，但上一步中的WebRoot\WEB-INF\classes则需要改成WebContent\WEB-INF\classes才能对应上。
5、放入JFinal库文件 将jfinal-1.9-bin-with-src.jar与jetty-server-8.1.8.jar拷贝至项目WEB-INF\lib下即可。注意：jetty-server-8.1.8.jar是开发时使用的运行环境，生产环境不需要此文件。
6、修改web.xml 将如下内容添加至web.xml
1、jetty下载地址 首页 https://www.doczj.com/doc/0318615898.html,/jetty/选择下载版本下载，下载下来之后解压 2、我是windows 启动命令java -jar start.jar etc/jetty.xml 默认8080 端口访问http://localhost:8080/test/test自带工程出现welcome页面 把自己的项目拷贝到D:\jetty-6.1.0\webapps （我的是d 盘，自己的位置自己改下）执行启动命令然后访问 制作Jetty bat启动文件 @ECHO OFF D: cd D:\jetty-6.1.0 echo 启动Jetty... pause java -jar start.jar etc/jetty.xml 3、Jetty服务配置etc\jetty.xml 修改访问端口：
第5章部署Web应用程序 当我们编写好一个web应用程序，如何交付给Jetty容器来运行呢？这也就是所谓“部署web应用程序”。 本章将介绍如何在Jetty中部署web应用，以及在Jetty的构架体系中是如何实现web应用部署的。 5.1 常用术语 为了使本章中讨论的内容能得到大家一致的理解，本节先明确一些专业术语，避免大家造成误解。 web应用程序（Web Application） 经常会说到这个词，大家也不难理解，就是由一组文件构成的集合，这些文件可能包含html文件、图像文件、java编译后的class文件，配置文件等等所有可能出现的文件。符合Servlet规范的应用程序还要求目录下存在一个WEB-INF的文件夹，在里面还必须存在一个web.xml的web部署配置文件，关于这个目录和web.xml的内容格式都是Servlet规范中定义的。根据Servlet规范我们还可以web应用程序整个目录打包成 war文件。 上下文（Context） 上下文是我们经常听到的词汇，可以使用在各种专业场合，但当我谈论web应用程序的时候，是这样的意思。 首先看一个名为Example的web应用程序的访问URL， https://www.doczj.com/doc/0318615898.html,/example /index.jsp。可以发现要访问这个Example应用，所有的路径都需要加前缀“/example”，换句话说，就是该应该的访问地址都符合 https://www.doczj.com/doc/0318615898.html,/example/* 这种模式。所有已https://www.doczj.com/doc/0318615898.html,/example/开头的请求都将有Example应用程序处理。 这就是上下文的概念了。有了上下文的概念后，一个web服务下就可以部署多套不同的web应用程序了，且不同的应用程序不会造成混乱。 上下文路径（Context Path） 在术语上下文的中，我们举例的“/example”就是上下文路径。同一个服务器下的不同的web应用就应该有不同的上下文路径。 注意：上下文路径必须以“/”开头，且不能以“/”结尾。
Jetty 9嵌入式开发手册 Jetty有一个标语，“不要部署你的应用在Jetty上，部署Jetty在你的应用中”。这意味着可选择使用Jetty捆绑你的应用作为一个标准 WAR进行部署。Jetty设计成一个软件组件，可以实例化并且使用在Java程序中，例如：如何POJO。但是另外一种方法，以嵌入式模式运行 Jetty，这意味着把HTTP模块放入到你的应用中，而不是把你的应用放入到HTTP服务中。 本教程引导你逐步从最简单的Jetty服务实例到使用标准部署描述运行多个Web应用。大部分示例的源代码是标准Jetty项目的一部分。 在学习该教程之前，完成一个HelloWorld教程是值得的。该教程可以在“嵌入式Jetty网络研讨会记录”中找到。 Jetty版本：本教程的代码来自于Jetty7，但是也应该在Jetty 8中可以使用。对于最新的稳定版本，参考最新发行版的链接代码。可能与本教程中给出的代码例子有稍微的不同。 概述 为了嵌入Jetty服务，通常执行下面的步骤： 1）创建一个服务 2）添加和配置连接器 3）添加和配置处理器 4）添加和配置Servlet、Webapp到处理器 5）启动服务 6）等待（join服务防止主线程退出） 创建一个服务 下面的代码来自于SimplestServer.jar，实例化和运行一个最简单的Jetty服务 https://www.doczj.com/doc/0318615898.html,/jetty/stable-9/xref/org/eclipse/jetty/emb edded/SimplestServer.html public class SimplestServer
SCA软件架构 一、SCA(Service Component Architecture)软件架构的概述SCA是一个开发SOA(Service-Oriented Architecture)面向服务应用的简单模型规范，它描述用于使用SOA构建应用程序和系统的模型。它可简化使用SOA进行的应用程序开发和实现工作。SCA仅仅是个规范，各个涉及SOA技术的公司的实现也各不相同。 SCA是由Open Service Oriented Architecture collaboration 提出的一种组件化的面向服务编程模型，并于2007年正式捐献给OASIS组织。 SCA提供了服务组件模型、装配模型和策略框架来支持各种异构应用的封装和集成。同SCA并列提出的SDO规范，定义了SOA应用程序中访问各种异构数据源的方法。组件可以以各种不同的协议发布服务，包括SOAP、RMI、REST、JMS，甚至可以是虚拟机内的对象直接调用。组件可以使用多种技术实现, 包括EJBs, Java POJOs ，Spring Beans，BPEL process ， COBOL ，C++， PHP … SCA中，最重要的一个概念是Service----服务，它的内涵是独立于具体的技术。因此，SCA不会称之为 Java组件架构，或Web Service 组件架构。所谓的具体技术，主要有两层含义：一是程序语言，而是传输协议。 现有的组件是和传输协议紧密耦合的。比如EJB组件采用的是RMI 传输协议，Web Service组件采用的是SOAP传输协议。SCA组件则能
自由地绑定各种传输协议。 SCA是对目前组件编程的进一步升华，其目标是让服务组件能自由绑定各种传输协议，集成其他的组件与服务。 SCA与传统的业务组件最大区别在于SCA实现了两个功能：一是组件和传输协议的分离，二是接口和实现语言的分离。 二、SCA规范基础知识 SCA编程模型是高扩展性和语言中立的，它易于被扩展为多种实现语言技术JAVA，C++，BPEL，PHP， Spring等，多种远程访问bindings 包括Web Service，JMS， EJB，JSON RPC等，多种主机环境例如Tomcat，Jetty，Geronimo，OSGI等。SCA分隔式架构可以使开发者更注重业务逻辑，而不必要关注诸如可靠性，安全，事务等系统属性，这些属性都配置到配置文件中。SCA的组成部分如下图所示： （1）Component
一、i-jetty简介 介绍： popular Jetty open-source platform.Having a "personal" webserver on your phone opens up a world of possibilities, letting you run your favourite existing webapps in your mobile environment. Moreover, as webapps developed for i-jetty have access to the Android API, this means that you can bring the contents of your mobile phone to your normal desktop browser. To demonstrate the possibilities, we've created a "Console" webapp that interfaces to the data on your mobile device. You don't need any special software to synchronize the mobile data to your desktop computer - the i-jetty console webapp makes your on-phone info like contacts lists, call logs and media instantly available and manageable via your browser. We've packaged the Console webapp as an Android application so it can be conveniently downloaded and updated via the Android Marketplace. i-jetty can also dynamically download webapps from anywhere on the net. To help get you started, we've also created a "Hello World" webapp that is simpler than the Console webapp. You can either build it from src and install it locally, or you can point i-jetty to the pre-built hello.war on the download page. The apks for i-jetty and the i-jetty Console webapp are both available from the Android Marketplace, and also from the download page.
IntelliJ+Maven+Jetty+Jrebel实现web项目java代码更改后热部署环境准备： IntelliJ IDEA 11.1.3 Maven 3.0.4 Jetty-maven-plugin 8.1.7.v20120910 Jrebel Plugin v1.5.2 1.安装maven 3.0.4 请参考网上安装教程。 2.安装IntelliJ IDEA 11.1.3 请参考网上安装教程。 3.安装Jrebel Plugin v1.5.2 3.1.打开Intellij IDEA Settings对话框，点击Browse repositories…
3.2.在左边插件列表中选择JRebel Plugin , 我安装的是v1.5.2版本，以下图片 是网上截图，一定要选择1.5.0+，后面会用到JRebel 5.0的破解包。 3.3.下载并安装JRebel Plugin v1.5.2插件
3.4.安装完后会要求你重启Intellij IDEA，你就重启好了。 3.5.重启后，验证是否安装成功。在项目上点击鼠标右键，出现的菜单中有 JRebel则代表安装成功。
菜单栏显示，如果要实现热部署必须以红框内的方式运行。 3.6.接下来替换插件自带的jrebel.jar，从网上下载jrebel5破解版的包【原因是 jrebel是收费的】，给几个下载地址 https://www.doczj.com/doc/0318615898.html,/download/dengqianyong/4473522 https://www.doczj.com/doc/0318615898.html,/blog/1589821 用下载的jrebel5破解版替换 C:\Users\Administrator\.IntelliJIdea11\config\plugins\jr-ide-idea\lib\jrebel 目录下的jrebel.jar文件 并删除C:\Users\Administrator\.jrebel目录下的所有内容 3.7.一定要选择红框中的其中一个运行，这样才能达到热部署的目的 4.用maven插件[jetty-maven-plugin]运行web项目
关于Apache/Tomcat/JBOSS/Neginx/lighttpd/Jetty等一些常见服务器的区别比较和理解 https://www.doczj.com/doc/0318615898.html,/allenlinrui/article/details/6675998 分类：各种容器2011-08-11 17:07 30人阅读评论(0) 收藏举报 今天是个很丰富的日子，早上一上班，第一个听到的惊爆消息就是楷子得了肠胃炎，一大早去医院挂水了…… 随后风胜和笑虎也没来，后来得知他们俩去去华星现代产业园参加培训，内容是关于Apache与Nginx的。于是乎，我非常感兴趣地查了一下培训用的PPT，并跟旁边的俊牧了解了一下关于服务器的一些东西…… 整个交流过程中，我发现好多概念已经被我遗忘了，有的也很模糊，于是乎，我还是决定到网上查一下，并记录下来！ 下面是令人纠结的正文…… 先说Apache和Tomcat的区别： Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。 在Apache基金会里面ApacheServer永远会被赋予最大的支持，毕竟大儿子最亲嘛，而Apache的开源服务器软件Tomcat同样值得关注，毕竟Tomcat是开源免费的产品，用户会给予最大的支持。但是经常在用Apache和Tomcat等这些服务器时，你总感觉还是不清楚他们之间有什么关系，在用Tomcat的时候总出现Apache，总感到迷惑，到底谁是主谁是次，因此特意在网上查询了一些这方面的资料，总结了一下。 解析一： Apache支持静态页，Tomcat支持动态的，比如Servlet等， 一般使用Apache+Tomcat的话，Apache只是作为一个转发，对JSP的处理是由Tomcat来处理的。 Apche可以支持PHPcgiperl,但是要使用Java的话，你需要Tomcat在Apache后台支撑，将Java请求由Apache转发给Tomcat处理。 Apache是Web服务器，Tomcat是应用（Java）服务器，它只是一个Servlet(JSP也翻译成Servlet)容器，可以认为是Apache的扩展，但是可以独立于Apache运行。
最受欢迎的Java框架介绍
17个最受欢迎的Java 框架：优点、缺点 Java 依旧是最受欢迎的编程语言。这里是如今被使用最多的Java 框架第一部分。 在2018年，Java 依旧是世界上最受欢迎的编程语言。它自带一个庞大的生态和全世界超过900万的Java 开发者。虽然Java 不是最简单的语言，但是你不必从零开始写Java 程序。这里有许多杰出的Java 框架可以编写运行在Java虚拟机上的web 和手机应用程序、微服务和REST API。 Java 框架允许你聚焦于你的app的业务逻辑，而不是编写如处理数据库连接或异常处理这样的基础功 能。此外，如果你有一些Java 的经验，你可以更快的开始。这些框架都使用相同的语法并且与相似的 条件、模型和概念工作。 我们前17 的Java 框架基于直到2018年的使用情况并按字母顺序排列展示的。这里是顶级Java 框架的第一部分。 Blade：极小占用的简单应用程序框架 Blade 是一个轻量级、高性能的Java 框架，它允许你用简单的方式快速构建web 应用程序。作者希望用户再一天内了解整个框架。因此，Blade 专注于简洁和优雅。 Blade 框架遵循MVC（模型-视图-控制器）软件设计模式。它有易于理解的设计，并且不依赖其他任何 第三方库或引入太多层。Blade 基于Java 8。Netty web服务器和模板引擎也内置于框架中。它占用极小，源代码总共小于500kb。
用Blade，你可以访问RESTful 风格的路有接口并可以将你的app 作为当作基础Maven 项目部署。Blade 也内置了安全功能。例如，它带有CSRF（跨站点请求伪造）和XSS（跨站点脚本）防御。它是 一个多功能框架，因为它自带插件扩展和webjar 资源的支持。其主站的文档是中文的。但是，它在 Github repo 也有英文文档。 Dropwizard：生产级RESTful Web 服务 Dropwizard 是一个高性能且简单的用于快速开发RESTful Web 服务的Java 框架。它特别适合创建 Java 微服务。 Dropwizard 框架汇集了一些成熟的Java 库，为你提供了快速且无干扰的开发平台。它自带了一个嵌入 式Jetty 服务器、Google Guava、LogBack、Hibernate Validator、Joda Time和许多其他流行的Java 库。此外，Dropwizard 还包含可用于构建RESTful Web 服务的Jersey 和用于处理JSON 的jackson。你可以将Dropwizard 想成一个独立的生态系统，包含了上述所有依赖捆绑为一个单独的包。 如果你选择Dropwizard，你将不必花费大量时间为如配置、监控、日志的辅助功能编写代码。相反， 你可以专注于你的app 的主要业务逻辑并达到最大生产率。这就是为什么Dropwizard 经常被称为操作 友好的Java 框架。如果你之前写过Java 那么入门不会很难；Dropwizard 的文档甚至有一个简单的 Hello World 示例，它可以帮助你完成第一步。 Grails：基于Groovy 的Web 应用程序框架
Maven Jetty Plugin 配置指南(翻译) Jetty 版本信息 Jetty7 - 此插件更名为jetty-maven-plugin，以便更符合maven2的协定。为了在Web 应用做快速应用开发做准备，详见多Web应用源目录。 为了在Jetty里运行一个Web应用，你如果按照Maven默认的做法构造(resources文件存放,${basedir}/src/main/webapp下Classes文件存放在${project.build.outputDirectory}下，web.xml的配置描述${basedir}/src/main/webapp/WEB-INF/web.xml)，你不需要配置任何其它东西。 只需输入：mvn jetty:run 这将在端口为8080的Jetty服务器上启动你的项目。Jetty将持续运行，直到插件是明确停止，例如，按下
Struts的原理和优点. Struts工作原理 MVC即Model-View-Controller的缩写，是一种常用的设计模式。MVC 减弱了业务逻辑接口和数据接口之间的耦合，以及让视图层更富于变化。MVC的工作原理,如下图1所示： Struts 是MVC的一种实现，它将Servlet和JSP 标记（属于J2EE 规范）用作实现的一部分。Struts继承了MVC的各项特性，并根据J2EE的特点，做了相应的变化与扩展。Struts的工作原理， 视图：主要由JSP生成页面完成视图，Struts提供丰富的JSP 标签库：Html，Bean，Logic，Template等，这有利于分开表现逻辑和程序逻辑。 控制：在Struts中，承担MVC中Controller角色的是一个Servlet，叫ActionServlet。ActionServlet是一个通用的控制组件。这个控制组件提供了处理所有发送到Struts的HTTP请求的入口点。它截取和分发这些请求到相应的动作类（这些动作类都是Action类的子类）。另外控制组件也负责用相应的请求参数填充Action From（通常称之为FromBean）,并传给动作类（通常称之为ActionBean）。动作类实现核心商业逻辑，它可以访问java bean 或调用EJB。最后动作类把控制权传给后续的JSP 文件，后者生成视图。所有这些控制逻辑利用Struts-config.xml文件来配置。 模型：模型以一个或多个java bean的形式存在。这些bean分为三类：Action Form、Action、JavaBean or EJB。Action Form通常称之为FormBean，封装了来自于Client的用户请求信息，如表单信息。Action通常称之为ActionBean，获取从ActionSevlet传来的FormBean，取出FormBean中的相关信息，并做出相关的处理，一般是调用Java Bean或EJB等。 流程：在Struts中，用户的请求一般以*.do作为请求服务名，所有的*.do请求均被指向ActionSevlet，ActionSevlet根据Struts-config.xml中的配置信息，将用户请求封装成一个指定名称的FormBean，并将此FormBean传至指定名称的ActionBean，由ActionBean完成相应的业务操作，如文件操作，数据库操作等。每一个*.do均有对应的FormBean名称和ActionBean名称，这些在Struts-config.xml中配置。 核心：Struts的核心是ActionSevlet，ActionSevlet的核心是Struts-config.xml。 Struts优缺点 优点： 1.开源软件，能更深入的了解其内部实现机制。 2.Taglib标记库，灵活动用，能大大提高开发效率。 3.页面导航使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。