Re: renaming jar files
Costin Manolache wrote: I understand people using JDBC authenticator would miss the connection pooling - but maybe they could download it separately ? Would't be easier to just download the 'official' version ? No. commons-dbcp supports far more than just pooling for the JDBC authenticator. The reason we do the renaming is to avoid class loading issues when users want to use a Tomcat-managed connection pool alongside an application that uses commons-dbcp and/or commons-pool directly. I'm also curious, assuming JDK1.5 is used to compile - would the tomcat distro work in JDK1.6 if dbcp is compiled with 1.5 ? Yes it does. To be more accurate, I haven't seen any issues using the re-packaged DBCP on 1.6. In any case - it kind of sucks to not be able to build following the instructions ( ant download, ant ) - I didn't find any ref that JDK1.6 is not supported for build. Correct. If you want to fix this you could always port the DBCP build fixes from commons. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
On Sun, Mar 23, 2008 at 6:29 AM, Mark Thomas [EMAIL PROTECTED] wrote: Costin Manolache wrote: I understand people using JDBC authenticator would miss the connection pooling - but maybe they could download it separately ? Would't be easier to just download the 'official' version ? No. commons-dbcp supports far more than just pooling for the JDBC authenticator. The reason we do the renaming is to avoid class loading issues when users want to use a Tomcat-managed connection pool alongside an application that uses commons-dbcp and/or commons-pool directly. I'm also curious, assuming JDK1.5 is used to compile - would the tomcat distro work in JDK1.6 if dbcp is compiled with 1.5 ? Yes it does. To be more accurate, I haven't seen any issues using the re-packaged DBCP on 1.6. In any case - it kind of sucks to not be able to build following the instructions ( ant download, ant ) - I didn't find any ref that JDK1.6 is not supported for build. Correct. If you want to fix this you could always port the DBCP build fixes from commons. This isssue is being tracked as DBCP-191. Comments, suggestions, patches are welcome on the ticket or on commons-dev. Opinions on JDK support levels/branching from tomcat perspective would be appreciated. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, Mar 23, 2008 at 6:29 AM, Mark Thomas [EMAIL PROTECTED] wrote: Costin Manolache wrote: I understand people using JDBC authenticator would miss the connection pooling - but maybe they could download it separately ? Would't be easier to just download the 'official' version ? No. commons-dbcp supports far more than just pooling for the JDBC authenticator. The reason we do the renaming is to avoid class loading issues when users want to use a Tomcat-managed connection pool alongside an application that uses commons-dbcp and/or commons-pool directly. I'm also curious, assuming JDK1.5 is used to compile - would the tomcat distro work in JDK1.6 if dbcp is compiled with 1.5 ? Yes it does. To be more accurate, I haven't seen any issues using the re-packaged DBCP on 1.6. Well, of course, if you try and use any of the new JDBC-4 methods on Objects returned by dbcp, then expect your app to explode :). But if you just use JDBC-3 methods or below, then it should work fine. In any case - it kind of sucks to not be able to build following the instructions ( ant download, ant ) - I didn't find any ref that JDK1.6 is not supported for build. Correct. If you want to fix this you could always port the DBCP build fixes from commons. This isssue is being tracked as DBCP-191. Comments, suggestions, patches are welcome on the ticket or on commons-dev. Opinions on JDK support levels/branching from tomcat perspective would be appreciated. *If* dbcp had been built around a Factory model (e.g. BasicDataSource was a package level class instead of being public), then BasicDataSource could be made abstract with a BasicDataSource3 class (that doesn't implement anything other than constructors) and a BasicDataSource4 class that implements JDBC-4. Then the BasicDataSourceFactory could determine at runtime which implementation to send back, with exclude statements on BasicDataSource4 if compiled on a Java-5 or lower system. This is generally the model used in Tomcat for JDK changes (the best example is the JSSE support in Tomcat 5.5.x and below, but used other places as well). But Tomcat has the advantage that almost nobody references its internal classes directly :). Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
that's because DBCP implements interfaces, and only implements the
java.sql/javax.sql up to JDK 1.5.
any usage in the code - and just removing it doesn't seem to hurt in
any way.
it's being used, removing it would prolly upset some users, as the DBCP
is the core for the tomcat connection pooling.
I did a grep - couldn't find any direct dep in the code, and removing
it from the 'download' and the copy in 'deploy' just worked. There is
only one ref in Constants, which is loaded with Class.forName() by the
naming code.
The dbcp build file actually handles jdk1.5/1.6 changes by doing some 'replace'.
Our build.download just download theirs, replaces the package name and
adds some more stuff.
I understand people using JDBC authenticator would miss the connection
pooling - but maybe they could download it separately ? Would't be
easier to just download the 'official' version ?
I'm also curious, assuming JDK1.5 is used to compile - would the
tomcat distro work in JDK1.6 if dbcp is compiled with 1.5 ?
In any case - it kind of sucks to not be able to build following the
instructions ( ant download, ant ) - I didn't find any ref that JDK1.6
is not supported for build.
Costin
Am I missing something - the jar name is referenced if few
places, and there is a class name in Constants. I assume some JDBC
connector stuff would not work so well unless someone install the
package.
Costin
On 3/20/08, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
when the commons-logging jar files got updated, they also got renamed,
we missed a few spots,
some files in bin and conf still reference the old name, like
catalina.policy
// These permissions apply to the commons-logging API
grant codeBase file:${catalina.home}/bin/commons-logging-api.jar {
permission java.security.AllPermission;
};
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
Costin Manolache wrote:
What's the current status of commons-logging versus juli/logging ? Do
we still need the dep ?
in 5.5 we still support commoons logging, in 6.0, no more unless you
build the adapter from the extras package
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
that's because DBCP implements interfaces, and only implements the
java.sql/javax.sql up to JDK 1.5.
any usage in the code - and just removing it doesn't seem to hurt in
any way.
it's being used, removing it would prolly upset some users, as the DBCP
is the core for the tomcat connection pooling.
Am I missing something - the jar name is referenced if few
places, and there is a class name in Constants. I assume some JDBC
connector stuff would not work so well unless someone install the
package.
Costin
On 3/20/08, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
when the commons-logging jar files got updated, they also got renamed,
we missed a few spots,
some files in bin and conf still reference the old name, like
catalina.policy
// These permissions apply to the commons-logging API
grant codeBase file:${catalina.home}/bin/commons-logging-api.jar {
permission java.security.AllPermission;
};
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
What's the current status of commons-logging versus juli/logging ? Do
we still need the dep ?
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
any usage in the code - and just removing it doesn't seem to hurt in
any way. Am I missing something - the jar name is referenced if few
places, and there is a class name in Constants. I assume some JDBC
connector stuff would not work so well unless someone install the
package.
Costin
On 3/20/08, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
when the commons-logging jar files got updated, they also got renamed,
we missed a few spots,
some files in bin and conf still reference the old name, like
catalina.policy
// These permissions apply to the commons-logging API
grant codeBase file:${catalina.home}/bin/commons-logging-api.jar {
permission java.security.AllPermission;
};
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
