2EE or not 2EE

CAS is a standalone application with a very high security profile. You would not want to run other applications with a lower security profile in the same application server. CAS was developed to run in Tomcat and it embraced Spring Framework at a time when Spring was presented as a J2EE alternative.

Then things changed. Servers now have many more cores, much more memory, and routinely run in 64 bit mode. J2EE changed, replacing the old, complex EJB 2 disaster with a simpler modern model of JSF+JPA+EJB3 and annotation driven dependency injection. CAS has no need to run in a full J2EE server and will make no use of the additional services. However, as you develop your own extensions, you may find that the business logic needed for a particular AuthenticationHandler or CredentialsToPrincipalResolver plugin component are already available but packaged as an EJB.

While CAS doesn't need the full J2EE environment, it will run in JBoss 5 or Glassfish 3. Larger installations standardize on environments that support a wide range of applications. As each revision of J2EE becomes more attractive, and the additional memory cost becomes less important, a wider range of user may migrate from Tomcat to JBoss.

In a small organization, or when CAS is regarded as a secondary application, a single person may be assigned to choose the hardware, operating system, application server, and to install and maintain CAS. In larger organizations, however, different professionals will specialize in particular concerns. In a High Availability environment, multiple CAS servers may be positioned behind a BIG-IP F5 frontend, and they may replicate the ticket cache using whatever standard technology the organization uses to replicate session and transaction state. CAS may be simply one of many applications managed by a combination of programmers, security specialists, network managers, and system administrators. To make this work, the configuration of the database connection should be done by the database specialist, while the configuration of ticket replication would be done by the cluster specialist. The way to achieve this separation of specialties and concerns is to run all applications in a serious application server that breaks these different aspects out into different configured services.

CAS is designed to run in a simple Tomcat, so that deployment will remain supported into the indefinite future. There isn't much experience deploying CAS in a larger container, but this is probably the time to start thinking about it.

One thing you can do if you move up to a real J2EE container like JBoss of Glassfish is to package CAS in an EAR. An EAR is simply yet another Zip file that contains library JARs and WARs. The current CAS Maven projects create JAR artifacts for every optional project, and then package the HTML/JSP pages along with libraries and previously generated JAR artifacts in a WAR

Skinny WAR

With very little change, you can create a "Skinny WAR". This involves creating a new Maven project to generate an EAR. The EAR contains the existing cas-server-webapp WAR, and you copy over to the EAR project all the dependencies from the current WAR file and modify the WAR project to contain no libraries. The only trick is that the TLD files that define JSP syntax have to be extracted and placed in the WAR because they are the one item from the classpath that cannot be moved out of the WAR.

If this is all you do, then the effect will have been to move the contets of the WEB-INF/lib from the WAR to the /lib subdirectory of the parent EAR that contains the WAR. By itself, this does nothing. Until, however, you add a second WAR to the EAR for a related application that manages the Service table or provides more detailed status to administrators. JAR files that are inside the WAR are visible only to code in the WAR, but JAR files that are packaged at the EAR level can be shared by more than one Web application contained inside the EAR. They can also be used by EJB code that you add to the package to perform special credential validation using smart cards or PKI.

When code in CAS or any other Web application looks for a class, the Servlet standard requires the container to first search the WEB-INF/classes directory for a matching class name. If the name is not found, then all of the JAR files in the WEB-INF/lib are searched in no particular special order. If the name is not found there, then in a real J2EE container the JAR files in the EAR will be searched (and files in common/lib of the container). In Maven, any actual Java source in the src/main/java subdirectory of the WAR project will end up in WEB-INF/classes, and they will override any classes of the same package+classname in any dependency JAR artifact. The Skinny WAR provides a second override option, where JAR artifacts explicitly included in the WEB-INF/lib are searched before JAR artifacts implicitly included in the enclosing EAR.

This produces an alternate packaging option if you want to maintain minor changes to a few classes in CAS, say to create a version of the class that is not "final", but you just want to maintain the one modified class in some project rather than maintaining a complete copy of the cas-server-core project just so that one "final" can be deleted from that one source file. In Tomcat you have to put the override source in the cas-server-webapp WAR project so it is generated in the WEB-INF/classes and overrides all JARs, but with a skinny WAR you have two sets of JARs and the ones in the WAR override the ones in the EAR. So you can build Maven projects that build regular JAR artifacts and know that they will be selected first before the vanilla JA-SIG artifacts.