A Quick Note about Confluence and JBoss
Confluence does not make any use of the JBoss container beyond its embedded Tomcat web application server, as can be easily demonstrated by the fact that our standalone Confluence ships with, and runs entirely inside, Tomcat. In addition deploying Confluence inside JBoss can cause additional problems, as described below.
While JBoss is a supported platform, and (subject to the limitations below) you can deploy Confluence into it successfully, we recommend that unless there is some overriding reason to run JBoss - i.e. you are making use of its specific management features, or you're already running several other JBoss servers and want to keep your deployments consistent - you just run Confluence directly under Tomcat instead.
JBoss and Multiple Application Deployments
Due to JBoss's inventive interpretation of the J2EE Classloader specification, multiple applications deployed on the same JBoss instance can interfere with each other. The most common symptom of this problem from the Confluence side is for a user to be unable to edit their profile (although it causes many other seemingly random problems). As such, we do not recommend running Confluence on the same JBoss instance as any other J2EE application.
This issue is reported in CONF-1635.
Some customers have reported success having Confluence share a server with other Confluence or JIRA instances by tweaking their classloader settings or server configurations. A number of recipes for doing so are mentioned below in comments. We currently have not verified these configurations at Atlassian. You're welcome to try them yourself, but if they do not work for you, we can not currently provide support getting them to work.
JBoss Root Logging
On starting up Confluence under JBoss, you may see the following message logged to the console:
By default, JBoss ships with the root confluence logger set to DEBUG level. This means that Confluence (and any other log4j-enabled application deployed in the JBoss server) will spend a lot of time generating debugging information that will just end up wasting processor cycles and disk space.
To fix this problem, edit the conf/log4j.xml
file in your JBoss server installation. Find the following section:
<root>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
Replace it with this:
<root>
<priority value ="warn" />
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
This will raise the default log level to WARN, which is where Confluence is most comfortable running day-to-day. Logging at INFO level should also be safe, but it will result in a lot more unnecessary information being logged. We recommend you keep Confluence logging at WARN level unless something is going wrong that you need to diagnose (or you're asked to log at a lower level by support).
Additional log4j.xml
Configuration
The Confluence log4j.properties
file includes some additional logging configuration, which is overridden by JBoss's log4j.xml
. To set logging to the same level as the standard Confluence distribution, you should include the following in log4j.xml
immediately above the root declaration you edited above.
<logger name="com.atlassian.confluence.lifecycle" additivity="false">
<level value="INFO"/>
<appender-ref ref="FILE"/>
<appender-ref ref="CONSOLE"/>
</logger>
<logger name="com.atlassian.confluence.upgrade" additivity="false">
<level value="INFO"/>
<appender-ref ref="FILE"/>
<appender-ref ref="CONSOLE"/>
</logger>
http://www.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases