...
Yale Production Services runs Java applications under JBoss. CAS was designed , while JASIG releases CAS for the simpler Tomcat environment.
The J2EE standard requires each application server to provide a set of standard services. Implicitly, this means that there are certain JAR files that define the standard APIs (Servlet, JPA, JSF, ...) that the application server has to provide for the running WAR. So generally there are some JAR files that the server uses for itself, some JAR files it shares with the WAR, and then the WAR itself contains private JAR files in its WEB-INF/lib directory. Tomcat and JBoss 4 or 5 solves this problem by creating separate directories of JAR files that are internal for the server or shared with the application. Unfortunately, JBoss has a lot more shared JAR files and they conflict with the JAR files that JASIG packages in the WAR it builds to run under the simpler less extensive Tomcat environment. This can produce a conflict in the Maven POM configuration file between the Version number of a dependency JAR library that was used to develop a particular release of CAS and a different Version number of the same library that was embedded in the version of JBoss you are deploying CAS under. So the standard JASIG POM has to be tweaked to change the version number and to mark certain libraries as "provided by the container" rather than as a library to be included with the applicationcreated a lot of work reconciling the Maven Dependencies in CAS to match the JBoss 5 shared libraries.
JBoss EAP 6 has a modular system of libraries similar to OSGi. Each JAR file used by the system and potentially shared with applications is stored in a separate "module" directory. An application can access any of these libraries, but unlike the previous versions of JBoss it does not get a whole mass of JAR files automatically. The WAR has to include a JBoss specific configuration file naming the modules that it wants to access. By default, a WAR file will mostly use the JAR files in its WEB-INF/lib configuration and if JBoss internally uses a different version of the same JAR file, there is no conflict.
However, the J2EE standard still requires JBoss or any other application server to automatically provide the Servlet API, JPA, and other API defining JAR files automatically to every WAR. This potentially poses a problem if there is a JAR file that JBoss has decided is part of the standard API but CAS needs to use its own local copy. We discover that the logging libraries (SLF4J and log4j) fall in this category. JBoss EAP 6 will share its logging libraries and will screw up CAS logging unless you include a WEB-INF/jboss-deployment-structure.xml file that tells JBoss to exclude the org.apache.log4j, org.slf4j, and org.slf4j.impl modules from the default shared module list. If you don't do this, then the WEB-INF/classes/log4j.xml file is read and it creates the log files, but you don't get any log messages in them (or anywhere else for that matter).
Yale has a Netid System (not just AD)
...