While planning my upgrade from Roller 2.1 to 2.3, I ran into an unexpected snag in Tomcat 5.5 running on Fedora Core 5. After I installed Roller 2.3 on my Fedora server and upgraded my database, Tomcat couldn’t seem to create the <Resource> for the JDBC datasource. My catalina.log file had this unrevealing (to me) error:

Sep 22, 2006 9:23:29 AM org.apache.catalina.core.NamingContextListener addResource
WARNING: Failed to register in JMX: javax.naming.NamingException: Cannot create resource instance
Sep 22, 2006 9:23:47 AM org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
Sep 22, 2006 9:23:47 AM org.apache.catalina.core.StandardContext start
SEVERE: Context [/roller] startup failed due to previous errors
Exception in thread "Thread-9" java.lang.NullPointerException
at org.apache.roller.business.runnable.WorkerThread.run(WorkerThread.java:83)
at org.apache.roller.business.runnable.ContinuousWorkerThread.run(ContinuousWorkerThread.java:83)

The “Error filterStart” message seems to be Tomcat telling me that it couldn’t start one of Roller’s servlet filters after WorkerThread threw the NPE. Nowhere was Tomcat telling me, however, what resource it was trying to add at the time.

The messages in the roller.log file showed more helpful information. Roller obviously couldn’t pull the DataSource from JNDI using the naming context java:comp/env/jdbc/rollerdb:

INFO  2006-09-22 09:23:30,239 RollerConfig:<clinit> - successfully loaded default properties.
INFO  2006-09-22 09:23:30,293 RollerConfig:<clinit> - successfully loaded custom properties file from classpath
INFO  2006-09-22 09:23:30,297 RollerConfig:<clinit> - no custom properties file specified via jvm option
WARN  2006-09-22 09:23:30,347 RollerContext:upgradeDatabaseIfNeeded - Unable to access DataSource
javax.naming.NamingException: Cannot create resource instance
[stack trace]
[Hibernate logging statements]
INFO  2006-09-22 09:23:41,904 NamingHelper:getInitialContext - JNDI InitialContext properties:{}
FATAL 2006-09-22 09:23:41,914 DatasourceConnectionProvider:configure - Could not find datasource:
java:comp/env/jdbc/rollerdb
javax.naming.NamingException: Cannot create resource instance
[stack trace]
ERROR 2006-09-22 09:23:41,928 RollerFactory:setRoller - Error instantiating org.apache.roller.business.hibernate.HibernateRollerImpl
java.lang.reflect.InvocationTargetException
[stack trace]
Caused by: org.apache.roller.RollerException
at org.apache.roller.business.hibernate.HibernateRollerImpl.<init>(HibernateRollerImpl.java:73)
at org.apache.roller.business.hibernate.HibernateRollerImpl.instantiate(HibernateRollerImpl.java:84)
... 31 more
FATAL 2006-09-22 09:23:41,938 RollerFactory:setRoller - Failed to instantiate fallback roller impl
java.lang.Exception: Doh! Couldn't instantiate a roller class

Still, the log messages weren’t pointing me to why the datasource wasn’t getting registered. I checked and double-checked the spelling from my Tomcat roller.xml context file and couldn’t find any typos or bad configuration settings:

<Context
path="/roller"
docBase="/home/tom/apps/roller/2.3/roller"
debug="0"
/>
<Resource
name="jdbc/rollerdb"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/roller?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&mysqlEncoding=utf8"
username="[username]"
password="[password]"
maxActive="20"
maxIdle="3"
removeAbandoned="true"
maxWait="3000"
/>

My roller configuration seemed correct. My initial Google search didn’t turn up a solution, and neither did my search of the Roller FAQs or the Apache roller-user mailing list. But I did notice that if I google the exact string, “WARNING: Failed to register in JMX: javax.naming.NamingException: Cannot create resource instance,” from the Tomcat log, the two search returns both mentioned Fedora Core. My environment:

O/S: Fedora Core 5 (Linux kernel 2.6.17)

Server: Tomcat 5.5.15 (from FC5 “core” repository)

JVM: Sun’s Java 1.5 (build 1.5.0_07-b03)

Database: MySQL 5.0.22 (from FC5 repository)

I thus shortened some of my search terms and added “Fedora Core 5” into the search, and came across this message from PKR Internet’s task list for its “Taskjitsu” product that pointed right at the problem. According to that message, Tomcat 5.5 is built so the default datasource naming factory is org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory from the naming-factory-dbcp.jar JAR file. But the Fedora Core install package for Tomcat 5.5, tomcat5-5.5.15-1jpp_6fc, does not ship that JAR or its factory class in any other JAR file.

There are two ways to solve the problem. The first is to add a factory attribute to the Roller webapp’s roller.xml context with a <Resource> element that defines the Jakarta commons DBCP BasicDataSourceFactory class:

factory="org.apache.commons.dbcp.BasicDataSourceFactory"

The second way is to grab a copy of naming-factory-dbcp.jar from a binary distribution of Tomcat 5.5 and install it in Fedora Core’s Tomcat common/lib directory (default /usr/share/tomcat5/common/lib). I don’t know if one solution is preferable to the other. Both solutions work, and the latter solution probably will resolve the same issue for other web applications. However, it seems adding two JARs that might share some of the same classes could lead to future ClassCastExceptions if for some reason the order of the JARs change in a classpath search. This event doesn’t seem likely, though, as long as Tomcat controls the search order for classes in common/lib. Comments appreciated on whether one solution is better than the other.

After I found these solutions, I was going to post it as an FYI to the roller-user mailing list. Before I did, I poked again through the list archives to see if someone else already mentioned it. Sure enough. I found this email from Conor P. Cahill, posted July 6, by searching for fedora. Conor’s subject line was “MySQL Database connector problems,” which is why I think I missed it on my first search.

His email detailed the problem and proposed adding the factory attribute to the element.

Since I didn’t find Conor’s email on my first search for a solution, I thought I’d post the problem and solution here, with the log errors, in the hope it helps other Fedora Core users.