Portlet是生成片段（遵守特定规范的标记语言（如HTML、XML）的片段）的Web组件。片段再合成一个完整的文档。本文介绍了关于Java Portlet的Java Specification Request (JSR) 168规范。它说明了如何使用BEA WebLogic Workshop 8.1 SP2来创建Java Portlet，以及如何将这些portlet部署到BEA WebLogic Portal 8.1 Sp2上。我将介绍一些关键概念，如门户、桌面和portlet，并详细描述多种portlet模式和窗口状态。我还将介绍如何使用Workshop来设计、实现、配置和执行portlet。


　　JSR 168定义了有关Java Portlet的规范。门户是一个Web应用程序和一个portlet的聚合。Portlet容器运行portlet，并管理它们的生命周期。JSR 168定义了portlet与portlet容器之间的契约，它没有定义portlet容器与门户之间的契约。门户的实现留给了门户供应商。

　　BEA WebLogic门户
　　BEA WebLogic Portal (8.1 SP2)的当前版本支持不同类型的portlet：JSP/HTML portlet、Java PageFlow portlet、Struts portlet和Java portlet，将来还会支持其他portlet，如Web Services for Remote Portlets (WSRP)。我们将着重介绍Java portlet。

　　WebLogic Portal提供了JSR 168中未描述的门户功能，包括但不限于：书和页面中portlet的组织、多渠道支持和使用skin、skeleton和shell定制。

　　为了能够继续下去，在进行下一部分之前，请先完成以下内容：
　　　·使用WebLogic Domain Configuration Wizard创建一个门户域（如JSR168PortalDomain）。
　　　·使用WebLogic Workshop创建一个使用上面所建立域的门户应用程序（如JSR168PortalApp）。
　　　·在门户应用程序内创建一个门户Web项目（如JSR168PortalWebProject）。
　　　·在门户Web项目中创建一个WebLogic Portal .portal文件（如JSR168.portal）。
　　　·启动服务器实例。

　　创建您的第一个Java Portlet
　　下面的步骤描述了如何创建您的第一个JSR 168 portlet。
　　·在门户Web项目（如JSR168PortalWebProject）中，使用WebLogic Workshop为portlet（入FirstPortlet）创建一个新文件夹。
　　·在新文件夹内使用Wizard通过创建相应的.portlet文件创建一个新portlet（如Firstportlet）。
　　·选择portlet类型为Java Portlet。
　　·指定标题（如First）。
　　·指定定义标签（如first）。
　　·指定类名称（如com.malani.examples.portlets.jsr168.FirstPortlet）。
　　·打开门户（如JSR168.portal）。
　　·将portlet（如Firstportlet）拖放到门户中的页面上（如JSR168.portal）。
　　·运行.portal文件进行测试。

　　您的第一个JSR 168 portlet已经成功运行了！但向导在背后作了些什么呢？
　　·它创建了一个特定于WebLogic Workshop和WebLogic Portal的.portlet文件。.portlet文件构成了与特定于Workshop和WebLogic Portal的.portal文件的契约。
　　·向导创建了一个.java文件（如com.malani.examples.portlets.jsr168.FirstPortlet.java），该文件放置在WEB-INF/src目录中。
　　·向导创建了一个WEB-INF/portlet.xml配置文件，并为portlet在文件中插入了一个条目。该portlet的条目看上去如下：

<portlet>
<description>Description goes here</description>
<portlet-name>first</portlet-name>
<portlet-class>com.malani.examples.portlets.jsr168.FirstPortlet
</portlet-class>
<portlet-info>
<title>First</title>
</portlet-info>
</portlet>

　　Java Portlet类
　　在该示例中，向导生成的Portlet Java文件扩展了javax.portlet.GenericPortlet类。GenericPortlet类实现了javax.portlet.Portlet接口。图1是一个Unified Modeling Language (UML)类图，描述了这些关系。通过直接实现portlet接口，可以编写一个portlet。然而，GenericPortlet是一个创建portlet的更方便方法。首先，我们看一下portlet生命周期、portlet模式和window状态。

图 1

　　Portlet生命周期
　　为了成功地创建portlet，您必须遵照portlet生命周期。javax.portlet.Portlet接口中的方法定义了该生命周期，这些生命周期方法是init()、render()、processAction()和destroy()。当部署portlet的实例时调用init()方法。它用于获得所需的任何昂贵资源（如后台连接），并执行其他一次性活动。当portlet的实例被撤销部署时，使用destroy()方法来释放这些资源。

　　Portlet规范清晰区别render请求和动作请求。图2描述了portlet请求和响应的一个UML类图。门户页面上的render请求会导致对所页面上的每个portlet上调用render()方法，当用户在特定portlet上调用某个动作（通常是HTML表单提交）时，将会调用该portlet的processAction()方法。这样，用户的动作请求转换为processAction()方法的一次调用和render()方法的多次调用。

图 2

　　图3是一个序列图，说明了调用processAction()方法的效果，以及为同一页面上的portlet进行后续render()方法的调用。关于更多信息，请参阅关于处理动作的一节。

图 3

　　有两种重载的init()方法，一个没有参数，另一个有一个javax.portlet.PortletConfig类的实例。注意：关于init(PortletConfig)有一个特殊的caveat。调用super.init(aPortletConfig)失败将导致一个NullPointerException。所包含的源代码示例中的Init portlet说明了这种行为（源代码可以在www.sys-con.com/weblogic/source.cfm中找到）。

　　Portlet模式
　　JSR 168定义了三种Portlet模式：VIEW、EDIT和HELP。一个portlet实例在任何时候都可以恰巧在一种　portlet模式下。其他自定义portlet模式（如配置和源）都是可能的。VIEW模式是默认的模式。Portlet规范建议EDIT模式允许portlet用户定制portlet实例，以及HELP模式显示关于portlet的用法信息。Portlet必须支持VIEW模式，但在portlet中对EDIT模式和HELP模式的支持是可选的。例如，portlet First portlet示例不支持EDIT模式和HELP模式。

　　window状态
　　JSR 168定义了三种Window状态：NORMAL、MINIMIZED和MAXIMIZED。Portlet实例任何时候都可以恰好是一种window状态。其他自定义window状态（如半页）也是可能的。在NORMAL状态下，portlet占了屏幕区的一小部分。屏幕状态与其他portlet共享。在MINIMIZED状态下，portlet的内容被隐藏。在MAXIMIZED状态下，portlet的内容占屏幕区的大部分。其他共享同一页面的portlet在MAXIMIZED状态下被隐藏。例如，portlet First示例支持所有三种window状态。

　　GenericPortlet类
　　您创建的大多数portlet将会扩展javax.portlet.GenericPortlet类，而不是直接实现javax.portlet.Portlet接口。GenericPortlet类实现了render()方法。如果portlet的window状态被最小化，那么render()方法不能做任何事情。如果portlet的window状态不是最小化，那么render()方法设置在portlet.xml文件中指定的标题，并调用doDispatch()方法。根据Portlet模式， doDispatch()方法适当地调用doView()、doEdit()和doHelp()方法。这样，由于GenericPortlet类帮助实现render()方法，并且提供doView()、doEdit()和doHelp()方法来覆盖，因此GenericPortlet类比Portlet接口更便于扩展。

　　考虑一下First portlet示例。FirstPortlet类扩展了GenericPortlet，FirstPortlet改写了doView()方法。

public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
response.setContentType("text/html");
response.getWriter().write("<p>Hello World</p>");
}

　　注意：调用setContentType()方法前调用getWriter()方法会导致java.lang.IllegalStateException。

　　实现Portlet模式
　　VIEW模式是强制的，但EDIT和HELP模式是可选的。为了实现EDIT和HELP portlet模式，需要在portlet类中实现适当的doEdit()和doHelp()方法。请参考包含在源代码示例（本文的源代码可以在www.sys-con.com/wldj/sourcec.cfm找到）中的portlet Mode。此外，必须在portlet.xml中如下配置各模式：

<supports>
<mime-type>text/html</mime-type>
<portlet-mode>edit</portlet-mode>
<portlet-mode>help</portlet-mode>
</supports>

　　注意：修改portlet.xml配置文件，但不实现portlet类中的相应方法，会导致javax.portlet.PortletException。

　　实现window状态
　　JSR 168没有描述禁用window状态支持的方法。然而，WebLogic Portal实现了对它们的禁用。为了禁用portlet对window状态的支持，需要在weblogic-portlet.xml文件中排除window状态：

<portlet>
<portlet-name>state</portlet-name>
<supports>
<mime-type>text/html</mime-type>
<excluded-window-state>minimized</excluded-window-state>
<excluded-window-state>maximized</excluded-window-state>
</supports>
</portlet>

　　请参考源代码示例中的portlet State。

　　包含JavaServer Pages (JSPs)
　　考虑portlet First的doView()方法，该方法获得了Writer的实例，并直接输出HTML片段。由于多种原因（如为了达到Java逻辑与HTML视图表现的分离），往往不推荐输出直接的HTML片段。推荐的方法是使用JSP来显示视图。portlet类中的方法执行业务逻辑、设置render参数以及包含JSP。为了包含一个特定的JSP，应首先获得PortletContext。从PortletContext实例中，通过调用getRequestDispatcher()方法获得一个PortletRequestDispatcher的实例。通过调用include()方法来包含JSP。例如：

// execute the necessary logic here...
PortletRequestDispatcher aDispatcher =
getPortletContext().getRequestDispatcher(
"/IncludePortlet/includeView.jsp"
);
aDispatcher.include(aRequest, aResponse);

　　注意：在执行render()方法时，portlet可能只使用一个PortletRequestDispatcher对象。
　　请参考包含在源代码中的portlet Include。JSP页面（如includeView.jsp）不包含根HTML标签（如<html>、<title>和<body>），因为这些标签由门户框架提供。JSP页面只包含显示portlet所必需的HTML片段。

　　处理动作
　　在一个标准的Web应用程序中，一个HTML表单提交将导致执行一些业务逻辑。业务处理的结果，要么作为属性而被设置在请求或会话中并转发，要么包含到下一个JSP。

　　在一个JSR 168 portlet中，一个HTML表单的动作URL应该是什么样呢？JSR 168定义了一个JSP标签库，称为portlet taglib。HTML表单的动作URL可以使用actionURL portlet标签生成。例如（请参考favoriteColorEdit.jsp文件）：

<form action="<portlet:actionURL/>" method="post">
...
</form>

　　提交该HTML表单将会导致调用portlet的processAction(ActionRequest aRequest, ActionResponse aResponse)方法。像通常一样，可以通过调用request对象的getParameter()方法来获得表单参数。注意：通过提交表单调用动作，但portlet中却没有processAction()方法，将会导致javax.portlet.PortletException。

　　processAction()方法设置response对象中的值。不要使用ActionRequest或ActionResponse对象的setAttribute()方法。值不会从processAction()传递到render()方法，而且在JSP中是不可用的。相反要使用ActionResponse对象的setRenderParameter()方法。这些render参数将对所有后续render请求可用，这一点与典型的Web应用程序请求属性很不相同。典型的Web application请求属性只对于一个请求可用。另一方面，render请求参数对于许多后续render请求可用。render参数保持可用直到值被动作的重新执行显式地修改或删除。

　　考虑portlet FavoriteColor。它在VIEW模式显示了一个用户偏好的颜色，但是可以在EDIT模式下更改。在EDIT模式下提交偏好的颜色选择将调用processAction()方法。该方法获得偏好的颜色请求参数，并将其设置为render参数。这样，偏好的的颜色render参数将在所有后续render请求中都可用。

　　所呈现的参数是怎样显示在JSP上的呢？应使用来自portlet标签库的defineObjects标签来定义portlet对象。该标签使renderRequest、renderResponse和portletConfig portlet对象在页面中可用。参数通过调用renderRequest对象的getParameter()方法来显示。请参考与所包含的源代码示例中的favoriteColorView.jsp。

　　portlet FavoriteColor也展示了其他概念。第一个是如何在processAction()方法中用编程的方法改变portlet模式。调用ActionResponse对象的setPortletMode()方法来修改portlet模式。第二个概念是如何使用一个HTML链接来修改portlet模式。该链接使用来自portlet标签库的renderURL标签生成。根据希望的portlet模式指定portletMode属性的值。请参考源代码示例中的FavoriteColorPortlet类和favoriteColorView.jsp页面。

　　Portlet Preferences
　　Portlet Preferences（Portlet首选项）是portlet的基本配置数据。一个preference是一个“名称和值”对。名称的类型是一个字符串，而值的类型是字符串或字符串数组。Portlet Preference不适于存储任意数据。portlet容器为portlet preferences提供持久性。在WebLogic Portal中，preference的持久性只在下面两个条件都为真时才起作用：
　　·门户运行在桌面中，而不是DOT门户模式。
　　·用户已经登录。

　　桌面与DOT门户模式
　　在WebLogic Workshop中创建.portal文件时，像书、页面和portlet等项都可以被拖放到.portal文件中，.portal文件能够直接从Workshop内运行。然而，某些功能，如preferences的存储，在这种DOT门户模式下运行时是不可用的（DOT门户模式也称为单文件模式（Single File Mode））。

　　其他模式称为桌面模式。创建一个门户时使用Portal Administrator。在门户内，一个桌面被创建。像图书、页面和portlet等项被创建，并放置在桌面中。在这种模式下，某些功能，像preferences的存储，是可用的（桌面模式也被称为流模式（Streamed Mode））。

在继续讨论前，先创建一个桌面：
　　启动Portal Administration（譬如，http://localhost:7001/JSR168PortalAppAdmin/）。一种启动Portal Administration的方法是直接从Workshop中启动。选择Portal菜单，选中Portal Administration菜单项。
　　·登录进Portal Administration。
　　·创建一个新门户（譬如，JSR168）。
　　·在门户中，创建一个新桌面（如d1）。
　　·将LoginPortlet添加到桌面的一个页面中。
　　·将ContactPortlet添加到桌面的一个文件中。

　　Portlet Preferences示例
　　Contact portlet演示了Portlet Preferences。Portlet Preferences可以是静态的或动态的。静态 preferences与portlet一起在portal.xml文件中指定。例如，ContactPortlet具有一个成为contact-preference的 preferences。contact-preference的默认值也被指定：

<portlet-preferences>
<preference>
<name>contact-preference</name>
<value>Email</value>
</preference>
</portlet-preferences>

　　动态 preferences不在portlet.xml配置文件中预定义。当portlet运行时，这些preferences被存储和读取。在运行期间，一个javax.portlet.PortletPreferences接口的实例包含这些preferences。该实例通过调用PortletRequest对象的getPreferences()方法获得。特定preferences的值通过调用preferences实例上的getValue()方法来获得。

　　调用preferences实例的setValue()方法会更新一个preferences值。然而，需要一个额外的步骤来提交这些修改。preferences实例的store()方法被调用来使preferences持久化。preferences只能在processAction()方法中进行修改。如果在processAction()方法中没有调用store()方法，任何对preferences实例的修改都会被丢弃。注意：就如前面提到的，如果用户没有登录或门户处于DOT门户模式，那么调用store()方法将会导致一个运行时异常。

　　在portlet和servlet之间有很多相似点。然而，它们也存在着重要区别。portlet规范建立在servlet规范之上。portlet容器存在于servlet容器中。就像servlet部署在一个Web应用程序中，portlet也是如此。Servlet和Web应用程序使用portlet.xml文件进行配置。一个servlet具有显式的生命周期：init()、doGet()、doPost()等。类似地，一个portlet也具有显式的生命周期：doView()、doEdit()、processAction()等。servlet和portlet类的方法必须以安全线程的方式编码。

　　然而，也存在着重要的区别。Servlet被允许进行include、forward和redirect操作；然而portlet只被允许进行include操作。Servlet能够呈现一个完整的页面，但portlet只提交页面片段。portlet具有严格定义的portlet模式和Window状态，这方面不像servlet。Portlet具有更正式的请求，对render请求和动作请求进行处理，它们也具有preferences。portlet并不是servlet！

　　结束语
　　本文通过使用一个简单的向导描述portlet的创建而开始，并说明了portlet的生命周期以及portlet类实现的内部工作方式，描述了portlet.xml配置文件和相应的weblogic-portlet.xml配置文件的结构和语义。对各种概念，如portlet模式和window状态，本文也进行了解释。本文演示了portlet标签库的用法和portlet中的表单处理。最后，我介绍了如何使用portletpreferences。理解了本文所介绍的这些知识和概念，您就可以在创建和部署自己的强大portlet的道路上前进了。

　　致谢
　　感谢Subbu Allamaraju、Max Cooper、Steve Ditlinger、David Lu、Roshni Malani和Alex Toussaint，他们仔细阅读了这篇文章，并提供了有价值的反馈意见。

　　参考资料
　　· 要讨论这篇文章、并提问问题，从这里开始： www.bartssandbox.com。需要免费成员资格。
　　· 下载、阅读JSR 168：www.jcp.org/en/jsr/detail?id=168
　　· WebLogic Portal文档的起始点：e-docs.bea.com/wlp/docs81/index.html
　　· 建立Workshop Help的Java Portlet部分：e-docs.bea.com/workshop/docs81/doc/en/core/index.html
　　· 用WebLogic Portal 8.1开发JSR 168 Portlet：dev2dev.bea.com/products/wlportal81/articles/JSR168.jsp
　　· Web Services for Remote Portlets (WSRP)规范：www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
　　· 尝试一下WSRP：dev2dev.bea.com/codelibrary/code/wsrp_supportkit.jsp
　　· Single File Mode和Streamed Rendering Mode：单击这里！
　　· 有关Portlet规范上的文章：
- 介绍Portlet规范，第1部分：
www.javaworld.com/javaworld/jw-08-2003/jw-0801-portlet_p.html
-介绍Portlet规范，第2部分：
www.javaworld.com/javaworld/jw-09-2003/jw-0905-portlet2_p.html
　　· 对JSR 168白皮书的介绍：单击这里！
　　· Java Passion Portlet演讲笔记：www.javapassion.com/j2eeadvanced/Portlet4.pdf

　　源代码
　　源代码-Zip文件
　　英文原文：http://www.sys-con.com/story/?storyid=45565&DE=1

作者简介
Prakash Malani	Prakash Malani 在架构、设计和开发软件方面经验丰富。他在许多应用领域从事过软件开发，比如娱乐、金融、零售、医学、通信和交互式电视。他喜欢实践和研究先进的技术，比如Java 2 Enterprise Edition (J2EE)、Unified Modeling Language (UML)和eXtensible Markup Language (XML)。他还在加利福尼亚州立理工大学波莫那校区等机构讲授最佳实践和设计模式。他在业界的著名出版物上发表过许多文章，比如JavaWorld和WebLogic Developers Journal。当前，他正在帮助组织Los Angeles BEA Users Group (LABEAUG)。

• WebLogic域配置策略
• BeanUtils: 威力和代价
• 配置weblogic 8.1和hibernate 3.0 第一部分
• 配置WebLogic 8.1和Hibernate 3.0，第二部分
• 使用面向方面编程(AOP)实现Gang of Four (GoF)设计模式
• 是否要使用门户代替POWA来开发web应用程序？

权限控制是liferay4.0以后增加的新特性。在liferay中开发权限是一件很容易的事情，基本上都是通过定义xml来实现。

首先，我们来看看给自己的portlet加上权限控制，主要要完成以下四步操作（DRAC）:

1. Define all resources and their permissions.

先定义所有所需要的权限（包括portlet resource和model resource）

2. For all the resources defined in step 1, register them into the permission system. This is also known

simply as “adding resources.”

当定义完权限后，我们需要把权限的定义注册到权限系统中，即把权限相关信息保存到数据库中

3. Associate the necessary permissions to these resources.

把所需的permission关联到resources上

4. Check permission before returning resources.

在相应的位置加上权限检验的方法

在解析上面四个步骤以前，有两个定义是非常重要的：

1．               Resource－在portal系统中，可以简单的认为Resource是一个个可以操作的实体对象。举个例子：一般resources包括portlets（如：Message Boards，Calendar， etc），java类（如：Message Board Topics，Calendar Events， etc）还有flies（如：documents，images，etc）

2．               Permission－一个个可运行的权限动作，都已经在resourcez中定义了。举个例子：“查看calendar的portlet”这个权限动作已经通过resource在liferay的权限系统中定义

下面来简单解析一下开发权限的四个步骤：

一．Defining Resources and Actions

       默认的权限定义的xml文件放portal/portal-ejb/classes/resource-actions中

我们来看看calendar的权限定义

• liferay-display.xml
• liferay-portlet.xml
• portlet.xml
• struts-config.xml
• tiles-defs.xml
• web.xml

本节主要内容是Liferay的授权操作以及内容管理，在介绍授权早作的同时将结合上一篇的内容，探讨程序背后的执行流程，也会凸现出在进行自己的portlet开发时所要注意的权限相关代码，为portlet的开发打下基础。

 liferay-portal-4.1.2的权限管理主要有2部分构成：

1．user的部门归属

2．对单个portlet的授权

超级用户登陆系统后，将进入超级用户的管理界面，管理界面总共有Guest、Private、CMS、Support 四层组成，即在Myplace中的4种视图, 现对其进行介绍.

Guest视图：主要管理普通用户的所访问的主页内容，在此视图中可以管理展现在主页上的各个portlet，管理portlet中展现的内容以及portlet的展现形式以及方位。Portlet的内容管理放在稍后的视图中详细讲解，portlet的方位以及显示形式后可以通过页面上直接的拖放进行设置。

      默认情况下，我们所列的portlet就是匿名用户所看到的门户，在每个portlet的设置中，我们还看到了权限的设置，可以将这个portlet的配置，查看等权限（每个portlet的权限不相同，每个都有配置、查看权限，但是有个复杂的portlet如用户管理的就有更多的如添加用户、删除用户等权限）授予用户，这里权限的授予分6级，直接授予用户，授予组织、授予地点、授予用户群、授予社群和授予客人（用户群和社群是自定义的）。Liferay的用户机制为公司—地点—组织—个人，所以授予某一高级的组，下挂的用户将都会自动获得权限。在我的应用中，我将WIKI加入了门户首页，同时将察看与删除授予匿名用户，所以，首页就拥有了一个大家参与修改的区域WIKI了！

Private 视图：这个是超级用户的私人界面，这里特别分析了几个简单portlet的权限管理的实现。

HelloWorldPortlet。位置Test－>helloworld 这个portlet是最简单的一个展示，而且仅仅只有view的功能，所以这个权限管理就是能否在用户的视图中显示就行了，代码中的权限代码无，只是由layout调用HelloWorldPortlet。注：这里是通过设置直接调用HelloWorldPortlet，没有经过Struts框架，所以代码直接继承GenericPortlet，不能由路径访问。

Announcements。位置，这个portlet中访问路径由struts配置文件指定，这个portlet代码ViewAction继承PortletAction，PortletAction继承的是Struts Action.在portlet.xml中，

<name>view-action</name>

<value>/wiki/view</value>

指定了这个portlet的view所调用的路径，portal容器会根据struts的配置调用指定的Action。在进行action调用时，很显然通过了Liferay扩展的PortalRequestProcessor（上一篇提到），也就进行了权限检查。配置Announcements的路径在liferay－portlet.xml中配置，为/announcements/edit_configuration，同样这也是一个struts路径，她的权限管理也同view一样，在PortalRequestProcessor中完成。

IFramePortlet。这个portlet也是一个简单标签的使用例子。在这个portlet中，与HelloWorldPortlet相同，也没有Struts的路径配置，而是直接在portlet.xml中定义了接受请求的Action，所继承的StrutsPortlet由于不是由struts Action而是GenericPortlet扩展而来，所以在访问的时候没有通过PortalRequestProcessor，所以其内部明确调用了liferay的权限管理代码：

PermissionChecker checker =

             PermissionThreadLocal.getPermissionChecker();

由上面我们所分析的几个简单的portlet来看，以后在进行portlet开发时有2种选择，当逻辑比较少时，我们可以象IFramePortlet一样，通过对StrutsPortlet的继承完成。当业务逻辑比较复杂时（多个路径），采用Struts进行路径配置时，最好同Announcements一样，通过继承PortletAction来将自身开发的portlet纳入liferay的权限管理框架中。

CMS视图：明显，这个层进行文档管理，用过Guest视图就可以知道门户的所有的新闻文章都在journal中进行管理，对它的使用网上有很多很有用的文章，多用几次也就熟悉了，强大的文本、图像编辑功能可以就近使用而不再用自己编码，肯定也是很愉快的了：）

Support视图：这个视图也是其他用户（非管理员用户）登陆后的定制页面，由管理员进行定制，主要操作和上面一致。

图1 Liferay技术架构

  

要用好这个基础平台，必须要对她的自身实现原理有个比较清晰的认识，以下文章为我在研究Liferay原理时所做的一些笔记，现整理和分享（由于笔记带有强烈的个人思想，有错误再所难免，希望能对进一步的分析做为铺垫，更欢迎批评指正）。

Liferay Portal

Liferay 的JAAS权限管理

Liferay的业务逻辑管理

Liferay二次开发

Liferay WSRP

Liferay的权限管理实现了一个典型的JAAS管理策略，所以在分析其本身前，在此首先介绍JAAS的验证原理和Tomcat上如何开发标准JAAS应用。

 JAAS验证原理

JAAS的核心类和接口可以被分为三种类型，大多数都在javax.security.auth包中。在J2SE 1.4中，还有一些接口的实现类在com.sun.security.auth包中，如下所示：

& #61557;       普通类 Subject，Principal，Credential(凭证)

　Subject类代表了一个验证实体，它可以是用户、管理员、Web服务，设备或者其他的过程。该类包含了三中类型的安全信息：

1)        身份（Identities）：由一个或多个Principal对象表示

2)        公共凭证（Public credentials）：例如名称或公共密钥

3)        私有凭证（Private credentials）：例如口令或私有密钥

　　Principal对象代表了Subject对象的身份。它们实现了java.security.Principal和java.io.Serializable接口。在Principal类中，最重要的方法是getName（）。该方法返回一个身份名称。在Subject对象中包含了多个Principal对象，因此它可以拥有多个名称。由于登录名称、身份证号和Email地址都可以作为用户的身份标识，可见拥有多个身份名称的情况在实际应用中是非常普遍的情况。

在上面提到的凭证并不是一个特定的类或借口，它可以是任何对象。凭证中可以包含任何特定安全系统需要的验证信息，例如标签（ticket），密钥或口令。Subject对象中维护着一组特定的私有和公有的凭证，这些凭证可以通过Subject 方法getPrivateCredentials（）和getPublicCredentials（）获得。这些方法通常在应用程序层中的安全子系统被调用。

& #61557;       验证 LoginContext，LoginModule，CallBackHandler，Callback

验证：LoginContext

　　在应用程序层中，你可以使用LoginContext对象来验证Subject对象。LoginContext对象同时体现了JAAS的动态可插入性（Dynamic Pluggability），因为当你创建一个LoginContext的实例时，你需要指定一个配置。LoginContext通常从一个文本文件中加载配置信息，这些配置信息告诉LoginContext对象在登录时使用哪一个LoginModule对象。

　　下面列出了在LoginContext中经常使用的三个方法：

& #61550;         login () 进行登录操作。该方法激活了配置中制定的所有LoginModule对 象。如果成功，它将创建一个经过了验证的Subject对象；否则抛出LoginException异常。

& #61550;         getSubject () 返回经过验证的Subject对象

& #61550;         logout () 注销Subject对象，删除与之相关的Principal对象和凭证

　　验证：LoginModule

　　LoginModule是调用特定验证机制的接口。J2EE 1.4中包含了下面几种LoginModule的实现类：

& #61550;         JndiLoginModule 用于验证在JNDI中配置的目录服务

& #61550;         Krb5LoginModule 使用Kerberos协议进行验证

& #61550;         NTLoginModul 使用当前用户在NT中的用户信息进行验证

& #61550;         UnixLoginModule 使用当前用户在Unix中的用户信息进行验证

　　同上面这些模块绑定在一起的还有对应的Principal接口的实现类，例如NTDomainPrincipal和UnixPrincipal。这些类在com.sun.security.auth包中。

　　LoginModule接口中包含了五个方法：

1)        initialize () 当创建一LoginModule实例时会被构造函数调用

2)        login () 进行验证,通常会按照登录条件生成若干个Principal对象

3)        commit () 进行Principal对象检验，按照预定义Principal条件检验Login生成的Principal对象，所有需要的条件均符合后，把若干个生成的Principal对象付给Subject对象，JAAS架构负责回传给LoginContext.

4)        abort () 当任何一个LoginModule对象验证失败时都会调用该方法。任何已经和Subject对象绑定的Principal对象都会被解除绑定。

5)        logout () 删除与Subject对象关联的Principal对象和凭证，消除Subject,Principal等认证对象。

　验证：CallbackHandler和Callback

　　CallbackHandler和Callback对象可以使LoginModule对象从系统和用户那里收集必要的验证信息，同时独立于实际的收集信息时发生的交互过程。

　　JAAS在javax.sevurity.auth.callback包中包含了七个Callback的实现类和两个CallbackHandler的实现类：ChoiceCallback、ConfirmationCallback、LogcaleCallback、NameCallback、PasswordCallback、TextInputCallback、TextOutputCallback、DialogCallbackHandler和TextCallBackHandler。Callback接口只会在客户端会被使用到。我将在后面介绍如何编写你自己的CallbackHandler类。

授权 Policy，AuthPermission，PrivateCredentialPermission

要了解Liferay（tomcat版本）的权限管理，必须首先了解JAAS在tomcat上的应用。

u          Tomcat服务器JAAS配置方法

　　和在应用程序运行JAAS不同的是，配置JAAS方法会有很不一样。我们使用的是Tomcat 5.0.x 应用服务器，它的JAAS配置方法有数种，分别是

& #61557;       JAASRealm

& #61557;       JDBCRealm

& #61557;       DataSourceRealm

& #61557;       JNDIRealm

& #61557;       MemoryRealm

JAASRealm

1.         把自定义 LoginModule、User、Role等相关类放入Tomcat 的 classpath

2.         把自定义login.config JAAS配置文件配置进JVM环境，例如： JAVA_OPTS=-DJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config

3.         设置 web.xml里的 security-constraints 标签设定需要保护的资源

4.         在$CATALINA_HOME/conf/server.xml里engine标签里设置JAASRealm标签

以下是JAASRealm标签的详细说明

以下是完整的tomcat服务器配置例子：

在%TOMCAT_HOME%/config/server.xml 中添加以下段落

<Realm className="org.apache.catalina.realm.JAASRealm"            

                appName="MyFooRealm"      

    userClassNames="org.foobar.realm.FooUser"      

     roleClassNames="org.foobar.realm.FooRole"

                      debug="99"/>

上面介绍了tomcat的应用，而liferay（tomcat版本）也是利用了这种标准的tomcat的JAAS实现。

与权限管理、用户认证的主要类包为：

com.liferay.portal.security.auth.*

com.liferay.portal.service.permission

com.liferay.portal.struts.PortalRequestProcessor

Liferay关于JAAS的实现包都在com.liferay.portal.security.auth.*下，在$catalina_home/conf/jaas.conf中定义了Liferay实现的loginModule，在我使用的版本中，PortalLoginModule将首先通过对象池取出一个自定义Liferay用户自定义的实现，即也可以在portal中再次自定义loginModule。显然，如果没有自定义的实现，将根据用户所使用的服务器自动进行选择默认实现。

Liferay自身所实现的user Principals和role Principals也仅仅是保存了用户的userid，以其作为自身标识，在登陆成功时赋予了所有用户“users”角色：

PortalRole role = new PortalRole("users");

getSubject().getPrincipals().add(role);

Liferay的PortalRequestProcessor扩展了TilesRequestProcessor，实现了自定义的请求处理流程。在请求流程中复写了processRoles（），在这个函数中进行了用户权限的判断，从而达到了对web资源的保护。

Permission是Liferay定义的用户访问的权限判断，由processRoles调用进行访问控制。

值得一提的是，Liferay本身也含有登陆模块，这个登陆模块所做的主要工作为通过认证确定用户的登陆信息正确，并通过用户的登陆信息取得用户userid存放在session中，为JAAS的登陆模块提供基础（即通过登陆的正确用户id与密码）。登陆的用户默认为LDAP登陆，但是为默认禁用，所以用户认证Liferay都通过一个数据库的认证实现在loginAction中进行的用户判断，取出了userid和password存放在session中。

整个过程如下：

如上图所示，触发JAAS的登陆模块的是在登陆成功后转向了/c/portal/protected，而此路径为tomcat的安全域，所以tomcat将调用用户自定义的登陆模块进行用户认证，通过认证后通过对用户角色的对比，来判断用户是否允许访问。

 图2 Liferay认证流程

  

The following are a set of instructions for integrating Liferay Portal with CAS Server to setup single sign on (SSO) between Liferay and an existing web application.

Setting up CAS server

We will begin with setting up JA-SIG CAS server on Tomcat 5.x.x.

Download cas-server WAR from Liferay's download page or the whole distribution from here and drop the cas-web.war file into Tomcat's webapps dir. In a production environment The CAS server should really run on its own tomcat instance but for testing purposes we'll drop it in the same instance as our Liferay portal.

We'll need to edit the server.xml file in tomcat and uncomment the SSL section to open up port 8443.

<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />

Setting up the CAS client

Next we need to download the Yale CAS client from here. Get cas-client-2.0.11. Place the casclient.jar in ROOT/web-inf/lib of the Liferay install.

Generate the SSL cert with Java keytool

Now that we have everything we need, it's time to generate an SSL cert for our CAS server. Instructions and more information on SSL certs can be found here

But I found some typos and errors on that page. So following the instructions below should get you what you need.

In any directory ( I use my root ) enter the command:

keytool -genkey -alias tomcat -keypass changeit -keyalg RSA

Answer the questions: (note that your firstname and lastname MUST be hostname of your server and cannot be a IP address; this is very important as an IP address will fail client hostname verification even if it is correct)

Enter keystore password:  changeit
What is your first and last name?
[Unknown]:  localhost
What is the name of your organizational unit?
[Unknown]:
What is the name of your organization?
[Unknown]:
What is the name of your City or Locality?
[Unknown]:
What is the name of your State or Province?
[Unknown]:
What is the two-letter country code for this unit?
[Unknown]:
Is CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
[no]: yes

Then enter the command:

keytool -export -alias tomcat -keypass changeit -file %FILE_NAME%

I use server.cert for %FILE_NAME%. This command exports the cert you generated from your personal keystore (In windows your personal keystore is in C:\Documents and Settings\<username>\.keystore)

Finally import the cert into Java's keystore with this command. Tomcat uses the keystore in your JRE (%JAVA_HOME%/jre/lib/security/cacerts)

keytool -import -alias tomcat -file %FILE_NAME% -keypass changeit -keystore %JAVA_HOME%/jre/lib/security/cacerts

Startup the CAS server

Now you are ready to startup your CAS server. Simply startup Tomcat and access CAS with https://localhost:8443/cas You should see the CAS login screen and no errors in your catalina logs.

Setting up Liferay Portal

web.xml

Note: If you are using Liferay 4.2, this filter is already defined. All you have to do is modify the URL parameters, if your CAS server is at a different location.

It's time to move on to configuring Liferay. In the web.xml file you will need to add a new filter and its mapping directly above the first existing auto login filter mapping. This new filter we just added will redirect all login attempts to the CAS server. If your hostname is different you can modify the init-params accordingly.

<filter>
<filter-name>CAS Filter</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://localhost:8443/cas-web/login</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://localhost:8443/cas-web/proxyValidate</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serviceUrl</param-name>
<param-value>http://localhost:8080/c/portal/login</param-value>
</init-param>
</filter>

If you use a ...serviceUrl param like above, after logging in with CAS, the browser will be redirected back to that serviceUrl. However, you can change it to the following and it will redirect back to the full URL that was originally requested. This allows you to have a deep link (e.g. to a certain layout with parameters for a portlet even) that is preserved through the CAS login process:

   <init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>localhost:8080</param-value>
</init-param>

<filter-mapping>
<filter-name>CAS Filter</filter-name>
<url-pattern>/c/portal/login</url-pattern>
</filter-mapping>

Then add the following to the rest of the auto login filters

<filter-mapping>
<filter-name>Auto Login Filter</filter-name>
<url-pattern>/c/portal/login</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

system-ext.properties

Note: this is only needed in Liferay 4.2

Set the com.liferay.filters.sso.cas.CASFilter setting to true.

Place the following in system-ext.properties:

   #
# The CAS filter will redirect the user to the CAS login page for SSO. See
# http://www.ja-sig.org/products/cas for more information.
#
com.liferay.filters.sso.cas.CASFilter=true

portal-ext.properties

Put this in portal-ext.properties.

##
## Auto Login
##

#
# Input a list of comma delimited class names that implement
# com.liferay.portal.security.auth.AutoLogin. These classes will run in
# consecutive order for all unauthenticated users until one of them return a
# valid user id and password combination. If no valid combination is
# returned, then the request continues to process normally. If a valid
# combination is returned, then the portal will automatically login that
# user with the returned user id and password combination.
#
# For example, com.liferay.portal.security.auth.BasicAutoLogin reads from a
# cookie to automatically log in a user who previously logged in while
# checking on the "Remember Me" box.
#
# This interface allows deployers to easily configure the portal to work
# with other SSO servers. See com.liferay.portal.security.auth.CASAutoLogin
# for an example of how to configure the portal with Yale's SSO server.
#
#auto.login.hooks=com.liferay.portal.security.auth.BasicAutoLogin
auto.login.hooks=com.liferay.portal.security.auth.BasicAutoLogin,com.liferay.portal.security.auth.CASAutoLogin

Comment the first auto.login.hooks property and uncomment the second to add CASAutoLogin to the list of AutoLogin implementations.

Startup Liferay and Test

Startup the portal and when the homepage loads up hit the login link. If all goes well you should be redirected to the CAS server's login screen. Login to CAS with liferay.com.1 as your username and liferay.com.1 as your password. You should now be logged into the portal.

Next steps

If the above test worked, you already have a CAS server installed and integrated with Liferay. The next steps are more related to properly configuring the CAS server than with Liferay. That's out of the scope of this article but we'll give a very brief summary.

By integrating the CAS server Liferay, is no longer responsible for authenticating the users, it just trusts that the CAS server authenticates them properly. The CAS server has configurable strategies for authenticating users. So far the default one has been used, which just authenticates the user if the user and password are the same. That's completely unsecure so other options need to be considered before installing in a production environment. Some reasonable options would be:

• To authenticate with LDAP: The CAS server includes an authentication handler for LDAP. You can read about it in http://www.ja-sig.org/products/cas/server/ldapauthhandler/index.html. If this option is chosen it is recommended that you also configure Liferay to authenticate against LDAP using the instructions in: LDAP. Then you'll need to provide some way to synchronized the users between LDAP and Liferay's database. Two options are:
  • Set up the automatic importer (see LDAP, available since v4.2)
  • Develop an extension to CASAutoLogin that upon successful login, if the user does not exist it is created with the user from LDAP (see this mb thread for details)
• To authenticate with the portal's database: It is possible to develop your own CAS authentication handler that uses the information present in Liferay's database. One way of doing this would be using Liferay's services to authenticate the user.
• To authenticate against another user store: in this case you'll also need to write your own CAS authentication handler and also provide Liferay some way to add the user entries in its own database.

Some other steps that you might want to follow are:

• Modify the look and feel of the CAS server pages to match those provided by the portal: http://www.ja-sig.org/products/cas/server/views/index.html
• Clustering: http://www.ja-sig.org/products/cas/server/cluster/index.html
• Set up real certificates

Also, check the references at the end of the article for more information.

Troubleshooting

If you created a cert with the %FILE_NAME%, you'll probably run into problems. Here are 2 commands to delete the tomcat alias from the keystore so you can start fresh:

keytool -delete -alias tomcat -keystore %JAVA_HOME%/jre/lib/security/cacerts
keytool -delete -alias tomcat -file server.cert

• You may not be able to get https://localhost:8443/cas up and running after the cert key generation. If so, skip the test and try it after you've finished all the steps. If you can't login at that point, you've probably generated your cert incorrectly.
• I've had problems with certs on IE7, make sure you try it out on Firefox and Opera.

• Your certificate must be trusted. If you created a self-signed certificate, you must add it to your truststore. I mistakenly thought I could define the truststore settings on my Tomcat SSL Connector. That didn't work because CAS was redirecting (after logging in) to a non-SSL page. Since the HTTP connector didn't know to trust the self-signed certificate, I got the 'sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target' error. My solution was to follow the guidelines in the JSSE Reference Guide and define the truststore in the JAVA_OPTS (-Djavax.net.ssl.trustStore=/path/to/custom/truststore). I created both a custom keystore (needed by the SSL Connector and specified either in the Connector config or the JAVA_OPTS) and custom truststore.

References

• Lifecast: CAS Setup - Integrate Liferay Portal with a CAS server to access multiple applications with a single sign on.

• A short article regarding CAS, Active Directory and an example : http://www-128.ibm.com/developerworks/web/library/wa-singlesign/

 
发布记录：
 
版本 日期 作者 说明
1.0 2005-10-20 柯自聪 创建，第一版
       

 
链接：
 
类别 网址
Blog http://www.blogjava.net/eamoi/
MSN-Space http://spaces.msn.com/members/eamoi/

 
 
OpenDoc版权说明：
本文档版权归原作者所有。
在免费、且无任何附加条件的前提下，可在网络媒体中自由传播。
如需部分或者全文引用，请事先征求作者意见。
如果本文对您有些许帮助，表达谢意的最好方式，是将您发现的问题和文档改进意见及时反馈给作者。当然，倘若有时间和能力，能为技术群体无偿贡献自己的所学为最好的回馈。
 
序... 5
第一部分 Liferay Portal 架构解析... 6
第一章 Liferay Portal. 6
第一节 Portal规范... 6
1.1.1 JSR168. 6
1.1.2 WSRP. 6
第二节 什么是Portal7
1.2.1 Portal 服务器... 7
1.2.2 Portlet容器... 7
第三节 什么是Portlet8
1.3.1 Portlet8
1.3.2 Portlet与Servlet的关系... 8
1.3.3 Portlet的生命周期... 9
第四节 Liferay Portal工作原理... 9
1.4.1 Portlet 样式以及窗口状态... 10
1.4.2 Portal页面... 11
第二章Liferay Portal的使用... 13
第一节 Liferay Portal安装... 13
第二节 Liferay Portal的用户策略... 14
2.2.1 定义用户... 14
2.2.2 添加用户... 15
2.2.3 修改用户... 15
2.2.4 定义用户组... 18
2.2.5 新增、重命名用户组... 19
2.2.6 修改用户组... 19
2.2.7 定义角色... 21
2.2.8 新增、重命名角色... 21
2.2.9 修改用户组角色... 21
2.2.10 定义Portlet的角色... 22
第三节 Liferay Portal内容和布局... 24
2.3.1 什么是布局... 24
2.3.2 什么是内容... 26
2.3.3 内容布局与Portlet的关系... 27
2.3.4 选择内容和布局... 28
第四节 Liferay Portal的桌面... 28
2.4.1 什么是桌面... 28
2.4.2 定义个性化的桌面... 29
第五节 Liferay Portal的品质... 29
2.5.1 什么是品质... 30
2.5.2 品质和Portlet、Portal的关系... 30
2.5.3 定义个性化的品质... 30
第六节 Liferay Portal的部署描述文件... 31
2.6.1 web.xml31
2.6.2 portlet.xml32
2.6.3 liferay-Portlet.xml33
2.6.4 liferay-display.xml34
2.6.5 liferay-layout-templates.xml35
2.6.7 liferay-look-and-feel。xml35
第二部分 Liferay Portal 二次开发... 36
第三章开发自己的Portlet. 36
第一节 重要的基类：GenericPortlet36
第二节 Portlet标签... 37
3.2.1 defineObjects标签... 37
3.2.2 renderURL标签... 37
3.2.3 actionURL标签... 38
3.2.4 param标签... 38
3.2.5 namespace标签... 38
第三节 Portal的对象... 38
3.3.1 Request对象... 39
3.3.2 Response对象... 41
3.3.3 PortletConfig对象... 41
3.3.4 Session对象... 41
3.3.5 Preference对象... 43
第四节 编写自己的Portlet类... 44
3.4.1 开发环境... 44
3.4.2 准备工作... 44
3.4.3 HelloWorldPortlet46
3.4.4 HelloJSPPortlet47
第五节 修改Web部署描述文件... 48
第六节 创建Liferay Portal部署描述文件... 49
第三部分 Liferay Portal部署... 54
第四章部署自己的Portlet. 54
第一节 手动部署... 54
第二节 Ant自动部署... 55
第三节 加入Liferay Portal自有列表... 55
第四节 普通Java Web应用转化为Portlet应用... 56
第四部分附录... 58
第五章相关资源... 58
第一节资源网站... 58
第二节 示例... 58
第六章参考资料... 59
后序
 
第一部分 Liferay Portal 架构解析
本部分主要内容
Portal 服务器 Portal 容器 Portlet
第一章 Liferay Portal
作为一个开源Portal产品，Liferay Portal提供对多个独立系统的内容集成，帮助多个组织实现更有效的合作。与其他商业的Portal产品相比，Liferay Portal有着一系列的优良特性，而且不需要付费。
第一节 Portal规范
随着Portal的兴起，越来越多的公司开始涉足Portal产品开发，并组建各自的Portal组件和基于其的产品，比如IBM、BEA、MicroSoft、SAP、Apache等。各个厂商的接口互不兼容，给软件开发商以及开发人员带来诸多不便。
1.1.1 JSR168
为此，JCP组织发布了JSR168(Java Specification Request)，Portlet Specification V1.0，用来提供不同的Portal和Portlet之间的互通性。只要开发的Portlet遵循JSR168，则就可以在所有遵循JSR168的Portal上部署运行。
JSR168中定义了Portal的实现规范和接口，并对理想的Portlet进行了详细的规划和描述。
1.1.2 WSRP
WSRP是OASIS Web Service for Remote Portlet的缩写。WSRP是Web Service的一种新的商业应用，一种新的标准，主要用来简化Portal对于各种资源或者程序整合的复杂度，可以避免编程带来的整合麻烦和问题。而且Portal管理员可以从海量的WSRP服务中选择需要的功能用以整合到目前所用的Portal中。它有三种角色：
①、生产者 à 提供Portlet
②、消费者 à 使用Portlet
③、终端用户 à 最终用户
它的特点在于生产者将消费者所需要的信息通过WSRP返回给消费者，这些信息是相对标记片断，例如HTML、XHTML等，可以直接嵌入用户的页面中，而不用像Web Service一样开发用户端接口。
实现这个规范，Portal可以跟各式各样的数据源打交道，彻底终结信息孤岛的窘境。
第二节  什么是Portal
Portal是基于Web的，以“应用整合”和“消除信息孤岛”为最终目的，提供单点登录、内容聚合、个性化门户定制等功能的综合信息系统。
完整的Portal通常由Portal服务器、Portlet容器、Portlet构成。
1.2.1 Portal 服务器
Portal服务器是容纳Portlet容器，支持Portlet呈现的普通或者特殊Web服务器。Portal服务器通常会提供个性化设置、单点登录、内容聚合、信息发布、权限管理等功能，支持各种信息数据来源，并将这些数据信息放在网页中组合而成，提供个性化的内容定制，不同权限的浏览者能够浏览不同的信息内容。通常，Portal提供以下功能:
单点登录：Portal通常采用ACL、SSL、LDAP等业界标准的安全技术，提供对所有现有应用系统的安全集成，只需在Portal的唯一入口上登录一次，就可以访问所有应用系统和数据。对于安全性要求较高的应用系统，如电子商务平台、交易系统等，通过扩展接口传递用户身份信息，如数字证书信息、数字签名信息等，进行二次身份认证，保证单点登陆的安全性。
权限控制:系统采用LDAP对用户资源进行统一的管理，同时提供二次开发接口，可以与其他应用系统的用户管理模块对接，并能随相关业务系统实时更新访问权限。通过完善的授权机制及存取控制，用户访问权限控制到字段级别，确保用户只能访问具有权限的应用系统及相关信息。
内容管理: 实现应用系统之间实时交换信息。采用多种缓存机制，保证内容交换的性能和准确性。采用基于XML的Rich Site Summary (RSS)标准，迅速在各应用系统之间传播最新变化。
信息发布: 实现信息门户内容的动态维护。动态网站系统可与OA协同办公系统、知识管理系统等集成，网站信息须经OA系统的审批流程流转通过后或知识管理平台设置具有外部共享权限后才可正式发布，真正实现内外信息发布的同步。
文件管理: 系统实现无缝集成多种数据源，包括：数据库、文档（Office文档、PDF、AutoCAD、甚至ZIP文档）、Web网页、FTP站点等，并对数据按业务要求和职务特点加以分析整理，通过统一Web界面主动推送(Push)至用户的门户桌面，帮助用户做出及时、正确的决策。
1.2.2  Portlet容器
Portlet容器提供Portlet执行的环境，包含很多Portlet并管理它们的生命周期，保存Portlet的定制信息。
一个Portal容器接收到来自Portal的请求后，接着将这个请求传递给存在Portal容器的Portlet 执行。Portlet容器没有义务去组合Portlet 产生的信息內容，这个工作必须由Portal来处理。Portal和 Portal容器可以放在一起视为同一个系统的组件，或者分开成为两个独立的组件。
Portlet容器是普通Web Servlet容器的扩展，所以一个Portlet容器可以构建于一个已经存在的Servlet容器或者可能实现全部Web Servlet容器的全部功能。无论Portlet容器怎么实现，它的运行环境总是假定它支持Servlet2.3规范。
通常，Portlet容器扩展自普通的Servlet容器。
 
第三节  什么是Portlet
Portlet是Portal中最重要的组件，负责在Portal中呈现信息内容，有相应的生命周期。通过自定义Portlet，用户很容易定义个性化的Portal页面。Portlet由Portlet容器负责管理、处理请求并返回动态页面，可以作为Portal的可即插即用的界面组件。
1.3.1 Portlet
一个Portlet是以Java技术为技术的Web组件，由Portlet容器所管理，专门处理客户的信息请求以及产生各种动态的信息内容。Portlet 为可插式的客户界面组件，提供呈现层成为一个信息系统。
这些由Portlet产生的内容也被称为片段，而片段是具有一些规则的标记( HTML、XHTML、WML )，而且可以和其他的片段组合而成一个复杂的文件。一个或多个 Portlet 的内容聚合而成为一个 Portal 网页。而 Portlet 的生命周期是被 Portlet 容器所管理控制的。
客户端和Portlet的互动是由Portal通过典型的请求/响应方式实现，正常来说，客户会和Portlet所产生的内容互动，举例来说，根据下一步的连接或者是确认送出的表单，结果 Portal将会接收到Portlet的动作，将这个处理状况转向到目标Portlet。这些Portlet 内容的产生可能会因为不同的使用者而有不同的变化，完全是根据客户对于这个Portlet的设置。
1.3.2 Portlet与Servlet的关系
Portlet被定义成为一个新的组件，具有新的明确的界面与行为。为了尽可能与现有的 Servlet 结合达到重复使用的目的，Portlet 的规范利用了 Servlet 的规范，许多观念都很相似的，结合 Portlet、Servlet 及 Jsp 在同一个网站系统中，我们称为Portlet 应用 。在同一个 Portlet 应用 中，他们将分享同一个类加载器(ClassLoader)，上下文(Context) 及 Session。
①、Portlet 和 Servlet 的相似之处
@ Portlet 也是 Java 技术的 web 组件
@ Portlet 也是有特定的 container 在管理
@ Portlet 可以动态产生各种内容
@ Portlet 的生命周期由 container 所管理
@ Portlet 和客户端的互动是通过 request/response 的机制
②、Portlet 和 Servlet 也有一些不同
@ Portlet 只产生 markup 信息片段，不是完整的网页文件。而 Portal 会将所有的 Portlet markup 信息片段放到一个完整的 Portal 网页。
@ Portlet 不会和 URL 有直接的关系
@ 客户端必须通过 portal 系统才能和 Portlet 互动
@ Portlet 有一些定义好的 request 处理，action request 以及 render request。
@ Portlet 默认定义 Portlet modes 及窗口状态可以指出在网页中该 Portlet 的哪个功能正在执行及现在的 状态。
@ Portlet 可以在同一个 portal 网页之中存在多个。
③、Portlet 有一些附加的功能是 Servlet 所没有的
@ Portlet 能够存取及储存永久配置文件及定制资料。
@ Portlet 可以存取使用者数据
@ Portlet 具有 URL 的重写功能在文件中去动态建立连结，允许 portal server 不用去知道如何在网页的片 段之中建立连结及动作。
@ Portlet 可以储存临时性的数据在 Portlet session 之中，拥有两个不同的范围：
application-wide scope 及 Portlet private scope 。
④、Portlet 不具有一些功能， 但是 Servlet 却有提供
@ Servlet 具有设置输出的文字编码( character set encoding)方式
@ Servlet可以设置 HTTP 输出的 header
@ Servlet才能够接收客户对于 portal 发出的 URL 请求
1.3.3 Portlet的生命周期
一个Portlet有着良好的生命周期管理，定义了怎样装载，实例化和初始化，怎样响应来自客户端的请求及怎样送出服务。这个Portlet生命周期由Portlet接口的init，processAction，render和destroy方法来表达。
载入和实例化:Portlet容器负责载入和实例化Portlet。当Portlet容器运行Portlet应用或者延迟到Portlet需要服务使用者的请求时，Portlet就会被载入并实例化。载入Portlet类后，Portlet类随即被实例化。
初始化:Portlet类实例化后，Portlet容器还需要初始化Portlet。以调用Portlet去响应客户端的请求。Portlet容器呼叫Portlet接口中的init方法初始化Portlet。扩展自PortletConfig的类可以取出定义在部署描述文件中的初始化参数，以及Resource Bundle。
初始化异常:在 Portlet初始化期间，Portlet可能会丟出 UnavailableException 或 PortletException 异常。此时，Portlet容器不能把 Portlet置入已启动的服务，并且 Portlet容器必需释放这个 Portlet。 destory方法不能被呼叫，因为初始化被认为执行失败。发生 失败后，Portlet容器会尝试着重新实例化及初始化 Portlet。这个异常处理的规则是：由一个UnavailableException 指定一个不能执行的最小时间，当此异常发生时，Portlet容器必需等到指定时间过去后才产生并且初始化一个新的 Portlet。
在初始化过程中所丟出的 Runtime Exception异常，被当作 PortletException 来处理。
第四节 Liferay Portal工作原理
Portal系统根据需要由一个或者多个Portal页面组成，每个Portal页面包含零个或者多个的Portlet。每个Portlet呈现自己的信息内容，以此实现内容聚合。通过定义每个Portlet的可用权限，实现个性化的桌面信息定制。
1.4.1 Portlet 样式以及窗口状态

JCP组织提出的JSR168规范定义了Portlet的实现标准。每个Portlet对外表现为一个小窗口，有自己的默认样式和窗口状态。如上图，Portlet有自己的标题，浏览状态下支持编辑、关闭、上移、下移、最大化、最小化功能，编辑状态下支持返回和关闭功能。从各种数据来源提取的信息以Portlet内容的形式呈现在Portal中。
Portlet样式指出 Portlet正处于什么模式，Portlet通常会根据所处的模式而执行不同的工作并产生不同的内容。
Portlet模式让 Portlet决定它该显示什么内容和执行什么动作。调用一个 Portlet的时候，Portlet 容器会提供一个 Portlet模式给那个 Portlet。当在处理一个请求动作时，Portlet 的模式是可以用程序来改变的。
JSR168规范定义了三个Portlet模式： 浏览、编辑和帮助，Liferay Portal支持其中的全部三个模式。同时Portal是可以根据使用者的角色，来决定是要提供(显示)哪几个 Portlet 模式给使用者操作。
例如，匿名使用者可以操作浏览和帮助等 Portlet 模式的内容， 而只有授权过的使用者可以操作编辑这个 Portlet 模式所提供的内容或动作。
在浏览这个Portlet模式里，所被期望要提供的功能是产生标记语言来表现此时 Portlet的状态。 举例来说， Portlet的 浏览 模式可以包含一个或多个画面让使用者可以浏览与互动， 或是一些不需要与使用者互动的静态内容。
   在编辑这个Portlet模式里， Portlet 需要提供内容和逻辑来让使用者定制 Portlet 的行为。典型的说，编辑模式的 Portlet 会设定或更新 Portlet 的参数设定值。
在帮助这个模式里，Portlet应该提供有关这个 Portlet的帮助信息。这个帮助信息可以是有关这个 Portlet的简单且条理清楚的视窗说明或是详细的说明整个来龙去脉。所有的Portlet并不需要都提供帮助这个模式。
一个 Portlet可以根据窗口状态来决定在一个页面里该占多少空间。当调用一个 Portlet时， Portlet容器 需要告诉该 Portlet目前的窗口状态。 此时 Portlet可以根据窗口状态来决定它该对多少信息作处理。在处理请求的过程中， Portlet可以通过程序的方式来改变窗口状态。
1.4.2 Portal页面

每个Portal页面包含零个或者多个Portlet小窗口，构成一个完整的信息呈现页面。Portal在启动之后根据Portlet配置文件等信息，给Portlet的标题等属性赋值，赋予Portlet编辑、关闭等各种控制按钮，使Portlet成为一个标准的Portlet窗口。Portlet合并这些Portlet窗口，组成一个完整的文档，即Portal页面。每个Portlet都处于相应的布局当中，呈现事先定义的内容，表现Portal公共的品质。而且Portlet可以在不同的布局之间切换。Portlet响应客户端的请求，并将请求提交到相应的URL进行逻辑处理。
Portlet开发完毕之后，部署到Portal服务器，由Portal服务器负责组织、权限控制和呈现。Portal页面创建过程如下:
Portlet 在 Portlet容器内执行，Portlet容器接收 Portlet产生的内容。通常 Portlet容器将这些内容提交给 Portlet服务器，Portlet服务器依照这些内容建立Portal页面，然后将它传给客户端呈现。具体流程如下图:

Portal页面的请求过程如下:
使用者经由客户端设备（例如浏览器）存取 Portal，Portal 根据接收到的请求决定哪些 Portlet 需要被执行以满足需求。Portal 通过Portlet容器呼叫 Portlet，然后由 Portlet产生的片段建立Portal页面，再传回客户端呈现给使用者。具体流程如下图:

第二章Liferay Portal的使用
       Liferay Portal分为Professional 和 Enterprise两个版本。
Liferay Portal支持多个应用服务器和Servlet容器。Liferay Portal Ent版本需要一个健壮的J2EE服务器，而Pro版本只要一个普通的Servlet服务器就可以运行。如果需要运行EJB，建议使用Pro版本。两个版本的源码和应用接口都是一样的。
默认的，Pro版本分别集成Tomcat / Jetty / Resin作为Web服务器，采用Struts作为Web框架，实现轻量级的系统架构。Enterprise集成JBoss作为Web服务器，采用Spring作为Web框架，兼顾EJB。
Liferay Portal默认集成HSQL数据库，来持久化保存用户自定义的数据。通过修改集成在Liferay Portal的Tomcat的部署描述文件，用户可以更改数据源。Liferay Portal官方网站提供了数据库表的生成脚本。
下面以Pro版本(Tomcat服务器)为例，讲述Liferay Portal的用户策略、内容布局、桌面和品质。
第一节 Liferay Portal安装
由于Liferay Portal Pro版本集成了Tomcat服务器V5，所以只要把应用包下载解压就可以直接运行。
1、从 http://www.iferay.om/web/guest/downloads/portal_pro 下载Pro版本zip包， 解压到目录{PORTAL_HOME}， 目录结构相对普通的Tomcat增加了Liferay文件夹。Liferay是默认的Web应用。
2、正确安装JDK1.4或者JDK1.5，并在环境变量里面正确配置JAVA_HOME变量。

3、从命令行启动{PORTAL_HOME}/bin/startup.bat，启动Liferay Portal。
4、在浏览器地址栏输入http://localhost ，访问Portal首页。
5、用Login为test@liferay.com密码为test的用户登录Portal系统，得到的是一个Demo的首页。

如果启动呈现异常，请查看Tomcat控制台查找原因。
Liferay Portal启动之后，HSQL数据库自动启动。
登录系统后，点击右上角“My Account”链接，在“Display”选项卡中将Language改为“Chinese(China)”，以便中文化Portal界面。
第二节 Liferay Portal的用户策略
Liferay Portal通过定义严谨的用户策略、灵活的可个性化定制的内容和布局以及丰富可定制的品质策略，实现灵活的可定制的产品理念。
Liferay Portal采用用户－用户组－角色－Portlet的关联方式来实现用户权限的管理。用户录属于用户组（也可以单独存在），该用户组具有某种（多种）角色，角色分配给用户组，也可以直接分配给用户。而操作某个Portlet 需要具有其指定的角色。下面通过实例操作，来了解和体验一下Liferay Portal的用户管理策略。
2.2.1 定义用户
Liferay Portal的用户管理在系统管理的Portlet中。缺省只有系统管理员才能使用。登录Portal后，可以在默认的桌面上找到“系统管理”Portlet。如果没有，从页面底部的选择框中选择“系统管理”添加上。也可以通过右上角“CMS”桌面的“内容和布局”页面找到管理入口。
从“系统管理”Portlet中选择“用户”项，进入用户管理界面。

2.2.2 添加用户
图2.2.1-2所示页面右边为“新增用户”列，填入你所要增加的用户名称，姓氏，用户标识（可自动生成），邮件地址，密码（可自动生成）等。可以修改该用户所具有的用户组和角色信息（也可创建之后再修改）。用户标识必须是系统唯一的，所以请确保你所输入的用户标识与已有的不冲突。
点击“新增用户”，我们成功增加一位用户标示为“educhina”的用户，如图2.2.1-2所示。左侧列表中新增一项“educhina eamoi”。然后我们就可修改这位用户的用户组，角色，个人档案等信息了。
2.2.3 修改用户
选择用户列表中一项，然后点击底部的三个编辑按钮，就可以分别编辑该用户的用户组、角色、档案等信息了。
       此处我们选择用户“educhina eamoi”，然后选择“编辑档案”，出现档案编辑页面。如图2.2.3-3所示。填写你想要修改的信息，点击对应的“更新”按钮即可完成修改。需要注意的是整个档案页面分成几个部分，需要分别修改更新。
选择用户“educhina eamoi”，然后选择“编辑角色”，进入角色编辑页面，如图2.2.3-4所示。左侧列表框为当前该用户所具有的角色，右侧列表为所有可用的角色。要赋给用户新角色，则从右侧选择一项或多项，通过中间的转移按钮，从右侧添加至左侧。要删减用户角色，则从左侧移至

set JAVA_OPTS=%JAVA_OPTS% -Djava.security.auth.login.config=%CATALINA_HOME%/conf/jaas.config
9. 解压liferay-portal-pro-3.6.1.war：创建到%CATALINA_HOME%/liferay目录地下（%CATALINA_HOME%为任意目录，最好不带中文）
10. 移动%CATALINA_HOME%/liferay/WEB-INF/lib 下除util-taglib.jar之外的所有.jar包放入/common/lib/ext。
11. 启动Tomcat，在浏览器地址栏上输入http://localhost就能看见登录界面，用户名输入：test@liferay.com,密码：test.

疑难：
1. 此方法只适应Tomcat5.0.x 和 jdk1.4.2，其他版本搭配，并不一定使用；
2. liferay-portal-pro-3.6.1.war用WinRAR解压即可；
3. 在安装Tomcat时应注意，不要让别的程序占用了8080端口，如果占用，可以在安装的时候修改端口，也可以修改
/conf/server.xml，使port="8082"或其他端口。
    <Connector 
port="8080"               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true" />
4.安装完毕，打开地址时可能报 java.lang.OutOfMemoryError，设置JVM的内存为-Xmx512m。
附原安装文件：

Tomcat 5.0.x/5.5.x

Expert

Download and install JDK 1.4.2 . Set an environment variable

If you are using Tomcat 5.5.x, you must download and install
JDK 5.

Download and install Tomcat.

You can download Tomcat 5.0.x or Tomcat 5.5.x. This
documentation assumes that you are using Tomcat
5.0.x but will also give special instructions for usage with
Tomcat 5.5.x.

Create /conf/Catalina/localhost/liferay.xml to set up the
portal web application.

<Context
    path=""
    docBase="../liferay"
    debug="0"
    reloadable="true"
    crossContext="true">
</Context>

For Tomcat 5.5.x, edit /conf/Catalina/localhost/ROOT.xml.
You must also remove the reference to
path="" in the XML.

Download liferay-portal-pro-3.6.1.war.

Populate your database with the portal schema and default
data.

Edit /conf/catalina.properties.

common.loader=
    ${catalina.home}/common/classes,\
    ...\
    ${catalina.home}/common/lib/ext/*.jar

Configure data sources for your database. Make sure the JDBC
driver for your database is accessible by Tomcat.

Create a mail session bound to mail/MailSession. You only
need to set the locations of the IMAP, POP3,
and SMTP servers.

Edit /conf/Catalina/localhost/liferay.xml and configure a
mail session. For Tomcat 5.5.x, edit
/conf/Catalina/localhost/ROOT.xml.

<Context...>
    <Resource
        name="mail/MailSession"
        auth="Container"
        type="javax.mail.Session"
    />
    <ResourceParams name="mail/MailSession">
        <parameter>
            <name>mail.store.protocol</name>
            <value>imap</value>
        </parameter>
        <parameter>
            <name>mail.transport.protocol</name>
            <value>smtp</value>
        </parameter>
        <parameter>
            <name>mail.imap.host</name>
            <value>localhost</value>
        </parameter>
        <parameter>
            <name>mail.pop3.host</name>
            <value>localhost</value>
        </parameter>
        <parameter>
            <name>mail.smtp.host</name>
            <value>localhost</value>
        </parameter>
    </ResourceParams>
</Context>

Configure JAAS.

Edit /conf/Catalina/localhost/liferay.xml and configure a
security realm. For Tomcat 5.5.x, edit
/conf/Catalina/localhost/ROOT.xml.

<Context...>
    <Realm
        className="org.apache.catalina.realm.JAASRealm"
        appName="PortalRealm"
     
userClassNames="com.liferay.portal.jaas.PortalPrincipal"
        roleClassNames="com.liferay.portal.jaas.PortalRole"
        debug="99"
        useContextClassLoader="false"
    />
</Context>

Repeat this step for a file called
/conf/Catalina/localhost/tunnel.xml if you want to enable
Liferay's
HTTP tunneling.

Create /conf/jaas.config.

PortalRealm {
    com.liferay.portal.jaas.PortalLoginModule required;};

Edit /bin/catalina.bat so that Tomcat can reference the
login module.

...

rem ----- Execute...

set JAVA_OPTS=%JAVA_OPTS%
-Djava.security.auth.login.config=%CATALINA_HOME%/conf/jaas.
config

Deploy liferay-portal-pro-3.6.1.war.

Unpack liferay-portal-pro-3.6.1.war to
%CATALINA_HOME%/liferay.

Move every jar except util-taglib.jar from
%CATALINA_HOME%/liferay/WEB-INF/lib to /common/lib/ext.
This step is only necessary if you plan to hot deploy
portlet WARs.

Start Tomcat.

If you get a java.lang.OutOfMemoryError exception while
starting up Tomcat, give your JVM more memory
by setting -Xmx512m.

Open your browser to http://localhost. Click on My Liferay
at the upper right hand corner to enter the
login screen. Your login is test@liferay.com and your
password is test.