naming-factory-dbcp.jar nonsense

[Dan Armbrust]

So, I have an issue with tomcat's database connection pool.  Namely,
my connections keep getting closed, instead of reused.

I figured that the easiest way to figure out what was going wrong was
to put this in my debugger, so I could follow the close() call which
should release the db connection back to the pool, instead of actually
closing the connection.

Now I just needed the source code, so I could follow it in the
debugger.  Then, after much searching, I discover this nutty sequences
of events:

Tomcat doesn't actually implement the connection pool - it is actually
from the apache-commons-dbcp project.  Great - code reuse - just like
it should be.

Tomcat's build script downloads a version of apache-commons-dbcp as
part of its build script.  It doesn't download a jar file, no, it gets
the source.  Thats kinda strange...
Then, it proceeds to refactor and rename the source code from
apache-commons-dbcp.  WTF?
Then, it compiles that into the naming-factory-dbcp.jar file... Ok....
That gets shipped with tomcat.  What does it do with the source, at
this point, do you ask?  It throws it away!  Great.  Thats really
helpful.
The source for this jar file is not shipped with the tomcat binary
distribution, nor with the source distribution, nor is it in tomcats
source control system, because it is actually "created" by the build
script.

I can't attach the source for apache-commons-dbcp to my debugger,
because the hierarchy is different.  I can't get the source for my
version of tomcat unless I feel like going out and getting ant to
build an entire copy of tomcat locally.  Which, is less than easy
behind the proxy server I have at work, since I'm sure that your ant
build scripts will fail when it attempts to download the source and
can't reach the internet.

So, my real question, is why the heck would anyone do this?  What
possible purpose could all of this obfuscation serve?  All you have
done is make debugging and trouble shooting 10 times more difficult
than it needs to be.

If you insist on refactoring the code for dubious reasons, could you
at least put the source in your source control system and/or the
source download package?

Ok, rant over.  Now I can go back to debugging the real problem....
Most likely by ripping out the code that uses tomcats connection
pooling, and just pointing it directly at dbcp so I can actually debug
it...

Dan

---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

Dan Armbrust wrote:
> So, my real question, is why the heck would anyone do this?  What
> possible purpose could all of this obfuscation serve?  All you have
> done is make debugging and trouble shooting 10 times more difficult
> than it needs to be.
>
> If you insist on refactoring the code for dubious reasons, could you
> at least put the source in your source control system and/or the
> source download package?

Did it occur to you that no-one would go to all this trouble unless there
was a good reason for the re-factoring? Apparently not. If your tone had
been more reasonable I would have taken the time to explain the reasoning.
Since it wasn't - STFW.

As for getting the source you need there are plenty of simple options. Had
you sent a polite request to the list for help, you would have had the
source by now.

Mark

---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Dan Armbrust]

>  Did it occur to you that no-one would go to all this trouble unless there
>  was a good reason for the re-factoring? Apparently not. If your tone had
>  been more reasonable I would have taken the time to explain the reasoning.
>  Since it wasn't - STFW.

It was a sarcastic rant, because I was frustrated.  It was meant
tongue in cheek.  Don't anybody take it personal :)

I had already STFW quite a bit to try to figure out where the source
code was.  And the only reasons I could find were that some people may
have issues with version collisions of the dbcp packages.  That sounds
like user error to me - either that - or earlier versions of tomcat
had classloader bugs that were not maintaining proper separation of
classes - and this was a hack fix.  I'm sure those sorts of
classloader issues have long since been fixed.

Yet, this remains, as a very ugly hack.

I also wrote this as a rant, rather than politely, because I had very
little hope that anyone would consider fixing it at this point.
Someone else who was trying to handle gentoo package maintenance asked
this same series of questions (much more politely, I might add) late
in 2006 (http://www.mailinglistarchive.com/dev@.../msg02418.html)
- because they also ran into a lot of issues caused by this mess.
And then someone from debian chimed in, and also said this sucks, and
causes them to not include it in their packages. And after a few nicer
answers, their requests were ignored.

The only reasons he was given was that it was smaller (and we care
why?) and that it _might_ prevent a version conflict issue.

Maybe you should refactor log4j and commons logging next.  Never know
when you might have an issue there....  ;)

If there are any other legitimate reasons - such as - you needed to
fix some bugs in the code that weren't being addressed in dbcp, then
you should just put the code in your source control system.

>
>  As for getting the source you need there are plenty of simple options. Had
>  you sent a polite request to the list for help, you would have had the
>  source by now.
>

Yes, but that wouldn't have helped the fact that I had already spent a
lot of valuable time trying to trace the history of this mess.  You
have to admit, its really not very obvious.  Plus, I already had my
solution, I stopped using the tomcat implementation.  Looks like most
of the 3rd party package maintainers had the same conclusion.  They
dropped the package.

It seems that at a minimum, you should at least include the refactored
source code in the source download.  But I don't care one way or
another at this point, I now know to avoid this package in order to
make my life easier.

Dan

---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Bill Barker-2]

"Dan Armbrust" <[hidden email]> wrote in message
news:[hidden email]...

>>  Did it occur to you that no-one would go to all this trouble unless
>> there
>>  was a good reason for the re-factoring? Apparently not. If your tone had
>>  been more reasonable I would have taken the time to explain the
>> reasoning.
>>  Since it wasn't - STFW.
>
> It was a sarcastic rant, because I was frustrated.  It was meant
> tongue in cheek.  Don't anybody take it personal :)
>
> I had already STFW quite a bit to try to figure out where the source
> code was.  And the only reasons I could find were that some people may
> have issues with version collisions of the dbcp packages.  That sounds
> like user error to me - either that - or earlier versions of tomcat
> had classloader bugs that were not maintaining proper separation of
> classes - and this was a hack fix.  I'm sure those sorts of
> classloader issues have long since been fixed.
>
> Yet, this remains, as a very ugly hack.

You can use still use the commons-dbcp jars by starting Tomcat with:
    -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory

Of course, you have to supply the commons-dbcp and commons-pool jars
yourself in common/lib.

>
> I also wrote this as a rant, rather than politely, because I had very
> little hope that anyone would consider fixing it at this point.
> Someone else who was trying to handle gentoo package maintenance asked
> this same series of questions (much more politely, I might add) late
> in 2006
> (http://www.mailinglistarchive.com/dev@.../msg02418.html)
> - because they also ran into a lot of issues caused by this mess.
> And then someone from debian chimed in, and also said this sucks, and
> causes them to not include it in their packages. And after a few nicer
> answers, their requests were ignored.
>
> The only reasons he was given was that it was smaller (and we care
> why?) and that it _might_ prevent a version conflict issue.
>
> Maybe you should refactor log4j and commons logging next.  Never know
> when you might have an issue there....  ;)
>

Actually, TC6 already refactors commons-logging ;).  We don't need to
refactor log4j, since TC6 only uses JUL logging internally (but we do
replace the LogManager).  You can add commons-digester, commons-collections,
and commons-modeler to the list as well.  But at least these live in the svn
repository.

> If there are any other legitimate reasons - such as - you needed to
> fix some bugs in the code that weren't being addressed in dbcp, then
> you should just put the code in your source control system.
>
>>
>>  As for getting the source you need there are plenty of simple options.
>> Had
>>  you sent a polite request to the list for help, you would have had the
>>  source by now.
>>
>
> Yes, but that wouldn't have helped the fact that I had already spent a
> lot of valuable time trying to trace the history of this mess.  You
> have to admit, its really not very obvious.  Plus, I already had my
> solution, I stopped using the tomcat implementation.  Looks like most
> of the 3rd party package maintainers had the same conclusion.  They
> dropped the package.
>
> It seems that at a minimum, you should at least include the refactored
> source code in the source download.  But I don't care one way or
> another at this point, I now know to avoid this package in order to
> make my life easier.
>
> Dan
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: [hidden email]
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

Dan Armbrust wrote:
> The only reasons he was given was that it was smaller (and we care
> why?) and that it _might_ prevent a version conflict issue.

Size - don't care that much but as a side effect it isn't going to cause
any harm. Version conflicts, however, are a big issue. Many web apps
include the DBCP jars and deploying such an app in the servlet class loader
environment where a different version of DBCP exists is a nightmare. Whilst
you can work around one app, when you have multiple apps each with a
different DBCP version you rapidly run out of options.

> Maybe you should refactor log4j and commons logging next.  Never know
> when you might have an issue there....  ;)

Where we have issues we have / we will.

> If there are any other legitimate reasons - such as - you needed to
> fix some bugs in the code that weren't being addressed in dbcp, then
> you should just put the code in your source control system.

If this was the problem, the right way to fix it would be to go and help
out DBCP and fix the bugs in the source. This is exactly what happened just
before the latest round of releases to fix
http://issues.apache.org/bugzilla/show_bug.cgi?id=43552 which was caused by
a commons-pool bug.

>>  As for getting the source you need there are plenty of simple options. Had
>>  you sent a polite request to the list for help, you would have had the
>>  source by now.
>>
>
> Yes, but that wouldn't have helped the fact that I had already spent a
> lot of valuable time trying to trace the history of this mess.  You
> have to admit, its really not very obvious.

It isn't as obvious as the source just being there but as you discovered it
has been discussed on the lists and the build script is pretty clear.

>  Plus, I already had my
> solution, I stopped using the tomcat implementation.  Looks like most
> of the 3rd party package maintainers had the same conclusion.  They
> dropped the package.

My recollection is that they didn't drop it but got it from the binary
package rather than reproduce the build process.

> It seems that at a minimum, you should at least include the refactored
> source code in the source download.  But I don't care one way or
> another at this point, I now know to avoid this package in order to
> make my life easier.

If you care about this you can always open a bugzilla entry for an
enhancement and propose a patch.

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Dan Armbrust]

>  > If there are any other legitimate reasons - such as - you needed to
>  > fix some bugs in the code that weren't being addressed in dbcp, then
>  > you should just put the code in your source control system.
>
>  If this was the problem, the right way to fix it would be to go and help
>  out DBCP and fix the bugs in the source. This is exactly what happened just
>  before the latest round of releases to fix
>  http://issues.apache.org/bugzilla/show_bug.cgi?id=43552 which was caused by
>  a commons-pool bug.

I realize that, and I'm glad to see that the projects responsive, and
work well with each other.  But we all know that sometimes that
doesn't happen - good project maintainers come and go.  Smaller
projects don't do well when the good maintainers move on to other
work, and you are left with no choice but to fork their code if you
want to fix an issue in a timely fashion.

>  > It seems that at a minimum, you should at least include the refactored
>  > source code in the source download.
>
>  If you care about this you can always open a bugzilla entry for an
>  enhancement and propose a patch.

I probably will sometime in the near future, when I get caught up again :)

Thanks for your patience,

I know my initial post was rather a flame bait.

Dan

---------------------------------------------------------------------
To start a new topic, e-mail: [hidden email]
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]