Historique de la page

Quand une modification est-elle prise en compte ?

• CSS : fichiers statiques servis par tomcat. voir astuces war, auto-déploiement
• html : templates thymeleaf mis en cache à la première utilisation. voir astuces thymeleaf, war, auto-déploiement

• etc/cas/config/log4j2.xml : monitoré par CAS, pris en compte dynamiquement (monitorInterval 5 secondes)

• etc/cas/config/cas.properties : monitoré par CAS, plusieurs modifications prises en compte dynamiquement (réf) ou via un POST sur /actuator/refresh
• etc/cas/services/*.json : monitoré par défaut par CAS, modifications/ajouts/suppressions pris en compte dynamiquement (cf cas.service-registry.schedule + cas.service-registry.json.watcher-enabled)
• groovy files : monitoré par CAS, pris en compte dynamiquement (avec cache pour éviter la recompilation)
• message_fr.properties : pris en compte par POST sur /actuator/refresh

• java : build & restart ou parfois hotswap
• pom.xml : build & restart. Un "clean" peut-être nécessaire en cas de chgt de versions de jar

Comment accélérer

...

les tests suite à des modifications de l'overlay CAS ?

Désactiver le cache thymeleaf

spring.thymeleaf.cache=false

(cf https://fawnoos.com/2021/02/16/cas63-ui-themes/ ou pas un CAS plus vieux https://apereo.github.io/2018/06/10/cas-userinterface-customizations/ )

Mettre les templates en dehors du WAR

Comme expliqué sur la page https://fawnoos.com/2021/02/16/cas63-ui-themes/ , il est possible de dire à CAS de prendre les fichiers statiques en dehors du WAR, par exemple dans /etc/cas/templates.

(à valider)

War avec Embedded tomcat

NB : solution alternative aux templates en dehors du WAR, et à "bootrun" (qui marche plus ou moins bien...)
Difficile de faire prendre en compte les modifs quand on utilise le war avec embedded tomcat.
Solution intermédiaire à l'utilisation d'un tomcat externe :

au lieu de

java -jar xxx/build/libs/cas.war
# ou avec maven :
java -jar xxx/target/cas.war

utiliser

gradlew unzipWAR
java -cp "xxx/build/app:xxx/build/app/WEB-INF/classes:xxx/build/app/WEB-INF/lib/*" org.springframework.boot.loader.WarLauncher
# ou avec maven :
java -cp "xxx/target/cas:xxx/target/cas/classes:xxx/target/cas/WEB-INF/lib/*" org.springframework.boot.loader.WarLauncher

NB : avec maven le répertoire target/cas est créé en plus du war. Je crois qu'avec gradle ce n'est plus le cas ? Dans ce cas un unzip fait l'affaire :)
* Pour les templates thymeleaf, désactiver le cache thymeleaf
Mettre ceci dans cas.properties :
spring.thymeleaf.cache=false
(cf https://apereo.github.io/2018/06/10/cas-userinterface-customizations/ )
* Dilemne entre "modifier dans les sources de l'overlay + lancer un build" (lent) ou "tester en modifiant dans target/ puis reporter dans les sources" (fragile)
Solution : utiliser un script transformant les fichiers dans target/ en symlink vers la source :
mvn package && compareDirsAndSymlinkSameFiles src target/cas
Le script utilisant "fdupes" pour trouver les fichiers identiques : https://github.com/UnivParis1/server-scripts/blob/master/bin/compareDirsAndSymlinkSameFiles
NB : ça marche sans pb avec le tomcat interne spring-boot. Avec un tomcat externe (de test), il faut modifier conf/context.xml : <Resources allowLinking="true" />

Auto-déploiement des modifications dès la sauvegarde des fichiers

Voir la page générique expliquant cette problématique du développement Java