Known Issues for JBoss

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:

ERROR [lifecycle] The root log4j logger is set to DEBUG level. This may cause Confluence to run slowly.
ERROR [lifecycle] If you are running Confluence under JBoss, please read http://confluence.atlassian.com/x/PtAB
ERROR [lifecycle] To disable this error message, start Confluence with the system property -Dconfluence.ignore.debug.logging=true

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>

International Characters in Attachment File Names

JBoss uses Apache Tomcat as its servlet engine. To support international characters in URLs it is not sufficient to only configure JBoss to use an encoding such as UTF-8; you must also configure Tomcat to process URLs using your selected encoding.

Inside JBoss you'll find the tomcat server.xml here:

<jboss home>/server/default/deploy/jbossweb-tomcat55.sar/server.xml

Here is an example configuration for the HTTP connector listening on port 8080:

<!-- A HTTP/1.1 Connector on port 8080 -->
      <Connector port="8080" address="${jboss.bind.address}"
         maxThreads="250" strategy="ms" maxHttpHeaderSize="8192"
         emptySessionPath="true"
         enableLookups="false" redirectPort="8443" acceptCount="100"
	 connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" />

Note the URIEncoding attribute should be set to your desired character encoding.

-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE startup directive

If you are experiencing a problem with missing images when generating a PDF page export and following error is found in the logs:

[30-10-2007 05:10:41.944] [249524602] [STDOUT] [INFO ] [ajp-0.0.0.0-61781-15] 2007-10-30 05:10:41,939 ERROR [ajp-0.0.0.0-61781-15] [confluence.importexport.impl.AbstractExporterImpl] exportResource The image /Wiki/download/attachments/39308/Overview1-1.gif cannot be exported
 -- url: /Wiki/pages/doexportpage.action | userName: mimzg | action: doexportpage | page: 39308
javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1

This is due to more strict Servlet 2.5 specifications on JBoss.
This can be experienced on JBossAS-4.2.0.GA and can be fixed by adding the following startup directive to the server and restarting it:

-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false