As is typical in application servers, classloader problems, class isolation and clashes between library versions can cause problems.
To influence the behaviour for war files which are deployed in JBoss there is a setting which influences this.
The explanation of this setting (as mentioned in the file itself) is :
A flag indicating if the JBoss Loader should be used. This loader uses a unified class loader as the class loader rather than the tomcat specific class loader. The default is false to ensure that wars have isolated class loading for duplicate jars and jsp files.
When this setting is set to false, the war has it’s own classloader and jar clashes are avoided. It sounds like you always want, this, but it hides all JBoss libraries and all other deployed artifacts. With this option you have to include all external dependencies in your application and all communicates with the other deployed artefacts will use serialization.
When the setting is set to true, the unified classloader is used, making all deployed artifacts visible. This has a couple of implications.
- Libraries which are contained in the JBoss (server/x/lib) are visible. It is recommended that such libraries are not duplicated in your war file (some libraries like commons-logging explicitly disallow this, in general it may still result in class not found problems).
- Other deployed artifacts are usable, however, the deployment order may be important (particularly for code executed during deployment or once deployed).
- Library version differences are problematic. Not only compared with JBoss included libraries but also compared with other web archives and other deployed artifacts. This specifically can cause problems for libraries which do discovery of plugins or components based on classpath navigation (like for example Tapestry), especially as the deployment order also comes into play at this case.