JNDI error with Roller weblogger on Fedora Core 5
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
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.