CAS Overlay Template’s copyCasConfiguration command

After long research, you decided to use Apereo CAS as a Single Sign-on solution. It will tell you when you go to the source code on Github.

So you change your direction to the CAS overlay template repository. This repository is a minimal version of CAS and provides great convenience in development and deployment (https://github.com/apereo/cas-overlay-template).

With every change you make to the project, you run the following commands in order as specified in the README.

./gradlew[.bat] copyCasConfiguration
./gradlew[.bat] war (or explodeWar)
./gradlew[.bat] run

The last two commands are commands that seem to do what they do. The “war” command is responsible for packaging the project and making it artifact with the extension .war (You can see the .war file under the build/libs directory.). The “run” command allows to run the .war package.

But what exactly is the function of the “copyCasConfiguration” command?

After running this command, you will see that the files of the project under the /etc/cas directory are copied to the root directory of the computer. If this is not done, most things will not work in CAS file operations.

Why?

Because after the jar/war is created, the url/uri of the files is as follows.

jar:file:/C:/Users/denizg/Desktop/cas-overlay-template/build/libs/cas.war!/BOOT-INF/classes!/mfaSelector.groovy

In most of the methods used by CAS for file operations, it is checked whether the file exists or not, and it is checked that the file protocol starts with file: in this process. For example,

public static File getFile(URL resourceUrl, String description) {
   Assert.notNull(resourceUrl, "Resource URL must not be null");
   if (!"file".equals(resourceUrl.getProtocol())) {
     throw new FileNotFoundException(description + " cannot be resolved to absolute file path because it does not reside in the file system: " + resourceUrl);
   } else {
     try {
        return new File(toURI(resourceUrl).getSchemeSpecificPart());
     } catch (URISyntaxException var3) {
        return new File(resourceUrl.getFile());
     }
   }
}

CAS uses the above method for file operations. While waiting for “file” as a protocol, “jar:file:” is encountered and a file error is thrown. Therefore, the expected file operations do not occur.

Related questions;

File inside jar is not visible for spring

Classpath resource not found when running as jar

Therefore CAS does not include files in artifacts such as .jar/.war. It always copies under the root directory and performs file operations over the root directory.