在研究cas的过程中, 发现cas的部署项目是采用overlay方式部署的, 因此上网查找如下:
在一个大项目中拆分maven工程时,很有可能会把js、css、jsp等文件放在不同的工程里(根据业务模块划分)。因为如果都集中在一个maven webapp里,那么这个maven webapp会太大,而且在业务上也比较分散
但是这些持有js、css、jsp的maven工程,如果packaging设置为jar是不合适的,因为外围要读取内部的这些文件就会很困难。在这种场景下,一个很自然的想法就是打成war包,然后用某种方式将多个war包归并起来,得到最终的war包
这就是overlays发挥作用的地方
以下举一个例子:
这里有2个web工程,一个是task-sla-web,一个是task-web-dist,packaging类型都是war,目录结构如下:
下面是task-sla-web的pom文件:
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-sla-web</name>
该工程就是打成一个war包,但是这个war是无法运行的,而是稍后用来合并的。(其中放了 一个空的web.xml,因为maven-war-plugin的package goal有强制要求)
下面是task-web-dist的pom文件:
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-web-dist</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-web-dist</name>
Xml代码 收藏代码
<!– 合并多个war –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<overlays>
<overlay>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
Xml代码 收藏代码
<!– 配置依赖 –>
<dependencies>
<dependency>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>war</type>
</dependency>
</dependencies>
以上片段主要要注意几点:
1、task-web-dist自身的packaging类型也是war
2、在<overlay>中配置要归并的webapp的groupId和artifactId,注意的是,该pom所在的webapp工程是主工程,会覆盖掉所有待归并工程的同名文件,包括web.xml
3、要归并的webapp,必须声明为依赖
归并后的最终war包如下:
其中的文件和.class都是由2个war包归并得到的,task-web-dist是主war包,如果多个war包中存在重名文件,则会被task-web-dist的文件覆盖,比如web.xml
此部分来源: http://kyfxbl.iteye.com/blog/1678121
上述说明了 overlay的使用方法, 下面是 cas的overlay的资料
还好,maven的overlay的功能,可以帮助我解决这个问题。
什么是maven的overlay?
overlay可以把多个项目war合并成为一个项目,并且如果项目存在同名文件,那么主项目中的文件将覆盖掉其他项目的同名文件。
于是,我就可以完全不修改cas-server-webapp的原有代码实现CAS了。
步骤一:新建my-cas-server
默认的CAS是以cas-server-webapp为主项目,用户登录认证入口、用户登录页面、各种主配置文件都包含在此项目中。
现在,我把新建的my-cas-server作为我的主项目,而把cas-server-core项目作为从属项目导入主项目中。
my-cas-server的pom.xml
<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<version>3.4.11</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
步骤二:设置overlays
配置overlay用于覆盖从属项目的同名文件,意思就是说,如果我主项目中存在与cas-server-webapp项目相同目录并且相同名称的文件,已主项目的为准,也就是覆盖从属项目的文件。
在my-cas-server的pom.xml中添加:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
</plugins>
</build>
步骤三:拷贝同名文件
把之前修改过的cas-server-webapp的源码以及配置文件,全都列举出来,并且拷贝到my-cas-server的相同目录下。
例如:之前我改过了这么些代码(部分代码)
UsernamePasswordCredentials.java
AuthenticationViaFormAction.java
webapp/WEB-INF/
|–classes
|—cas-theme-default.properties
|—default_views.properties
|—messages_zh_CN.properties
|–spring-configuration
|—-ticketRegistry.xml
cas-servlet.xml
deployerConfigContext.xml
login-webflow.xml
web.xml
同样的,我把这些文件全部复制到新项目中,目录与原项目保持一致。
步骤四:启动my-cas-server测试效果
启动后发现,与之前效果完全一致,可以正常访问,也可以正常的进行认证。
扩展:
采用overlay方式后,不仅可以不用修改源码进行CAS改造,而且你还会发现,编码的自由度大大增加了,不用再受限于原有项目的种种约束。
例如,我想要美化一下登录页面,原有的太过简单了。
我完全可以像平时开发一下,重新绘制一个登录页面,然后在配置文件中替换掉默认登录页面就可以了。
然后修改一下default_views.properties
### Login view (/login)
casLoginView.(class)=org.springframework.web.servlet.view.JstlView
casLoginView.url=/WEB-INF/view/jsp/default/ui/casLoginView.jsp
–>
### Login view (/login)
casLoginView.(class)=org.springframework.web.servlet.view.JstlView
casLoginView.url=/WEB-INF/jsp/login.jsp
重新启动,运行。
此部分来源: https://www.cnblogs.com/notDog/p/5276645.html
另外,附上 cas的说明文档
WAR Overlay 安装
CAS的安装是基于源码的基础上构建出来的,我们建议你使用WAR overlay的方式来安装,可自动自定义安装,比如自行对组件的配置,和UI的设计;构建出来的是cas.war
文件,该文件可以直接部署到servlet容器中,比如 Apache Tomcat。
安装要求
请参阅本指南了解更多信息。
War Overlay是什么?
Overlays是一种避免重复代码或重复资源的打包策略,它可以让你自行下载CAS预编译的应用后,自定义增加或者替换相应的配置和特性。在构建的时候,Maven/Gradle首先会自动下载更新安装,然后找到你的配置文件和设置,自动合并到你自动下载的目录结构中,来构建出一个完整的项目 (比如 cas.war
)。重写或覆盖的文件包括资源文件、Java的classes文件、图像文件、CSS和JS文件。
为了合并过程的成功执行,本地重写或覆盖的文件的位置和名称,必须与之前下载的存档中的项目所提供的位置和名称完全一样。
虽然前面的方法可能稍微复杂,但这种方法有显著的优势:
- 不需要从源站下载源码编译。
- 在大多数情况下,通过简单地调整生成脚本,来下载更新的CAS版本,升级非常容易。
- 与部署整个软件源代码不同的是,作为部署器,您只保留自己的本地定制,这使得更改跟踪变得更加容易。
- 源代码修改的管理和跟踪非常轻量级,配置更改只要管理修改的部分(而不是整个软件),非常的简单。
管理 Overlays
CAS的各个部分都可以通过在Overlay中新增、删除和修改文件来控制;也可以通过增加第三方组件来自定义CAS的行为。
使用覆盖的过程,无论是Maven还是Gradle,都可以概括为以下步骤:
- 以构建/部署包为基础,开始构建
- 从生成的版本中识别需要更改的工件。这些工件通常是由Maven或Gradle中的目标或生成目录生成的。
- 将已识别的文件从复制到
src
目录。- 创建
src
目录和所有的子目录,如果它们不存在的话。 - 复制的路径和文件名必须与它们的构建对应物完全匹配,否则更改不会生效。请参阅下表,了解如何将文件夹和文件从生成映射到
src
。
- 创建
- 更改之后,尽可能多次重建并重复该过程。
- 请仔细检查内置二进制文件的更改,以确保覆盖过程正常工作。
CAS WAR Overlays
CAS WAR overlay项目供参考和学习。
master主分支
,你需要确认你想要配置的部署的CAS版本。 master主分支
通过是CAS服务端最新的文档版本。确认构建的配置,如果不合理,使用git branch -a
命令来看可用的分支版本,然后使用git checkout [branch-name]
命令切换到所需要的版本。
Project | Build Directory | Source Directory |
---|---|---|
CAS Maven WAR Overlay | target/cas.war!WEB-INF/classes/ |
src/main/resources |
CAS Gradle WAR Overlay | cas/build/libs/cas.war!WEB-INF/classes/ |
src/main/resources |
要构造overlays的项目,需要在生成目录中把自定义的目录和文件复制到源目录。
在重新编辑文件之前,overlay的gradle工具可以提供额外任务,来生成二进制的项目;您可能需要手动完成这一步骤,以了解需要复制哪些文件/目录到源目录。
注意: 不要在上面提到的构建目录中做任何更改。每次构建时,更改将被除并设置为默认值。在源目录和/或其他指示的位置内放置重叠的组件以避免意外。
CAS Configuration Server Overlay
有关更多细节,请参阅Maven WAR overlay。
若要了解配置服务器的更多信息,请查看此指南。
Docker化部署
更多信息请参阅本指南。
Servlet容器
CAS可以部署到多个servlet容器中。更多信息请参阅本指南。
定制和第三方源
这是常见的定制或开发java组件,实现CAS API或包括由Maven依赖引用第三方源扩展CAS的功能。简单地在覆盖pom.xml
或build.gradle
文件。为自定义的java源码,Overlay项目应包括src/main/java
目录。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
├── src │ ├── main │ │ ├── java │ │ │ └── edu │ │ │ └── sso │ │ │ └── middleware │ │ │ └── cas │ │ │ ├── audit │ │ │ │ ├── CompactSlf4jAuditTrailManager.java │ │ │ ├── authentication │ │ │ │ └── principal │ │ │ │ └── UsernamePasswordCredentialsToPrincipalResolver.java │ │ │ ├── services │ │ │ │ └── JsonServiceRegistryDao.java │ │ │ ├── util │ │ │ │ └── X509Helper.java │ │ │ └── web │ │ │ ├── HelpController.java │ │ │ ├── flow │ │ │ │ ├── AbstractForgottenCredentialAction.java │ │ │ └── util │ │ │ ├── ProtocolParameterAuthority.java |
Maven 警告
另外,请注意,任何自定义的java组件编译要包含在最终的cas.war
文件,Overlay项目中的Maven pom.xml
必须包含Maven的java编译器,这样可以编译的java类。
以下是Maven构建配置示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
... <build> <plugins> ... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.1</version> <configuration> <source>${java.source.version}</source> <target>${java.target.version}</target> </configuration> </plugin> ... </plugins> <finalName>cas</finalName> </build> |
依赖管理
CAS的每个版本都提供了它支持的依赖列表。在实践中,您不需要为构建配置中的任何依赖项提供一个版本,因为CAS发行版正在为您管理这些版本。当升级CAS本身时,这些依赖性也将以一致的方式升级。
这个依赖列表包含第三方库的组件。这个列表可以作为标准物料清单(BOM)。
若要将项目配置为从BOM继承,只需设置父级:
Maven
1 2 3 4 5 |
<parent> <groupId>org.apereo.cas</groupId> <artifactId>cas-server-support-bom</artifactId> <version>${cas.version}</version> </parent> |
并不是每个人都喜欢从BOM继承。您可能需要使用自己的企业标准父级,或者可能更喜欢显式声明所有Maven配置。
如果不想使用cas-server-support-bom
,仍然可以通过使用scope=import
,得到依赖组件管理的好处(不是插件管理):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
<dependencyManagement> <dependencies> <!-- Override a dependency by including it BEFORE the BOM --> <dependency> <groupId>org.group</groupId> <artifactId>artifact-name</artifactId> <version>X.Y.Z</version> </dependency> <dependency> <groupId>org.apereo.cas</groupId> <artifactId>cas-server-support-bom</artifactId> <version>${cas.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> |
Gradle
使用Gradle来使用CAS BOM,请使用此指南,并相应配置Gradle构建。
(1) WAR Overlays