"Dan Armbrust" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> 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/[EMAIL PROTECTED]/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: [email protected]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
