This page last changed on Nov 30, 2006 by jon@atlassian.com.
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
 | Atlassian do not currently support configuring Confluence on the same JBoss instance as an existing Confluence or JIRA server. |
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.
 | Putting this anywhere else in the file will probably break your JBoss logging configuration. |
<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>
The warning about potential issues is accepted. However, there are no answers on how to deploy confluence on an existing jboss application server, despite the page being titled 'Running Confluence on JBoss.' Perhaps, this can be rectified by the responsible parties?

Posted by at Sep 14, 2005 08:34
|
The process for installing Confluence into an existing application server is covered here: Installing the WAR version. The instructions assume you are already familiar with installing a WAR application into your existing J2EE application server.
If you do not know how to install a WAR into JBoss, we suggest you stick with the standalone Confluence distribution, which is bundled with its own application server. Java application servers can be tricky beasts, and unless you already know how to run them, it's best to stick with the simplest (and most effectively supported) option.

Posted by at Sep 14, 2005 09:46
|
FYI, I have successfully installed Confluence 2.1.3 and Jira 3.5.3 into the same JBoss 3.2.7 instance. The notable things I had to do were:
- modify the jboss-service.xml for the embedded Tomcat to not use JBoss's UCL and to not use Java 2 style classloading
- this is good practice for all JBoss setups, IMO
- removed commons-logging & log4j jars from Confluence & Jira's webapps
- I don't know why there remained a conflict with these libs in place despite the classloading adjustments
- renamed the "debug" folder in the Jira war to "xdebug" because there was some problem on startup as it searched for some file
- ideally Atlassian would diagnose and fix whatever is going wrong. At least the "debug" folder isn't necessary for Jira use; I probably could have deleted it.
Note: although JBoss can handle being in a directory whose path contains spaces, either Confluence or Jira couldn't handle that (I forget which) so I was forced to move JBoss.

Posted by dsmiley at Apr 28, 2006 07:43
|
FWIW We run both Confluence as a war Version: 2.2.9 Build:#527, and Jira as a war , Version: 3.3.3-#99, on one Jboss 4.03 instance.
We already run with the Jboss isolated classloader. So the only things I had to do were
- remove log4j.jar, commons-logging.jar from lib
- remove the log4j.properties in classes
- add a jboss-web.xml into classes (for the virtual host details)
And the war hot-deployed. Too easy.
The bit about the default config of Jboss running in default as debug level in log4j is a little bit alarmist. If you were running Jboss in production you would very likely have sorted this out. Likewise the comment about the Jboss classloader, you probabley understand this issue if you run Jboss already. Anyway, installing Confluence took a few minutes. Cheers.

Posted by lindsay.smith@telrock.com at Oct 13, 2006 04:59
|
Thanks for the informative comment Lindsay.

Posted by ivan@atlassian.com at Oct 15, 2006 17:25
|
Thanks for the information, Lindsay.
This document is a year and a half old, and represents the state of our knowledge after spending almost six months trying ourselves, and collaborating with customers, to get Confluence and JIRA running together. At the time, the most we could get was anecdotal evidence from one or two customers that it was possible, based on configuration recipes that we were entirely unable to reproduce in-house.
As such, the page may be a little out of date, and might reflect a little more frustration than it should. 
The bit about the default config of Jboss running in default as debug level in log4j is a little bit alarmist. If you were running Jboss in production you would very likely have sorted this out.
If only this were true. If we hadn't had this problem show up so often in support cases, we wouldn't have had to document it so clearly.

Posted by cmiller at Oct 16, 2006 02:45
|
Thanks, Lindsay, this helped me a lot. I got this to work under JBoss 4.0.5 GA.
I do have a couple of comments:
The jboss-web.xml is not placed in WEB-INF/classes. I put it in WEB-INF, which is where the container-independent web.xml lives, as per standard.
Here's what my jboss-web.xml looks like:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 2.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">
<jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
com.example:loader=unique-archive-name
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
<context-root>/confluence</context-root>
</jboss-web>

Posted by gmack at Jan 08, 2007 16:15
|
I just wanted to report back confirming that I got Confluence deployed as a war file inside the JBoss default server deploy directory. I had some problems that were easy to fix:
- The default memory config for JBoss is too low, and I experienced out of memory errors after multiple undeploy-deploy cycles. I bumped it up to 786 MB (min and max) and restarted. This worked.
- I'm using MySQL and got bitten when I didn't create the database using UTF-8. Re-created it.
- Occasionally forgot to run jboss as my "jboss" user, and had permission problems with the Confluence data directory, so watch out for that.
- Had weird "missing macros" errors when creating an initial empty space. It's better to start with the demo space and then create other spaces.

Posted by gmack at Jan 08, 2007 18:34
|
One more insight. To get both Jira and Confluence to deploy together, using separate class loaders, I had to increase the size of the permgen space, to allow space for the duplicated classes that exist in both.
That's the -XX:MaxPermSize parameter, which is configured in the run.conf file for jboss, in the bin directory. I made it 256 MB (!).
It would be nicer to remove duplicated jars across the two apps.

Posted by gmack at Jan 13, 2007 22:09
|
|