Bugzilla Bug 144276

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
> yet.
> 

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
> 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.
> 

In the tomcat 5.5.23 source distro at ./build/build.xml
is the target:
 <target name="build-tomcat-dbcp">
and <target name="-build-tomcat-dbcp">

The target takes the directory path for the source files from these properties:

${commons-collections.home}
${commons-pool.home}
${commons-dbcp.home}

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.

http://marc.info/?l=tomcat-dev&m=115808287528288&w=2

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.
        <Resource 
                name="jdbc/app" 
                auth="Container"
                type="javax.sql.DataSource"
                factory="org.apache.commons.dbcp.BasicDataSourceFactory"
                driverClassName="com.mysql.jdbc.Driver"
        url="jdbc:mysql://localhost:3306/app"
        username="root" 
                password="" 
                maxActive="40"
                maxIdle="2"
                maxWait="60000"
        />
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.
>         <Resource 
>                 name="jdbc/app" 
>                 auth="Container"
>                 type="javax.sql.DataSource"
>                 factory="org.apache.commons.dbcp.BasicDataSourceFactory"
>                 driverClassName="com.mysql.jdbc.Driver"
>         url="jdbc:mysql://localhost:3306/app"
>         username="root" 
>                 password="" 
>                 maxActive="40"
>                 maxIdle="2"
>                 maxWait="60000"
>         />
> 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.

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.