Apache 门户项目组介绍

Jetspeed的设计者之所以要自己实现这种链式模式而不直接使用Filter的可能原因有二：其一，Filter是标准Servlet规范定义的接口，使用上肯定受规范限制，为了获取更大的控制权和灵活度需要自己的Pipeline。其二， Application Server，由于每种应用服务器可能对Filter的实现和配置方法上有异，为了实现一个Jetspeed Portal能够在各种应用服务器上发布并运行，因而必须自己实现类似Filter的功能。

Container

讲到这里，我们必须首先理清楚Portal和Portlet Container之间的关系。Portal并不等价于Portlet Container，一个企业级的门户实现，可以包含或者说支持多种Portlet Container同时运行，例如IBM WebSphere Portal就既包含兼容JSR-168规范的Portlet Container又包含了支持一些IBM特有功能属性的Portlet Container；BEA WebLogic也是采用相同策略，既有其旧有的基于Struts技术的Portlet Container，又支持JSR-168标准。随着JSR标准规范进一步深化完善，如JSR-286规范定稿，也许这些大的Portal厂商会逐渐放弃其旧的架构，完全拥抱标准。

对于Jetspeed而言，它同样关注的是门户本身的实现，而不是Portlet Container的实现，但由于Jetspeed-2完全抛弃Jetspeed-1的架构，而决定彻底拥抱标准，因此Jetspeed只有一个标准的 Portlet Container实现，这就是Pluto项目。

Pluto的设计目标，其实既是一个完整的、自包含的轻量级门户，又是一个易于内置的Portlet Container。它不需要Jetspeed也能够单独工作，例如Apache唯一的应用服务器项目Geronimo就内置Pluto Portlet Container，作为它的Console实现平台。然而，这与Jetspeed的定位起了冲突。在2005年底的Apache Con上，门户项目组开发者齐聚一堂，就该问题作了深入的探讨，也许这两个项目在将来会更加关注于自身的技术领域。

Jetspeed所内置的Pluto版本为稳定的1.0.1版，它所提供的内置集成方式不如目前尚未正式发布的Pluto1.1版本丰富，因此 Jetspeed采用了Servlet 规范中的Cross Context Dispatch机制，将之集成了起来，这就是为什么Runtime架构图上，两者要用竖线分隔开来，因为他们其实是两个完全不同的Web应用，有着不一样的Context设置，之间通过Cross Context Dispatch机制联系起来的。因此当门户开发者需要在其它应用服务器上部署Jetspeed门户时，必须注意开启Cross Context Dispatch机制，也同时要注意这种使用方式所带来的安全问题。例如Tomcat是通过设置文件%TOMCAT_ROOT% /conf/Catalina/localhost/jetspeed.xml(注意粉红色高亮字体)：

<Context path="/jetspeed" docBase="jetspeed" crossContext="true"> <Realm className="org.apache.catalina.realm.JAASRealm" appName="Jetspeed" userClassNames="org.apache.jetspeed.security.impl.UserPrincipalImpl" roleClassNames="org.apache.jetspeed.security.impl.RolePrincipalImpl" useContextClassLoader="false" debug="0" /> <Resource name="jdbc/jetspeed" auth="Container" factory="org.apache.commons.dbcp.BasicDataSourceFactory" type="javax.sql.DataSource" username="" password="" driverClassName="org.apache.derby.jdbc.EmbeddedDriver" url="jdbc:derby:/tmp/j2" maxActive="100" maxIdle="30" maxWait="10000" /> <Valve className="org.apache.catalina.authenticator.FormAuthenticator" characterEncoding="UTF-8" /> </Context>

在Pluto和Jetspeed相互配合下，通过JetspeedContainerServlet，最终执行控制权会交给Portlet的实现类。JetspeedContainerServlet就定义在Portlet应用程序所属的Web应用单位中，也就是说所有在Jetspeed中运行的 Portlet Web应用都必须在Web.xml中包含JetspeedContainerServlet的定义。在Tomcat中，这是通过deploy-tool组件完成的，在其它应用服务器平台，很可能就要靠应用发布者手动添加了，需添加的信息包含：

<servlet> <servlet-name>JetspeedContainer</servlet-name> <display-name>Jetspeed Container</display-name> <description>MVC Servlet for Jetspeed Portlet Applications</description> <servlet-class>org.apache.jetspeed.container. JetspeedContainerServlet</servlet-class> <init-param> <param-name>contextName</param-name> <param-value>rss</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> <servlet-mapping> <servlet-name>JetspeedContainer</servlet-name> <url-pattern>/container/*</url-pattern> </servlet-mapping> <taglib> <taglib-uri>http://java.sun.com/portlet</taglib-uri> <taglib-location>/WEB-INF/tld/portlet.tld</taglib-location> </taglib>

Jetspeed Portlet Extension Service

前面介绍了实现架构和运行时架构，接下来我们一起来看看Jetspeed为Portlet应用提供的Jetspeed Service架构。如果了解JSR-168规范的开发者就会知道，这个规范是基于Servlet 2.3规范基础上的一个简单扩展，因此并没有对Portlet开发提供任何特别的支持。因而每家Portal厂商都提供了自己的扩展。

Jetspeed 提供的扩展方式跟很多厂商对Servlet规范的扩展一样，定义了一个名为jetspeed-portlet.xml的文件，作为标准的 portlet.xml的扩展。只要你在打包发布portlet应用时将这个文件与portlet.xml放在一起，Jetspeed的发布程序就会自动读取这个文件，并根据其内容执行一系列的操作。它们的关系如同BEA Weblogic应用服务器里面的weblogic.xml与web.xml；JBoss应用服务器里面的jboss-web.xml与web.xml。

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<