...
Yale Production Services runs Java applications under JBoss, 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 less extensive Tomcat environment. This created 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)A Web Application like CAS is packaged in a WAR file. The WAR file contains a bunch of JAR files in the WEB-INF/lib directory and the Java standard says that these JAR files are used first, and only then does the application server search its own libraries. That used to work fine and in Tomcat where the application server provides almost nothing in the way of library services it still works.
However, the modern J2EE standard requires that a full function server provides a wide range of built in services. Sometimes the server (JBoss) has to create a certain type of object and pass it to the application. When the server creates something, it uses its own JAR library files. However, because Tomcat doesn't provide a full set of services, programs like CAS are often packaged up with their own copies of some version of the same JAR files that CAS uses in Tomcat because the server doesn't provide that function itself.
With each new version of JBoss and each new release of CAS, one has to use trial and error to discover conflicts between the JBoss version of a particular service and the version of the same function that comes built into the CAS WAR. Frequently it is just a matter of deleting a JAR file from WEB-INF/lib in CAS. Alternately, you can add an XML element in the JBoss configuration file in CAS to override the normal JBoss processing and absolutely require that JBoss use the CAS JAR and not its own JAR.
The most perplexing problem, but one that everyone can understand, comes from the generic problem of logging errors.
First, there are lots of different ways to do logging and long ago Java gave up trying to develop any standard. Instead there is log4J, slf4j, Commons Logging, and about a dozen other competing solutions to the same problem. Even within a single application, CAS has to consider that different libraries it uses will each have selected a different logging interface. So all the different logging systems get along with each other quite nicely within any application.
However, when you run a bunch of applications inside a server like JBoss, there are two different ways you might like to operate. If the administrator of the JBoss server is also the person expected to read the logs and debug problems, then he wants to control all the logging at the JBoss server level and control what he sees. On the other hand, if five different applications written by five different developers share the same server, and each developer is responsible for his application, then each developer wants to control his own log files and logging options.
JBoss EAP 6.1 tries to leave both options available, but in our experience it is almost impossible to really get the CAS logging details you want if you try to configure the logging at the JBoss server level. However, to transfer 100% of CAS logging control to the configuration files in the CAS application, you have to include a JBoss configuration file in the CAS application that lists absolutely every possible log related JAR file that JBoss and CAS could both know about. That turns out to be 4 jboss logging jars, 4 slf4j jars, the log4j jar, and the commons logging jar. If you forget one of them, then JBoss ends up trying to hook some of the logging and CAS tries to hook some of the logging and you end up with no log messages anywhere.
Yale has a Netid System (not just AD)
...