Configuring BRMS 5.0.2 with Oracle 11, JNDI and XA-DS

When deploying BRMS to a production system it is at times important to encrypt the database user’s password in the configuration. By default Jackrabbit does not have means of doing this, however it has the ability to use a data source lookup through JNDI. This gives us an apportunity to use the (more on this here

Before we start however we have to deal with some technology limitations:

BRMS 5.0.2 ships with Apache Jackrabbit 1.4. When configuring Jackrabbit with Oracle using it’s default org.apache.jackrabbit.core.fs.db.DatabaseFileSystem, you will run into JIRA (the initialization of the repository will fail due to Oracle converting empty strings to null values). But wait, Jackrabbit provides a specialized implementation for this issue called org.apache.jackrabbit.core.fs.db.OracleFileSystem which is great, however its ability to deal with JNDI is not there in Jackrabbit 1.4 ( This was added in Jackrabbit 1.5 ( OracleFileSystem extends DbFileSystem in case you haven’t noticed 😉

So the first thing we need to do is upgrade BRMS 5.0.2 to use the Jackrabbit 1.5 jars. Thankfully this is just a drop-in jar replacement.

Once you upgrade to Jackrabbit 1.5 and configure your repository.xml to use OracleFileSystem like shown in this small sample:

<FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
       <param name="driver" value="javax.naming.InitialContext"/>
       <param name="url" value="jdbc/brms/db"/>
       <param name="schema" value="oracle"/>
       <param name="schemaObjectPrefix" value="FS_"/> 

And start up your JBoss server instance however another issues comes up described in JIRA Basically the AS will wrap the underlying java.sql.Connection to org.jboss.resource.adapter.jdbc.WrappedConnection. The Jackrabbit code however in org.apache.jackrabbit.core.fs.db.OracleFileSystem uses the java.sql.Connection directly which results in the “pretty” ClassCastException shown in the JIRA.

One way to solve this problem is to modify the Jackrabbit source and rebuild the jars, however adding JBoss-specific classes such as org.jboss.resource.adapter.jdbc.WrappedConnection to the Jackrabbit source is not really the best idea, as it makes it JBoss specific. Another way is to actually extend org.apache.jackrabbit.core.fs.db.OracleFileSystem and make a JBoss-specific implementation which can be deployed as an individual jar. For other Appservers then you can create a specialized jar for it and deploy as needed. Even though none are ideal solutions here we show how to do the second option:
We need to modify the OracleFileSystem source ( ) to fix the ClassCastException.

First we modify the init method:

public class JBossOracleFileSystem extends DbFileSystem { 
public void init() throws FileSystemException {

        // initialize oracle.sql.BLOB class & constants

        // use the Connection object for using the exact same
        // class loader that the Oracle driver was loaded with
        try {
        	if (con instanceof WrappedConnection) {
				oracleCon = ((WrappedConnection) con).getUnderlyingConnection();
        	blobClass = oracleCon.getClass().getClassLoader().loadClass("oracle.sql.BLOB");
            durationSessionConstant =
                    new Integer(blobClass.getField("DURATION_SESSION").getInt(null));
            modeReadWriteConstant =
                    new Integer(blobClass.getField("MODE_READWRITE").getInt(null));
        } catch (Exception e) {
            String msg = "failed to load/introspect oracle.sql.BLOB";
            log.error(msg, e);
            throw new FileSystemException(msg, e);

Then we have to also make sure that “oracleCon” is used when creating the blobs:

 protected Blob createTemporaryBlob(InputStream in) throws Exception {
        Method createTemporary = blobClass.getMethod("createTemporary",
                new Class[]{Connection.class, Boolean.TYPE, Integer.TYPE});
        Object blob = createTemporary.invoke(null,
                new Object[]{oracleCon, Boolean.FALSE, durationSessionConstant})

Export this class into a JAR and deploy it in $JBOSS/$CONFIG/deploy/jboss-brms.war/WEB-INF/lib directory. Now in our repository.xml we can use JBossOracleFileSystem, for example:

<FileSystem class="org.jboss.jackrabbit.core.fs.db.JBossOracleFileSystem">
       <param name="driver" value="javax.naming.InitialContext"/>
       <param name="url" value="jdbc/brms/db"/>
       <param name="schema" value="oracle"/>
       <param name="schemaObjectPrefix" value="FSS_"/>

Next steps are to define our xa data source in $JBOSS/$CONFIG/deploy/jboss-brms-ds.xml:

        <xa-datasource-property name="URL">

    <mbean code="org.jboss.resource.adapter.jdbc.vendor.OracleXAExceptionFormatter"
        <depends optional-attribute-name="TransactionManagerService">

and define your security domain in $JBOSS/$CONFIG/conf/login-config.xml:

<application-policy name="YOUR_SECURITY_DOMAN">
            <login-module code="" flag="required">
                <module-option name="username">YOUR_DB_USER</module-option>
                <module-option name="password">YOUR_ENCRYPTED_DB_USER_PASSWORD</module-option>
                <module-option name="managedConnectionFactoryName">jboss.jca:name=jdbc/brms/db,service=XATxCM</module-option>

You can find more information on how to encrypt your password at

Make sure you have the oracle driver jar in $JBOSS/$CONFIG/lib and now you are using BRMS 5.0.2 with JNDI and XA DS..congrats 😉
Note that this is a non-issue with the upcoming BRMS 5.1 release as well as community Guvnor as they both use Jackrabbit 2.1 where this issue has been fixed as now the code uses ConnectionFactory.unwrap() and does not directly pass the java.sql.Connection when creating blobs:

 private Blob createTemporaryBlob(Connection con, InputStream in) throws Exception {
         * BLOB blob = BLOB.createTemporary(con, false, BLOB.DURATION_SESSION);
         *; OutputStream out = blob.getBinaryOutputStream(); ... out.flush();
         * out.close(); blob.close(); return blob;
        Method createTemporary =
            blobClass.getMethod("createTemporary", new Class[]{Connection.class, Boolean.TYPE, Integer.TYPE});
        Object blob =
            createTemporary.invoke(null, new Object[]{ConnectionFactory.unwrap(con), Boolean.FALSE,
        Method open = blobClass.getMethod("open", new Class[]{Integer.TYPE}); 

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: