其实portlet本来就是可以配置的,但我们的开发大部分情况下只使用view模式,edit和config模式一般没有使用,对于使用editor和config等模式的portlet,我们可以将他们称为可配置portlet。通过使用可配置portlet,可以做许多个性化定制。
应用场景:
1、如果在首页上有展现专题的地方,可以建立一个专题展现的portlet,这个地方要展现的内容为一个图片或多个图片,点击图片可以跳转相应的链接。但是专题可能需要变化,则这里可以添加一个config或edit模式来让管理员通过配置参数来定制。
2、如首页的新闻栏目,设计时是展现的A栏目,但是实际中用户可能有变化,需要换成其他栏目,同样可以通过可配置portlet来满足。
3、如提供RSS订阅,我们可以在配置项里面设置RSS的输出方法为标题或者是摘要或者是全文,标准可以为atom或者rss2.0等配置。
4、如有一个指标展现,用户需求为可定制的,用户A可以选择柱状图、用户B可以选择折线图、用户C可以选择饼图等。
包括但不限于以上场景,需要通过配置来适用不同的情况,为用户提供可配置选项的地方都可以使用可配置portlet。
可配置portlet的开发方式,我按数据的存储方式的不同,大概的分为两种。一种为使用PortletPreferences存储的,一种为自定义数据表结构存储的。
使用PortletPreferences存储的方式为将配置数据以键值对的形式存储于PortletPreferences的相关属性字段里面。以portlet的实例ID做为识别进行存储信息,适用于配置信息不算太复杂的场景。
如果配置信息比较复杂,推荐建立相关的数据库,将配置信息存储于数据库中。本文主要介绍存储于PortletPreferences中的方法,存储于数据库和普通的portlet的数据存储方法类似。
如果按模式的不同,又可以分为edit、config、help等不同的模式。这些对应于建立portlet时选用的modes的不同而不同,这里主要介绍config模式。其他模式类似。
1、需要有一个建立好的portlet。portlet的创建,参考前面的portlet简述:http://www.huqiwen.com/2012/09/03/liferay-6-1-development-study-3-portlet-explicate/
2、在Liferay-portlet.xml里面找到此portlet的相关配置,在里面添加configuration-action-class元素,如下:
<portlet>
<portlet-name>customjspportlet</portlet-name>
<icon>/icon.png</icon>
<configuration-action-class>xx.xxx.xxx.customjspportlet.CustomJspConfigurationAction</configuration-action-class>
<instanceable>true</instanceable>
<header-portlet-css>/css/main.css</header-portlet-css>
<footer-portlet-javascript>
/js/main.js
</footer-portlet-javascript>
<css-class-wrapper>customjspportlet-portlet</css-class-wrapper>
</portlet>
3、建立CustomJspConfigurationAction类,此类继承自DefaultConfigurationAction即可。
4、重写其中的render方法。如下。
public String render(PortletConfig portletConfig, RenderRequest renderRequest, RenderResponse renderResponse){
String portletId = renderRequest.getParameter("portletResource");
PortletPreferences preferences = PortletPreferencesFactoryUtil.getPortletSetup(renderRequest, portletId);
renderRequest.setAttribute("customjspConfig_page_title",preferences.getValue("customjspConfig_page_title", StringPool.BLANK));
renderRequest.setAttribute("customjspConfig_page_link",preferences.getValue("customjspConfig_page_link", StringPool.BLANK));
return "/html/CustomJspPortlet/config.jsp";
}
这个方法是点击portlet中的配置时进入的方法。在这个方法里面做以下几件事情。
1):我们获取到了当前portlet的PortletPreferences。
2):从PortletPreferences里面获取key为customjspConfig_page_title和customjspConfig_page_link的数据,并将他们放到request里面。
3):告诉Liferay我的配置页的JSP的路径是哪个。
5、编写config.jsp页面。config.jsp页面里面是我们要配置的一此参数信息,大部分情况下是一个展现的表单。主要内容可以参考如下(从项目中截取的部分代码,为说明问题已经简化):
<form action="<liferay-portlet:actionURL portletConfiguration="true" />" name="<portlet:namespace />fm" id="<portlet:namespace />fm" method="post">
<ul>
<li>
<span>标题:</span>
<input tabindex="1" type="text" name="<portlet:namespace />customjspConfig_page_title" id="<portlet:namespace />customjspConfig_page_title" value="<%=title%>" />
</li>
<li>
<span>链接地址:</span>
<input id='<portlet:namespace />custom_page_link' name='<portlet:namespace />customjspConfig_page_link' type="text" value="<%=link %>" />
</li>
<li>
<input type="button" value="" onclick="<portlet:namespace />saveConfig()">
</li>
</ul>
</form>
这里的关键点为form的action,所有这种模式的可配置portlet的action都可以固定为:<liferay-portlet:actionURL portletConfiguration="true" />。
6、服务端保存配置信息的处理。步骤5中的action会进入步骤3建立的配置类的processAction方法。在上面的配置类里重写processAction方法。里面的内容如下:
public void processAction(PortletConfig portletConfig, ActionRequest actionRequest, ActionResponse actionResponse)
throws Exception {
String portletResource = ParamUtil.getString(actionRequest, "portletResource");
PortletPreferences preferences = PortletPreferencesFactoryUtil.getPortletSetup(actionRequest, portletResource);
if (Validator.isNotNull(preferences)) {
//从request里面取数据
String title = ParamUtil.getString(actionRequest, "customjspConfig_page_title");
String link = ParamUtil.getString(actionRequest, "customjspConfig_page_link");
//将数据以键值对的形式填充到preferences里面
preferences.setValue("customjspConfig_page_title", title);
preferences.setValue("customjspConfig_page_link", link);
//存储数据到数据库中,持久化数据
preferences.store();
SessionMessages.add(actionRequest, "success");
}
super.processAction(portletConfig, actionRequest, actionResponse);
}
到这里已经完成了可配置portlet的配置部分的开发。
前面步骤开发的配置数据的目标是为了在view.jsp中使用,在view.jsp中使用可以在view.jsp的action中使用,也可以直接在view.jsp中直接提取,方法为:
PortletPreferences preferences = renderRequest.getPreferences();
String title = preferences.getValue("customjspConfig_page_title", StringPool.BLANK);
String link = preferences.getValue("customjspConfig_page_link", StringPool.BLANK);
通过这样的方法即可取到前面的配置信息,取取的数据具体怎么展现,怎么使用,根据不同的业务场景有所不同。
在IBM的developerworks中看到一篇不错的Liferay的文章,转载与此(进行了重新排版,以方便阅读):
本文可以配全以下几篇文章一起看:
Liferay与CAS及LDAP
Liferay基于CAS实现单点登录说明
本文的源文地址:http://www.ibm.com/developerworks/cn/opensource/os-cn-liferay-cas/index.html
Liferay 是一个基于 J2EE 架构的完整的门户解决方案,使用了 EJB、JMS 等技术, 前台界面使用了 Struts MVC 框架、模板技术等一些开源的主流技术,基于 XML 的 portlet 配置文件可以自由地动态扩展, 使用了 Web Services 来支持一些远程信息的获取,使用 Lucene 实现全文检索功能。
主要特点:
§ 采用最先进的技术 Java, EJB, JMS, SOAP, XML。
§ 提供多种单点登陆接口,如 CAS,LDAP, OpenID,OpenSSO 等。
§ 管理员能通过用户界面轻松管理用户,组,角色,并为不同的用户分配不同的权限范围和相应的功能。
§ 用户可以根据需要定制个性化的页面布局和颜色风格。
§ 可以在主流的 J2EE 应用服务器上运行,如 Tomcat,Weblogic,WebSphere 等商业或开源免费的服务器。
§ 支持多种主流的数据库,如 Oracle,DB2, MySQL 等。
§ 使用了第三方的开源项目,如 Velocity ,Hibernate, Lucene, Struts 等。
§ 支持包括中文在内的多种语言。
§ 目前最新的版本为 Liferay 6.1(2012 年 2 月更新)。
CAS 是一个独立的 web 应用 , 当前使用 Java Servlets 实现,通过 HTTPS 协议保证其数据的传输安全性。 它通过三个 Url 地址进行访问:登录 Url、验证 URL、注销 URL。
CAS 原理和协议
本文中,我们以 Liferay6.1 的版本进行部署示例。
准备:
由于本文需要将 Liferay 的数据库作为单点登录的认证数据库,所以需要将 Liferay 的数据库安装到 Mysql 上。 Mysql 的下载和安装本文不做缀述。在此只简要介绍 Liferay 的安装和配置。Liferay 可以从官方网站下载到安装包的最新版本。
Liferay 安装包的下载地址:
http://sourceforge.net/projects/lportal/files/Liferay%20Portal/6.1.0%20GA1/liferay-portal-tomcat-6.1.0-ce-ga1-20120106155615760.zip/download
安装 Liferay:
Liferay 在启动时会对数据库进行初始化。
将下载到的安装包 liferay-portal-tomcat-6.1.0-ce-ga1-20120106155615760.zip 解压到安装目录下, 在路径 liferay-portal-6.1.0-ce-ga1\tomcat-7.0.23\bin 下找到 startup.bat 启动文件,并执行。在默认情况下, liferay 会使用 Hypersonic 作为默认数据库,在第一次访问时,我们可以对数据库、管理用户等参数进行配置。 当 tomcat 服务器启动后,我们可以访问 http://localhost:8080/ 如果出现基本配置页面,则说明部署成功。 接下来,我们可以在这个配置页面上对 Liferay 进行一些基本设置。首先我们要做的是将默认的数据库更改为我们要使用的 Mysql 数据库。 点击(更改)如图 2:
Liferay 配置页面
在此我们将数据库的链接 URL 修改为我们新建的数据库地址。完成后点击完成配置。 此时 Liferay 将根据新的配置参数和数据库地址对数据库进行初始化。当出现如下界面时,则 Liferay 安装完成:
图3: Liferay 配置初始化成功界面
准备:
下载最新版的 CAS 产品包,下载地址:
http://downloads.jasig.org/cas/cas-server-3.5.0-release.zip
安装 CAS:
解压缩以后,在其路径 cas-server-3.5.0\modules 下面找到 cas-server-webapp-3.5.0.war, 将其拷贝到 liferay 的服务器部署目录 liferay-portal-6.1.0-ce-ga1\tomcat-7.0.23\webapps 下, 改名为 cas.war, 并修改 war 包中配置文件 cas.properties 里的 cas server name=cas 并启动 liferay 服务器, 启动后可在浏览器访问 http://localhost:8080/cas/login
当出现如下界面时,说明 cas 服务器已经部署成功。如下图:
此时,CAS 还不能作为有效的单点登录服务器。在实际使用的时候,还需要根据实际概况做扩展和定制,最主要的是扩展认证 (Authentication) 接口和 CAS Server 的界面。其中红色部分的提示当前登录的 CAS 链接是不安全的,建议使用 https 协议。 由于 https 协议在服务器上配置已经有很多对应的文档和帮助,在此将不做赘述,本文中,我们将使用 http 协议对 CAS server 进行配置。
取消 CAS 服务器 HTTPS 认证方式 :
修改 cas\WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml 配置文件,将 p:cookieSecure="true” 改为 p:cookieSecure="false" ,改完后如下:
清单 1. ticketGrantingTicketCookieGenerator 配置
1. <bean id="ticketGrantingTicketCookieGenerator"
2. class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
3. p:cookieSecure="false"
4. p:cookieMaxAge="-1"
5. p:cookieName="CASTGC"
6. p:cookiePath="/cas" />
修改 cas\WEB-INF\spring-configuration\warnCookieGenerator.xml 配置文件,将 p:cookieSecure="true” 改为 p:cookieSecure="false" ,改完后如下:
清单 2. warnCookieGenerator 配置
1. <bean id="warnCookieGenerator"
2. class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
3. p:cookieSecure="false"
4. p:cookieMaxAge="-1"
5. p:cookieName="CASPRIVACY"
6. p:cookiePath="/cas" />
修改 deployerConfigContext.xml: 找到"HttpBasedServiceCredentialsAuthenticationHandler" bean 添加:p:requireSecure="false", 改完后如下:
清单 3. warnCookieGenerator 配置
1. <bean class="org.jasig.cas.authentication.handler.support.
2. HttpBasedServiceCredentialsAuthenticationHandler"
3. p:httpClient-ref="httpClient"
4. p:requireSecure="false"/>
这样,在 cas 服务器运行的时候,就可以只使用 http 请求了,省去了 HTTPS 协议的麻烦配置。
CAS 作为单点登录的认证服务器,在收到页面传递的登录请求以后,将请求转发到 CAS 服务器后端进行验证,在未经配置的时候, 只要输入的密码和用户名称一致,则验证通过。在实际的使用中当然这样是不可行的。在此我们要对用户输入的用户名称和密码做校验。 如果存在该用户,并且密码正确则说明验证通过。
这里就有了两个问题:
第一,CAS 需要连接到存储用户信息的数据库才能读取到用户信息。
第二,验证密码的加密算法必须和数据库存储密码的加密方式一致。基于此文采用的方式,对于第一个问题, 我们将直接使用 CAS 服务器连接到 Liferay 安装的数据库,直接读取 Liferay 门户的用户信息。 对于第二个问题,我们将直接调用 Liferay 中的加密算法对用户输入的密码进行加密,然后与数据库中的加密密码进行比对。 这样就可以保证 CAS 服务器在进行用户认证时,可以和 Liferay 服务器使用的用户保持一致。
我们要读取 Liferay 中的认证用户信息,就需要用 CAS 链接到 Liferay 的数据库。CAS 提供了通过 JDBC 连接数据库进行验证的缺省实现, 基于该包的支持,我们只需要做一些配置工作即可实现 JDBC 认证。
JDBC 认证方法支持多种数据库,在此我们以 Mysql 数据库为例 :
清单 4. 配置 dataSource
1. <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
2. <property name="driverClassName" value="com.mysql.jdbc.Driver" />
3. <property name="url" value="jdbc:mysql://localhost:3306/portaldb?
4. useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false" />
5. <property name="username" value="username" />
6. <property name="password" value="password" />
7. </bean />
其中 id 属性为该 dataSource 的标识,在后面配置 authenticationManager 会被引用, 另外,需要提供 dataSource 所必需的数据库驱动程序、连接地址、数据库登录用户名以及登录密码。
修改 cas.properties 配置文件
清单 5. 配置 cas.properties
host.name=cas server.prefix=http://localhost:8080/cas database.hibernate.dialect=org.hibernate.dialect.MySQLDialect |
CAS 默认使用了一套简单的密码验证,在 deployerConfigContext.xml 配置文件中, 为认证管理接口 authenticationManager 配置了属性 authenticationHandlers 处理器, 其中:<bean /> 就是默认的认证处理逻辑,我们可以在下载到的压缩包找到他的源代码:cas-server-core\src\main\java\org\jasig\cas\authentication\handler\support\SimpleTestUsernamePasswordAuthenticationHandler.java,
清单 6. 默认认证算法
public boolean authenticateUsernamePasswordInternal (final UsernamePasswordCredentials credentials) { final String username = credentials.getUsername(); final String password = credentials.getPassword(); if (StringUtils.hasText(username) && StringUtils.hasText(password) && username.equals(getPasswordEncoder().encode(password))) { log.debug("User [" + username + "] was successfully authenticated."); return true; } log.debug("User [" + username + "] failed authentication"); return false; } |
默认的用户名和密码认证方式是只要校验用户名和密码相同,则认证通过。因此我们要对这种认证方式进行修改, 改为用户名和密码都采用 Liferay 中用户的校验方式。将默认的认证类注释掉,配置提供的 jdbc 认证:
清单 7. 配置自定义 JDBC 认证方式
1. <!--
2. <bean class="org.jasig.cas.authentication.handler.support.
3. SimpleTestUsernamePasswordAuthenticationHandler" />
4. -->
5. <bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler" >
6. <property name="sql" value="select password_ from user_ where screenName=?"/>
7. <property name="dataSource" ref="dataSource"/>
8. <property name="passwordEncoder" ref="mypasswordEncoder"/>
9. </bean>
属性 sql 配置为查询 Liferay 数据库表 user_,字段 password_ 和 screenName 其中 passwordEncoder 是对清单 7 中设置的实际加密器类的引用。 为了使用 Liferay 的密码加密方式,我们需要配置一个我们自己开发的密码加密类:
清单 8. 指定具体加密类和加密算法
1. <bean id="mypasswordEncoder"class="com.test.portal.cas.MyPasswordEncoder">
2. <constructor-arg value="SHA"/>
3. </bean>
在此我们采用和 Liferay 一致的默认加密算法“SHA”,在调用 Liferay 提供的加密算法时, 我们需要将 Liferay 的几个 jar 包引入到我们的 cas 工程中,自定义的加密算法也很简单, 只需要调用 jar 包中的加密工具类提供的加密算法即可,同时自定义的类需要继承 PasswordEncoder 接口:
清单 9. 自定义加密算法类
import javax.validation.constraints.NotNull; import org.jasig.cas.authentication.handler.PasswordEncoder; import com.liferay.portal.kernel.util.DigesterUtil; public final class MyPasswordEncoder implements PasswordEncoder { @NotNull private final String algorithm; public MyPasswordEncoder(final String algorithm) { this.algorithm = algorithm; } public String encode(final String password) { String pass = DigesterUtil.digest(algorithm,password); return pass; } } |
至此 CAS 部分的配置就完成了,只需要再 Liferay 中进行相应的设置以后就可以使用了。
使用有管理权限的用户登录 Liferay,在控制面板中进入“设置”页面。再右侧的面板中选择“认证”, 进入 Liferay 认证设置。在用户如何认证的选项中选择“按屏幕名称”。选择“CAS”设置页面,选中“开启”, 修改登录 URL:http://demo1:8080/cas/login,修改注销 URL:http://demo1:8080/cas/logout, 修改服务器名称:demo1:8080,修改服务器 URL:http://demo1:8080/cas, 修改无用户时重定向的 URL:http://demo1:8080,点击测试 CAS 配置,验证通过后,保存配置。
至此 Liferay 的配置也已经完成,此时点击“注销”用户,则根据配置,系统会跳转到 CAS 服务器的登录界面。使用 Liferay 的用户登录, CAS 服务器会链接 Liferay 的数据库进行认证,认证成功后会跳转到 Liferay 的首页,表示 CAS 和 Liferay 的连接配置完成。
配置好 CAS 与 Liferay 的集成以后,我们可以通过 CAS 服务器进行单点登录,这样 Liferay 门户中集成的 Web 应用就可以采用 CAS 作为单点登录的服务器。 在实际使用中,还需要实现用户的同步,其他 Web 应用中的用户信息需要与 Liferay 数据库中的数据保持同步, 用户信息的同步可以使用 Liferay 提供的接口从 Liferay 的数据库中同步,也可以使用第三方的用户目录服务器进行同步, 具体的同步方法在此不做过多说明。
本文介绍了 使用 Liferay 集成 CAS 实现单点登录的解决方案,并结合实例讲解了在 Liferay 中使用 CAS 的配置、部署方法以及效果。 Liferay 是作为开源门户解决方案的一个不错选择,更多的使用细节可以参考 Liferay 官方网站。
你是否在苦恼于想对一些系统做压力测试,但是又没有找到简单方便的工具?其实在 apache 里 面就自带了一些这样的测试工具—ab(apache benchmark)。此工具在安装在apache 的 bin 目录下面。Ab 可以直接在 web 服务器本地发起测试,也可以在远程发起测试。
Ab 测试的本质是模http请求,所以可以将它看做是对于Web 服务器软件的黑盒性能测试, 它获得的一切数据和计算结果,都可以途过HTTP来解释。
如现在我们要对 www.qq.com 做一次测试,使用方法如下。在 windows 下面打开命令行,进入到 apache 的 bin 目录下面,或者将 apache 的 bin 目录添加到系统的环境发量的 path 下面。
输入 ab –n 100 –c 10 http://www.qq.com/
然后按回车,可以出现如下的内容:
§ -n 100
表示总请求数为 100
§ -c 10
表示并发用户数为 10
§ Http://www.qq.com/
表示请求的目标 URL,也就是要测试的目标地址。
§ Server Software
表示被测试的 Web 服务器软件名称,返回的 squid/3.0,它来自于http响应数据的头信息,所
以如果这里是我们自己编写的 Web 服务器软件或者修改开源的 web 服务器软件的源代码,返里的 信息可以为我们自定义的头信息。
§ Server hostname
表示请求的 URL 中的主机部分名称,它来自于http请求数据的头信息。
§ Server port
表示被测试的 web 服务器软件的监听端口。
§ Document Path
表示请求的 URL 中的根的绝对路径,它同样来自于HTTP请求数据的头信息,通过它的后缀名, 我们一般可以了解该请求的类型。
§ Document Length
表示 HTTP 响应数据的正文的数据长度。
§ Concurrency Level
表示并发用户数,返里数据就是我们前面设置的-c 的数值。
§ Time taken for tests
表示所有返些请求被处理完成所花费的总时间。
§ Complete requests
表示为请求数,这是我们前面设置的-n 的参数值。
§ Failed requests
表示失败的请求数,这里的失败是指请求在连接服务器、发送数据、接收数据等环境节发生异常, 以及无响应超时的情况。对于超时时间的设置可以使用 ab 的-t 参数,
如果接收到的 http 响应数据的头信息中含有 2xx 以外的状态码,则会在测试结果显示另一个名 为“Non-2xx response”的统计项,用户统计这部分请求数,这些请求并不算是失败的请求。
§ Total transferred
表示所有请求的响应数据长度总和,包括每个 http 响应数据的头信息和正文数据的长度。注意 这里不包括 http 请求数据的长度,所以 Total transferred 代表了仅 Web 服务器流向用户 PC 的应用层数据总长度。通过使用 ab 的-v 参数即可查看详细的 http 头信息。
§ HTML transferred
表示所有请求的响应数据中正文数据的总和,也就是减去了 Total transferred中 http 响应数据中头信息的长度。
§ Request per second
这里的值就是吞吐率,它等于
Complete request /Time taken for testsTime per request
这里的值是用户平均请求等待时间,它等于
Time taken for tests /(complete requests/Concurrency level)
§ Time per request(across all concurrent requests)
这里的值是服务器的平均请求处理时间,它等于 Time taken for tests/complete requests 返回值正是吞吐率的倒数。同时,它也等于 Time per request/Concurrency Level
§ Transfer rate
表示这些请求在单位时间内从服务器获取数据的长度,它等于 Total transferred /Time taken for tests
这个统计项可以很好的说明服务器在处理能力达到极限时,其出口带宽的需求量。
§ Percentage of the requests served within a certain time(ms)
这部分数据用于描述每个请求处理时间的分布情总,比如在上面的测试结果中,50%的请求处理 时间在 5200ms 内,99%的请求在 18022ms 内。注意这里的处理时间,是指前面的 Time per request, 即对于单个用户而言,平均每个请求处理的时间。
Liferay和CAS的结合实现单点登录,在我之前转载的的IBM的那篇文章Liferay 集成 CAS 实现单点登录与应用系统集成里面,该说明的已经都说明了,但是那篇文章里面有一些地方说明的不太清楚明白的地方,在这里做一个补充说明:
1、那篇文章的单点登录是以Liferay的用户作为基准,用户的验证是使用Liferay的用户验证规则,所以要重写CAS的验证方法,以能够使用Liferay的用户,在实际中可能用户的验证源可能并不是Liferay的用户,有可能是从LDAP/AD或HR系统。
2、原文中“修改 war 包中配置文件 cas.properties 里的 cas server name=cas 并启动 liferay 服务器”,在cas.properties里面找不到cas seerver name这个属性(不同的版本问题),这里可以跳过,修改下面的host.name=域名,如果是本机测试可以使用localhost。
3、CAS配置里面的数据源配置等,是配置在deployerConfigContext.xml文件里面。
4、“在调用 Liferay 提供的加密算法时, 我们需要将 Liferay 的几个 jar 包引入到我们的 cas 工程中”,这里需要引入的包是portal-service.jar,在liferay的tomcat下面的lib/ext目录下面,如果是在eclipse里面,可以将这个服务器的运行环境引入进来。将这里编写的passwordEncode打成jar包或者编译成class文件,放置到cas工程的WEB-IN/classes目录下面即可。这样的配置加密的前提是CAS Server必须和Liferay部署在同一个Tomcat下面,实际中一般不这样做,所以此过程可以作为参考,在生产环境并不建议如此做。
其他就没有特别说明的,按照上面的说明走就可以配置通过。