I installed tomcat 5.5 and it didn't start because naming-factory-dbcp.jar was missing. If you install tomcat 5.5 manually, naming-factory-dbcp.jar is installed.
The tomcat 5.5 release notes list libraries that web applications can expect to come with a standard tomcat 5.5 installation and dbcp is one of them.
This is a known issue, covered in the Tomcat Guide at http://www.gentoo.org/proj/en/java/tomcat-guide.xml
Missing Jar - naming-factory-dbcp.jar
Currently the naming-factory-dbcp.jar is not build by default. To build that jar Tomcat robs .java source files from 3 other commons packages, collections, pool, and dbcp. There is no clean solution to compiling this jar at this time. Suggestions, patches, or any assistance on compiling that jar is greatly appreciated.
*** Bug 145372 has been marked as a duplicate of this bug. ***
Updating the bug summary since this also reflects Tomcat 6.0.x as well. Now called tomcat-dbcp.jar. But built the same way. Which means we can't build it yet.
(In reply to comment #3)
> Updating the bug summary since this also reflects Tomcat 6.0.x as well. Now
> called tomcat-dbcp.jar. But built the same way. Which means we can't build it
wltrj: Please add some elog messages about this so that users at least have some change the catch what's going on.
(In reply to comment #1)
> This is a known issue, covered in the Tomcat Guide at
> Missing Jar - naming-factory-dbcp.jar
> Currently the naming-factory-dbcp.jar is not build by default. To build that
> jar Tomcat robs .java source files from 3 other commons packages, collections,
> pool, and dbcp. There is no clean solution to compiling this jar at this time.
> Suggestions, patches, or any assistance on compiling that jar is greatly
In the tomcat 5.5.23 source distro at ./build/build.xml
is the target:
and <target name="-build-tomcat-dbcp">
The target takes the directory path for the source files from these properties:
Wouldn't it be a clean solution to just patch the build script to point these properties to the source files in the gentoo distribution?
I am not experienced in writing/patchin ebuilds, but I would like to take this as a starting point, because this bug stole me hours of work... this should not happen to others.
(In reply to comment #5)
> Wouldn't it be a clean solution to just patch the build script to point these
> properties to the source files in the gentoo distribution?
If the source files are present :) More than likely I will have to add the files under src_uri so the sources are downloaded along with Tomcat sources. However which version of the sources should I use? Current or the versions that upstream is using. It's quite nasty and most all distros have voiced to upstream we dislike how they are building/re-packaging that stuff.
If you follow thread, you will see my comments on there. Also their suggestions :(
> I am not experienced in writing/patchin ebuilds, but I would like to take this
> as a starting point, because this bug stole me hours of work... this should not
> happen to others.
Yes I need to add some info about it to the merge output, elog info. Then again if your JDBC driver has it's own factory, might be best to use that. Than a generic one. And most always dropping in commons-dbcp.jar is a usable alternative. Just not ideal, and not out of the box.
Really about to break down and just download the other sources, and build said jar. They do other nastiness like that in Tomcat 6.0.x. Where they are re-packaging aspects of Eclipse JDT.
FYI to all attempting to use commons-dbcp.jar instead of tomcat-dbcp.jar.
Do not place the Resource into GlobalNamingResources as some guides to setting up resources under Tomcat 5.5 suggest.
It may be convenient, but consistently got errors of the form:
Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory]
even though factory was set as above.
Moved the Resource back under specific Context entry, and it worked fine.
Quick question. What about adding a use flag like 'jdbc' that, if enabled, DEPENDs the same version of commons-pool/dbcp that the tomcat source used then at the end of the emerge, you can use jarjar (another DEPEND) to make the tomcat-dbcp.jar from the existing commons-dbcp/pool.jars? That way you dont need the source flag enabled.
*** Bug 215179 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> Quick question. What about adding a use flag like 'jdbc' that, if enabled,
> DEPENDs the same version of commons-pool/dbcp that the tomcat source used then
> at the end of the emerge, you can use jarjar (another DEPEND) to make the
> tomcat-dbcp.jar from the existing commons-dbcp/pool.jars?
Not a working solution because there are some modifications to sources before compile, aside from changing package, and adding tomcat in there. JPackage.org came up with a solution. I just need to research and see if it applies here, or I can tweak it for our needs. Just haven't had time.
It's really a stupid long time issue. Upstream has suggested countless times to just use commons-dbcp.jar. Why they can't just modify Tomcat to use that without having to tweak sources, to create a tomcat-dbcp.jar which is basically 99% commons-dbcp. Really makes no sense to me.
But then again I have no clue why they take Eclipse jdt.jar and rename it to jasper-jdt.jar. I need to see about stopping that, and just creating a symlink to jdt.jar named jasper-jdt.jar.
Was hoping someone from the community would help address this in the form of a patch for the ebuild or etc. Given how long time the bug is. I myself just switched to using my JDBC drivers factory and at times commons-dbcp. So really isn't a problem for me, and hasn't been for some time.
But it's not ideal, and prevents the package from being 100% like upstream :(
(In reply to comment #7)
> FYI to all attempting to use commons-dbcp.jar instead of tomcat-dbcp.jar.
> Do not place the Resource into GlobalNamingResources as some guides to setting
> up resources under Tomcat 5.5 suggest.
> It may be convenient, but consistently got errors of the form:
> Failed to register in JMX: javax.naming.NamingException: Could not create
> resource factory instance [Root exception is java.lang.ClassNotFoundException:
> even though factory was set as above.
> Moved the Resource back under specific Context entry, and it worked fine.
Well, it works fine here after also adding /usr/share/commons-pool/lib/commons-pool.jar:/usr/share/commons-dbcp/lib/commons-dbcp.jar to my CLASSPATH for tomcat.
Reassigning to herd since wltjr has left Gentoo, bug #135927.
Ubuntu had the same problem, and they appear to have resolved it by including commons-dbcp and then modifying the Tomcat source to make commons-dbcp the default factory.
I don't see any reason this fix wouldn't work for gentoo as well, we'd just need to include symlinks to commons-dbcp and commons-pool libs from /usr/share/tomcat-6/lib, no?
Is this still true? Tomcat 7 is now providing his own connection pool implementation deprecating commons-dbcp
Length Date Time Name
--------- ---------- ----- ----
0 03-14-2013 16:51 META-INF/
914 03-14-2013 16:51 META-INF/MANIFEST.MF
0 03-14-2013 16:51 org/
0 03-14-2013 16:51 org/apache/
0 03-14-2013 16:51 org/apache/tomcat/
0 03-14-2013 16:51 org/apache/tomcat/jdbc/
0 03-14-2013 16:51 org/apache/tomcat/jdbc/naming/
0 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/
0 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/
0 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/jmx/
5253 03-14-2013 16:51 org/apache/tomcat/jdbc/naming/GenericNamingResourcesFactory.class
3944 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/ConnectionPool$ConnectionFuture.class
2040 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/ConnectionPool$PoolCleaner.class
20895 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/ConnectionPool.class
3123 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/DataSource.class
10861 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/DataSourceFactory.class
13075 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/DataSourceProxy.class
1975 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.class
752 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/FairBlockingQueue$ExchangeCountDownLatch.class
1510 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/FairBlockingQueue$FairIterator.class
2183 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/FairBlockingQueue$ItemFuture.class
5788 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/FairBlockingQueue.class
2996 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/JdbcInterceptor.class
788 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/MultiLockFairBlockingQueue$ExchangeCountDownLatch.class
1834 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/MultiLockFairBlockingQueue$FairIterator.class
2273 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/MultiLockFairBlockingQueue$ItemFuture.class
6213 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/MultiLockFairBlockingQueue.class
3675 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolConfiguration.class
846 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolExhaustedException.class
2559 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolProperties$InterceptorDefinition.class
2263 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolProperties$InterceptorProperty.class
12894 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolProperties.class
579 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PoolUtilities.class
11779 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/PooledConnection.class
3474 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/ProxyConnection.class
1583 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/TrapException.class
136 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/Validator.class
302 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/XADataSource.class
2127 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/AbstractCreateStatementInterceptor.class
2474 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/AbstractQueryReport$StatementProxy.class
3404 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/AbstractQueryReport.class
3748 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/ConnectionState.class
1824 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/QueryTimeoutInterceptor.class
1334 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/ResetAbandonedTimer.class
4709 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport$QueryStats.class
4960 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.class
8627 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.class
263 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmxMBean.class
2203 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementCache$CachedStatement.class
6267 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementCache.class
1261 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementDecoratorInterceptor$ResultSetProxy.class
3758 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementDecoratorInterceptor$StatementProxy.class
4182 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementDecoratorInterceptor.class
1695 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.class
12254 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/jmx/ConnectionPool.class
395 03-14-2013 16:51 org/apache/tomcat/jdbc/pool/jmx/ConnectionPoolMBean.class
2011 10-03-2012 07:56 org/apache/tomcat/jdbc/pool/interceptor/mbeans-descriptors.xml
9389 10-03-2012 07:56 org/apache/tomcat/jdbc/pool/mbeans-descriptors.xml
11356 10-03-2012 07:56 LICENSE
178 10-03-2012 07:56 NOTICE
214926 60 files
tomcat-jdbc replaces commons-pool, not commons-dbcp.
Right now you have two options, as far as I can see:
1. tomcat-jdbc (included in Gentoo Tomcat) + tomcat-dbcp.jar (not included in Gentoo Tomcat for reasons I'll never understand)
2. commons-pool + commons-dbcp from the respective packages.
I really appreciate the effort that's been put into the Tomcat instance management, that's quite a neat feature. But I'd love to see a more "standard" Tomcat in Gentoo, sticking to the Apache defaults. Missing dbcp, the classloader bug... it's all just a bit clumsy and hard to debug as a user.
Personally, I'd vote for a use flag to simply include tomcat-dbcp.jar from the official archive. That might not be the "original Gentoo way" of building that jar from the source, but it would really be a big relief for all Gentoo/Tomcat users, and might put an end to the standard forum response to Tomcat problems: "DON'T use the Gentoo package, just download the official release, it will save you a lot of headaches".
Right, it's impossible to get this working properly. I wonder how this ever got into stable arch.
Is this still issue? tomcat-dbcp.jar installed with tomcat:8 so I think notice should be removed from tomcat:8 and newer