[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 20 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-upload : Services Framework - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jakarta-slide : Content Management System based on WebDAV technology - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-2 : A servlet based framework. - myfaces : JavaServer(tm) Faces implementation - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-jetspeed-1 : Enterprise Information Portal - portals-pluto-portal-1.0 : JSR168 Container - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-06122006.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-06122006 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-06122006.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 24 source files to /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol [javac] symbol : class ServletContextListener [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextListener; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol [javac] symbol : class ServletContextEvent [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextEvent; [javac] ^ [javac]
[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 20 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-upload : Services Framework - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jakarta-slide : Content Management System based on WebDAV technology - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-2 : A servlet based framework. - myfaces : JavaServer(tm) Faces implementation - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-jetspeed-1 : Enterprise Information Portal - portals-pluto-portal-1.0 : JSR168 Container - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-06122006.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-06122006 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-06122006.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 24 source files to /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol [javac] symbol : class ServletContextListener [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextListener; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol [javac] symbol : class ServletContextEvent [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextEvent; [javac] ^ [javac]
Re: [dbutils] SystemDataSource
Both of these suggestions are connection pooling datasources; or do they
also provide a simple datasource? Jakarta Commons already has DBCP which
offers a couple connection pooling datasources, no need to go looking to
sourceforge.
John McNally
David Graham wrote:
Why not just use a real DataSource from C3P0 or Proxool? They're fully
featured and easy to setup. Also, we should not use properties named
jdbc.* as they are potentially used by drivers.
http://sourceforge.net/projects/c3p0
http://proxool.sourceforge.net/
David
--- Henri Yandell [EMAIL PROTECTED] wrote:
Just had need to hack together a simple DataSource class and wondered
if it would fit nicely in dbutils. Name is either SystemDataSource
(after SystemClassLoader) or DriverManagerDataSource, it uses Java -D
properties and the DriverManager, so is very lightweight and something
nice to start with before moving up to a container that supplies a
real DataSource.
I imagine there are MockDataSources out there that are similar too for
unit testing, but nothing in DbUtils yet.
(code follows, it's pretty dumb)
public class SystemDataSource implements DataSource {
private String driver = System.getProperty(jdbc.driver);
private String username = System.getProperty(jdbc.user);
private String password = System.getProperty(jdbc.password);
private String uri = System.getProperty(jdbc.uri);
public SystemDataSource() {
DbUtils.loadDriver(driver);
}
public Connection getConnection() throws SQLException {
return DriverManager.getConnection(this.uri, this.username,
this.password);
}
public Connection getConnection(String username, String password)
throws SQLException {
return DriverManager.getConnection(this.uri, username,
password);
}
public PrintWriter getLogWriter() throws SQLException {
return DriverManager.getLogWriter();
}
public void setLogWriter(PrintWriter logWriter) throws SQLException
{
DriverManager.setLogWriter(logWriter);
}
public void setLoginTimeout(int timeout) throws SQLException {
DriverManager.setLoginTimeout(timeout);
}
public int getLoginTimeout() throws SQLException {
return DriverManager.getLoginTimeout();
}
}
Get Firefox!
http://www.mozilla.org/firefox/
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
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]
[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-07062005.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Circular Dependency with ant. -ERROR- Circular Dependency with xml-xerces. -ERROR- Circular Dependency with xml-apis. -ERROR- Circular Dependency with commons-beanutils. -ERROR- Circular Dependency with jakarta-servletapi. -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005 Gump E-mail Identifier (unique within run) #82. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-07062005.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Circular Dependency with ant. -ERROR- Circular Dependency with xml-xerces. -ERROR- Circular Dependency with xml-apis. -ERROR- Circular Dependency with commons-beanutils. -ERROR- Circular Dependency with jakarta-servletapi. -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005 Gump E-mail Identifier (unique within run) #82. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta/commons-sandbox-sql is moved to db/ddlutils
As voted on previously the code within commons-sandbox-sql is now being developed under oversite of the DB pmc and the code was copied to the /db/ddlutils svn repository. I left the old files in place as I did not want to break any dependencies, but if you want me to I can remove the sql directory. I modifed the README.txt file to indicate that development is no longer being done within Jakarta, but let me know if I should do more. John McNally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-06122004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-06122004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-pluto/container/target/pluto-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/portal/target/pluto-portal-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-06122004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 17 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-06122004.jar BUILD SUCCESSFUL Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 16001506122004, brutus:brutus-public:16001506122004 Gump E-mail Identifier (unique within run) #242. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@stormcrow]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-08112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: jakarta-servletapi unknown to *this* workspace -ERROR- Bad Dependency. Project: jakarta-pluto unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 53261508112004, stormcrow:brutus-public:53261508112004 Gump E-mail Identifier (unique within run) #10. -- Apache Gump http://gump.apache.org/ [Instance: stormcrow] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload has an issue affecting its community integration. This issue affects 95 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-fw : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-woody : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-fileupload : Commons File Upload Package - commons-jelly-tags-ojb : A variety of tags for working with the ObjectBridge persiste... - commons-jelly-tags-quartz : This is a Jelly interface for the Quartz Scheduler. - db-ojb : ObjectRelationalBridge - db-torque : Persistence Layer - forrest : Apache Forrest is an XML standards-oriented documentation fr... - fulcrum-upload : Services Framework - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jakarta-slide : Content Management System based on WebDAV technology - jakarta-struts : Model 2 Model-View-Controller framework for Servlets and JSP - jakarta-tapestry : Component-based web application framework organized around i... - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-coyote_10 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-3 : A servlet based framework. - jakarta-turbine-jcs : Cache - jakarta-turbine-stratum-full :
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-31102004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-31102004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-pluto/container/target/pluto-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/portal/target/pluto-portal-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-31102004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 17 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-31102004.jar BUILD SUCCESSFUL Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 18000931102004, brutus:brutus-public:18000931102004 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-31102004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-31102004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-pluto/container/target/pluto-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-pluto/portal/target/pluto-portal-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-31102004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 17 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /home/gump/workspaces2/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-31102004.jar BUILD SUCCESSFUL Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 17001531102004, brutus:brutus-public:17001531102004 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-16102004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-16102004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-16102004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 10 source files to /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-16102004.jar BUILD SUCCESSFUL Total time: 1 second - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 11001516102004, brutus:brutus-public:11001516102004 Gump E-mail Identifier (unique within run) #197. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success', with reason ''. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-11102004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-11102004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-11102004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 10 source files to /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-11102004.jar BUILD SUCCESSFUL Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 07010011102004, brutus:brutus-public:07010011102004 Gump E-mail Identifier (unique within run) #11. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-fileupload (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. The current state of this project is 'Success', with reason ''. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-11102004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-11102004 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-11102004.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 10 source files to /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes [jar] Building jar: /usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-11102004.jar BUILD SUCCESSFUL Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 13000611102004, brutus:brutus-public:13000611102004 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-commons/commons-fileupload success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. Project State : 'Success' Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-fileupload-20040725.jar] identifier set to project name -INFO- Enable verbose output, due to 1 previous error(s). -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) State: Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-20040725 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar- [javac] '-d' [javac] '/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes' [javac] '-classpath' [javac] '/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar' [javac] '-sourcepath' [javac] '/usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java' [javac] '-g:none' [javac] [javac] The ' characters around the executable and arguments are [javac] not part of the command. [javac] Files to be compiled: [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DefaultFileItem.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DefaultFileItemFactory.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DeferredFileOutputStream.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DiskFileUpload.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileItem.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileItemFactory.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUpload.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUploadBase.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUploadException.java [javac] /usr/local/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/MultipartStream.java [javac]
[GUMP@brutus]: jakarta-commons/commons-fileupload prerequisite failed
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-fileupload *no longer* has an issue. Project State : 'Prerequisite Failed', Reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jakarta-commons/commons-fileupload/index.html That said, some snippets follow: The following annotations were provided: -INFO- Sole jar [commons-fileupload-20040524.jar] identifier set to project name -INFO- Prerequisite failed with reason build failed To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org:8080/gump/jakarta-commons/commons-fileupload/rss.xml Atom: http://brutus.apache.org:8080/gump/jakarta-commons/commons-fileupload/atom.xml -- Produced by Gump 2.0.3-alpha-0002. [Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)] http://brutus.apache.org:8080/gump/index.html http://brutus.apache.org:8080/gump/options.html -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Relicensing to the Apache License 2.0 ?
The license appendix does not say to add All rights reserved. What was the reason for retaining that? john mcnally On Tue, 2004-02-03 at 07:35, Mark R. Diggory wrote: Simple expansion, double replace retains old dates, doesn't do date merging though, suppost you could use the regexpreplace task to accomplish that. Mark R. Diggory wrote: I replaced our licenses with a simple ant replace task. You may have to tweek the matching string a little. -MArk Gary Gregory wrote: Should we replace each source file header lock, stock and two smoking barrels? If so, does any one have a script for this? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 12:02 To: Jakarta Commons Developers List Subject: Re: Relicensing to the Apache License 2.0 ? The policy as far as I know is: All releases after March 1st must use Apache License 2.0. No agreement is needed as the only copyright holders to the ASF version of the source is the ASF. While people retain copyright to their submissions, they retain the copyright to their copy and not to the ASF copy. It might be different for say ASF-members who have not signed the CLA, but I would expect committers who have not signed the CLA to be the same as a contributor. IANAL etc. Just passing on what I've seen said, which could be wrong for all I know. Hen On Mon, 2 Feb 2004, Emmanuel Bourg wrote: Hi, the Apache License 2.0 has been released last month (http://www.apache.org/licenses/LICENSE-2.0) and it seems it will become mandatory for all Apache projects this year. I wonder what is the procedure for this migration, i guess all copyright holders, that's committers and external contributors, have to agree explicitely on the relicensing. This should be immediate for the committers since they signed the Contributor License Agreement allowing the ASF to license the code in any way. But the other contributors will have to be contacted to request permission for relicensing, correct? Emmanuel Bourg - 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] ?xml version=1.0 encoding=UTF-8? project default=replace_license name=license-2.0 basedir=. target name=replace_license replace dir=src include name=**/*.java/ replacetoken![CDATA[/* * The Apache Software License, Version 1.1 * * Copyright (c) 2003-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their name without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION
Re: [VOTE][Pool] Release Commons-Pool v1.1
On Mon, 2003-10-20 at 11:27, Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons Pool. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-Pool 1.1 - [X] +1 I support this release and will help john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
On Mon, 2003-10-20 at 11:27, Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons DBCP. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-DBCP 1.1 - [X] +1 I support this release and will help john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/dbcp build.xml
Was there discussion on removing support for building with pre-jdk1.4?
Why do this now? I see a benefit in building the source from its cvs
location without pre-processing, but could we postpone the change till
after the release?
john mcnally
On Sat, 2003-10-04 at 11:12, [EMAIL PROTECTED] wrote:
dirkv 2003/10/04 11:12:10
Modified:dbcp build.xml
Log:
update ant build
Revision ChangesPath
1.21 +86 -229 jakarta-commons/dbcp/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/dbcp/build.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- build.xml 7 Mar 2003 00:24:08 - 1.20
+++ build.xml 4 Oct 2003 18:12:10 - 1.21
@@ -1,27 +1,5 @@
!-- $Id$ --
-project name=jakarta-commons-dbcp default=test basedir=.
-
- !-- patternset describing files to be copied from the doc directory --
- patternset id=patternset-doc/
-
- !-- patternset describing test classes --
- patternset id=patternset-test-classes
- include name=**/Test*.class/
- /patternset
-
- !-- patternset describing non test classes --
- patternset id=patternset-non-test-classes
- include name=**/*.class/
- exclude name=**/Test*.class/
- /patternset
-
- !-- patternset describing non test source files (*.java, *html, etc.) --
- patternset id=patternset-javadocable-sources
- include name=**/*/
- exclude name=**/Test*.java/
- /patternset
-
- !-- # --
+project name=commons-dbcp default=test basedir=.
target name=init
tstamp/
@@ -38,6 +16,9 @@
property name=user-propfile value=${user.home}/build.properties/
property file=${user-propfile}/
+ property name=commons-collections.jar
value=${basedir}/../collections/dist/commons-collections.jar/
+ property name=commons-pool.jar
value=${basedir}/../pool/dist/commons-pool.jar/
+
!-- command line classpath, if any --
property name=cp value=/
@@ -45,131 +26,52 @@
property name=classpath
value=${cp}:${commons-pool.jar}:${commons-collections.jar}:${jdbc20ext.jar}:${junit.jar}:${jndi.jar}:${sax2.jar}/
property name=name value=commons-dbcp/
- property name=Name value=Commons-DBCP/
- property name=Name-Long value=Jakarta Commons Database Connection
Pool/
-
- !-- The current version number of this component --
- property name=component.package value=org.apache.commons.dbcp/
- property name=component.version value=1.1-dev/
- filter token=package value=${component.package}/
- filter token=version value=${component.version}/
+ property name=title value=Jakarta Commons Database Pooling Package/
+ property name=version value=Nightly-${DSTAMP}${TSTAMP}/
+ property name=package value=org.apache.commons.dbcp.*/
+
+ property name=src.dir value=${basedir}/src/
+ property name=src.java.dir value=${src.dir}/java/
+ property name=src.test.dir value=${src.dir}/test/
+ property name=build.dir value=${basedir}/build/
+ property name=build.classes.dir value=${build.dir}/classes/
+ property name=build.test-classes.dir value=${build.dir}/test-classes/
+ property name=dist.dir value=${basedir}/dist/
+ property name=dist.jar value=${dist.dir}/${name}.jar/
property name=test.entry value=org.apache.commons.dbcp.TestAll/
- property name=test.failonerror value=true /
- property name=test.runner value=junit.textui.TestRunner /
-
- property name=workdir
value=${java.io.tmpdir}/buildtemp_${DSTAMP}${TSTAMP}/
- property name=source value=${basedir}/
- property name=source.src value=${basedir}/src/
- property name=source.src.conf value=${source.src}/conf/
- property name=source.src.java value=${source.src}/java/
- property name=source.src.test value=${source.src}/test/
- property name=source.doc value=${basedir}/doc/
- property name=dest value=${basedir}/dist/
- property name=dest.src value=${dest}/src/
- property name=dest.classes value=${dest}/classes/
- property name=dest.confvalue=${dest}/conf/
- property name=dest.doc value=${dest}/docs/
- property name=dest.doc.api value=${dest.doc}/api/
- property name=dest.jardir value=${dest}/
- property name=dest.jardir.jar value=${dest.jardir}/${name}.jar/
- available property=available-doc file=${source.doc}/ !-- does this
module have docs? --
- available property=available-src-conf file=${source.src.conf
Re: [DBCP] fixing issue 23491 Can't configure PerUserPoolDataSource for use with tomcat
The way I wrote InstanceKeyObjectFactory it expected that an instance of
PerUserPoolDataSource would be created and bound to a jndi context. In
such a case, the Reference as returned by getReference() method of
InstanceKeyDataSource would be used and things should work properly.
It appears in the case of tomcat and using server.xml to specify the
datasource properties, tomcat does not bind a Reference created from the
Referenceable object to the jndi name. Rather it creates a reference
based on the parameters given in server.xml and that is passed to the
ObjectFactory.
Something along the lines of what you show below will be needed, though
that would limit the app to one connection pool. I was thinking of
creating a map, possibly keyed on description. Though description is
not required, I'm not sure what else to use.
I will work on this more tonight,
john mcnally
On Wed, 2003-10-08 at 13:43, Dirk Verbeeck wrote:
Any thoughts on how to fix this issue?
or how the current code should work?
I got it to work by adding the following to
InstanceKeyObjectFactory.getObjectInstance
if (obj == null) {
PerUserPoolDataSource ds = new
PerUserPoolDataSource();
ds.setDataSourceName((String)ra.getContent());
obj = ds;
}
and the following server.xml
Resource name=jdbc/bookstoreCPDS auth=Container
type=org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS/
ResourceParams name=jdbc/bookstoreCPDS
parameter
namefactory/name
valueorg.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS/value
/parameter
parameternameuser/namevaluesa/value/parameter
parameternamepassword/namevalue/value/parameter
parameter
namedriver/name
valueorg.hsqldb.jdbcDriver/value/parameter
parameter
nameurl/name
valuejdbc:hsqldb:database/value
/parameter
/ResourceParams
Resource name=jdbc/PerUserBookstore auth=SERVLET
type=org.apache.commons.dbcp.datasources.PerUserPoolDataSource/
ResourceParams name=jdbc/PerUserBookstore
parameter
namefactory/name
valueorg.apache.commons.dbcp.datasources.InstanceKeyObjectFactory/value
/parameter
parameter
nameinstanceKey/name
valuejava:/comp/env/jdbc/bookstoreCPDS/value
/parameter
/ResourceParams
I did a quick test and found no problems this way.
Without the extra code I can't get it to work but maybe there is another
way to automagically create the PerUserPoolDataSource.
Dirk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] 1.3 vs. 1.4 jdk
Dbcp can compile under both jdk's, so you can see an example of using ant filtering to comment out jdbc3.0 methods. The problem with two jars is that it makes usage in another product more difficult. I think tomcat would prefer to include only one jar. I believe our intention is to distribute a jar compiled with jdk1.4 as it is most compatible. I think this could vary with different jvm's, though that appears to be the case for Sun's. I was concerned because it seems usage of the cvs head mysql jdbc driver compiled with 1.4 jdk does result in ClassNotFoundErrors if used in a 1.3 jvm, I think we have avoided this problem in dbcp, it is just something I wanted to remind others and as something that should be tested before we ship final. john mcnally On Tue, 2003-09-30 at 21:18, Henri Yandell wrote: Compile two jars? In [dbutils] I need to learn how to do conditional compilation as it absolutely has to have two jars due to extension of ResultSet, but it's not such a need in dbcp. Still, maybe the answer is the obvious one. Hen On 30 Sep 2003, John McNally wrote: Code compiled with a 1.3 jdk is not compatible with java 1.4 jdbc api. I did not check, but assume any jars for release will be compiled with a 1.4 jdk? I think the hope is that a jar compiled with 1.4 will be usable in a 1.3 environment, so that we only distribute one. I'm not sure if that compatibility has been verified. I'm not sure but maybe I have used a 1.3 compiled dbcp in a 1.4 jvm, though that does not seem like it would work. Basically, I'm saying I don't know the answer, but have we verified the best jdk for compatibility? john mcnally On Tue, 2003-09-30 at 13:08, Dirk Verbeeck wrote: Release Candidates can be downloaded here: http://cvs.apache.org/~dirkv/builds/ Preview of the updated websites here: http://cvs.apache.org/~dirkv/dbcp/ http://cvs.apache.org/~dirkv/pool/ The release schedule forsees a 2 week review period. http://cvs.apache.org/viewcvs/jakarta-commons/pool/RELEASE_PLAN_1_1.txt?rev=1.2content-type=text/vnd.viewcvs-markup * Preparation Period:28 September 2003 - 30 September 2003 * Review Period: 1 October 2003 - 15 October 2003 * Implementation Period: 16 October 2003 - 19 October 2003 * Release Pool 1.1: 20 October 2003 Please report any issue to the commons-dev mailing list as soon as possible. Positive reports are also very welcome :-) (specify tested database, OS, JVM, hardware, container/framework) Cheers Dirk - 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]
1.3 vs. 1.4 jdk [was Re: [ANN][DBCP][Pool] First Release Candidates available for the 1.1 releases of Commons DBCP Pool]
Code compiled with a 1.3 jdk is not compatible with java 1.4 jdbc api. I did not check, but assume any jars for release will be compiled with a 1.4 jdk? I think the hope is that a jar compiled with 1.4 will be usable in a 1.3 environment, so that we only distribute one. I'm not sure if that compatibility has been verified. I'm not sure but maybe I have used a 1.3 compiled dbcp in a 1.4 jvm, though that does not seem like it would work. Basically, I'm saying I don't know the answer, but have we verified the best jdk for compatibility? john mcnally On Tue, 2003-09-30 at 13:08, Dirk Verbeeck wrote: Release Candidates can be downloaded here: http://cvs.apache.org/~dirkv/builds/ Preview of the updated websites here: http://cvs.apache.org/~dirkv/dbcp/ http://cvs.apache.org/~dirkv/pool/ The release schedule forsees a 2 week review period. http://cvs.apache.org/viewcvs/jakarta-commons/pool/RELEASE_PLAN_1_1.txt?rev=1.2content-type=text/vnd.viewcvs-markup * Preparation Period:28 September 2003 - 30 September 2003 * Review Period: 1 October 2003 - 15 October 2003 * Implementation Period: 16 October 2003 - 19 October 2003 * Release Pool 1.1: 20 October 2003 Please report any issue to the commons-dev mailing list as soon as possible. Positive reports are also very welcome :-) (specify tested database, OS, JVM, hardware, container/framework) Cheers Dirk - 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: dbcp bug
On Tue, 2003-08-19 at 01:24, KNOX, Liam, FM wrote: Noel I took the latest snap shot and this seems to work fine. Is there a plan for a new release in the near future? I am also interested in how dbcp deals with closed or 'stale' connections i.e. in the event of a db outage. Is it possible that stale connections could remain in the pool ? It is possible to configure a pool to verify the connection before handing it out (or at other times, if less critical). Connections that don't pass the verification test (usually a simple sql query) are removed from the pool. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pool] faulty change of synchronization? - Re: cvs commit:jakarta-commons/pool/src/java/org/apache/commons/pool/implGenericObjectPool.java
My quick read of this change is not favorable. It looks like changes to
an unsynchronized list have been moved outside any synchronization.
Also integer math like numActive++ outside a synchronization block has
got me into problems in the past. A test with two threads using i++ and
i-- ran quite some time (couple hours) on a single processor box, but
did eventually fail. Then the test was run on a dual processor box, it
failed pretty much immediately, repeatedly.
I'm -1 on this change.
john mcnally
On Wed, 2003-08-13 at 05:42, [EMAIL PROTECTED] wrote:
dirkv 2003/08/13 05:42:28
Modified:pool/src/java/org/apache/commons/pool/impl
GenericObjectPool.java
Log:
Bugzilla Bug 19614: [DBCP] Poor performance under load
Bugzilla Bug 9: [DBCP] Foul connection causes livelock of all pool operations
- remove synchronization on borrowObject
Revision ChangesPath
1.22 +76 -27
jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java
Index: GenericObjectPool.java
===
RCS file:
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- GenericObjectPool.java 12 Aug 2003 22:46:09 - 1.21
+++ GenericObjectPool.java 13 Aug 2003 12:42:28 - 1.22
@@ -163,6 +163,7 @@
*
* @see GenericKeyedObjectPool
* @author Rodney Waldhoff
+ * @author Dirk Verbeeck
* @version $Revision$ $Date$
*/
public class GenericObjectPool extends BaseObjectPool implements ObjectPool {
@@ -705,65 +706,113 @@
//-- ObjectPool methods --
-public synchronized Object borrowObject() throws Exception {
+public Object borrowObject() throws Exception {
+// Warning: because the method synchonization is gone
+// _numActive should be incremented as soon as possible
+// otherwise the pool can go over the limit
+// decrement on error (do not forget to notifyAll)
+
assertOpen();
long starttime = System.currentTimeMillis();
boolean newlyCreated = false;
for(;;) {
ObjectTimestampPair pair = null;
// if there are any sleeping, just grab one of those
-try {
-pair = (ObjectTimestampPair)(_pool.removeFirst());
-} catch(NoSuchElementException e) {
-; /* ignored */
+if (!_pool.isEmpty()) { // no need to synchronize when pool is empty
+synchronized(this) {
+try {
+_numActive++;
+pair = (ObjectTimestampPair)(_pool.removeFirst());
+} catch(NoSuchElementException e) {
+; /* ignored */
+}
+if(null == pair) { // someone took the last one before us
+_numActive--;
+notifyAll();
+}
+}
}
// otherwise
if(null == pair) {
// check if we can create one
// (note we know that the num sleeping is 0, else we wouldn't be
here)
if(_maxActive = 0 || _numActive _maxActive) {
-Object obj = _factory.makeObject();
-pair = new ObjectTimestampPair(obj);
-newlyCreated = true;
+try {
+_numActive++;
+Object obj = _factory.makeObject();
+pair = new ObjectTimestampPair(obj);
+newlyCreated = true;
+}
+finally {
+if(null == pair) {
+synchronized(this) {
+_numActive--;
+notifyAll();
+}
+}
+}
} else {
// the pool is exhausted
switch(_whenExhaustedAction) {
case WHEN_EXHAUSTED_GROW:
-Object obj = _factory.makeObject();
-pair = new ObjectTimestampPair(obj);
+try {
+_numActive++;
+Object obj = _factory.makeObject();
+pair = new ObjectTimestampPair(obj);
+newlyCreated = true
Re: [pool] faulty change of synchronization? - Re: cvs commit:jakarta-commons/pool/src/java/org/apache/commons/pool/implGenericObjectPool.java
public class TestAtomicIncrement
{
int j;
public TestAtomicIncrement()
{
j = 10;
}
public static void main(String[] args)
throws Exception
{
TestAtomicIncrement tai = new TestAtomicIncrement();
tai.j++;
int i = 10;
i++;
}
}
[EMAIL PROTECTED] small-tests]$ javac TestAtomicIncrement.java
[EMAIL PROTECTED] small-tests]$ javap -c TestAtomicIncrement
Compiled from TestAtomicIncrement.java
public class TestAtomicIncrement extends java.lang.Object {
int j;
public TestAtomicIncrement();
public static void main(java.lang.String[]) throws
java.lang.Exception;
}
Method TestAtomicIncrement()
0 aload_0
1 invokespecial #1 Method java.lang.Object()
4 aload_0
5 bipush 10
7 putfield #2 Field int j
10 return
Method void main(java.lang.String[])
0 new #3 Class TestAtomicIncrement
3 dup
4 invokespecial #4 Method TestAtomicIncrement()
7 astore_1
8 aload_1
9 dup
10 getfield #2 Field int j
13 iconst_1
14 iadd
15 putfield #2 Field int j
18 bipush 10
20 istore_2
21 iinc 2 1
24 return
I think the getfield bytecode is supposed to implemented in such a way
that it is atomic for an int field. It is possible the putfield
bytecode is as well, i don't know the jls that well. But it is doubtful
that the method#'s 10-15 comprise an atomic operation.
john mcnally
On Wed, 2003-08-13 at 12:32, David Graham wrote:
--- Dirk Verbeeck [EMAIL PROTECTED] wrote:
The pool manipulation was synchronized, only the isEmpty() test is not.
I didn't realize that _numActive++ should be synchronized, I thought the
++ operator was atomic.
The datatype the operator is applied to is what matters. Assignments to
ints are atomic, assignments to longs aren't because they are 64 bits.
So, if _numActive is an int, I don't think it needs to be synchronized.
David
I'll put these also in a synchronized block.
http://cvs.apache.org/viewcvs/jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java?rev=1.23content-type=text/vnd.viewcvs-markup
How does this new version looks?
Dirk
John McNally wrote:
My quick read of this change is not favorable. It looks like changes
to
an unsynchronized list have been moved outside any synchronization.
Also integer math like numActive++ outside a synchronization block has
got me into problems in the past. A test with two threads using i++
and
i-- ran quite some time (couple hours) on a single processor box, but
did eventually fail. Then the test was run on a dual processor box, it
failed pretty much immediately, repeatedly.
I'm -1 on this change.
john mcnally
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
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: [DBCP] AbandonedTrace - Connection Recovery
The current implementation recover's the abandoned connection based on an inactivity timeout. So it has to track the last time the connection was used. This more tightly couples it to DBCP. That sounds like a better implementation as it is unlikely to timeout long running transactions. But implementing an Observer pattern in the Connection, Statement, ResultSet implementations would still allow such an implementation, right? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I get the impression that some of you believe connection cleanup is difficult. It really is trivial to properly dispose of connections in a finally block. It is not always trivial. Yes, you can have some high level try/finally block to clean up resources, but you must make sure the code in the finally block has access to a Connection reference. Obviously, in the simple case where the Connection can be borrowed and returned in the same method, it is trivial. Not every case is that easy. It's even easier to find problems if you've properly layered the app so the database calls are all in one place. How do you do that when your application makes use of other components written by other teams/companies that have different policies. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Using a weak reference for pooled connections which are in use is a good idea and I am all for it. The only problem is that there is no guarantee when the weak referenced db connection pool object will be GC'd. That is highly dependent upon how the JVM implements GC. There is no guarantee that this would prevent abandoned connections from causing the pool to be exhausted. I had a case like this just a week ago, where an object that should have been closed when its use was done, because it was maintaining internally an open Connection. The bug never presented itself in our dev environments because the memory was low enough that gc was closing the object. Thankfully the test environments are more similar to production and the increased memory on those boxes caught the oversight. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Do not use broken code for production, but it must be possible to solve without broken pool. What utopia do you live in? I think it would be a close approximation to say that every piece of software in production use in the world today has bugs. And it is not a broken pool that allows the admin to set an idle timeout for connections anymore than it is a broken db that allows the same thing. You can keep calling it broken or crap, but your opinion does not matter much to me, have you contributed any code to dbcp, do you use it? I certainly hope not in production because its broken according to you. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:15, Juozas Baliuka wrote: http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC onnection.html +1 to implement this interface, but I do not think it can help for broken applications. That is an interface to be implemented by a jdbc driver vendor there is no reason for dbcp to implement it. dbcp.cpdsadapter provides a simple wrapper implementation for old jdbc 1.0 driver implementation. But it is not something a connection pool would normally need to code, it represents a physical connection to the db. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote: I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Try to implement yourself and I am sure the time to fix a problem will mean forever and crappers will blame you then server or app will crache. Do you want to blame apache for this code ? This problem redirection will not help, but if you want, you can maintain this crap yourself, but do not try to redirect this problem to apache please. This attitude is not very helpful. I don't see how dbcp supplying the ability to configure a connection pool to reclaim connections is that big of an issue. It adds code complexity, but if the implementation is modified so that it is not central to the rest of the code and the critical bug entered against the current implementation is solved, we should allow it as part of the release. I was for the removal of this code, assuming the contributor had abandoned it and it had bugs no one else wanted to fix. But it is a perfectly valid feature and the original developer is stating he is willing to rewrite it. Is it not possible for many databases to configure an idle timeout? I'm pretty sure this kind of ability is to handle the same sort of badly written client code. Does mysql get blamed if a poorly written application loses a connection because it leaked it and did not close it, but mysql reclaims it. How about if the db admin sets the timeout too low and some normal running process ends up corrupting the data because it held a connection too long. I don't think so; it is important that the configuration options are set appropriately for the apps that will be using the database/connection pool. We are not taking on any responsibility for someone's crappy code by such a feature. Consider that you are using dbcp as your connection pool and your code is error-free. You are awaiting a feature from a partner/subcontractor. The feature runs some reporting queries on an interval of 15 minutes and it is known that the queries generally take about a minute. It turns out the partners code is flawed and you are going to lose money, if you have to wait for a fix and start integration testing again after a delay. There might be all sorts of other remedies to this, but being able to configure the pool to recover the connections in the pool being used by the partners code would be optimal, imo. You can then just continue, or worse case immediately start over on, your integration testing. Features related to connection management are appropriate in a connection pool. Is it inappropriate for tomcat to allow an admin to configure a security policy, since well written code will not do anything it shouldn't? On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. Why is this such a contentious issue? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [dbcp] Do we need Referenceable?
On Tue, 2003-07-08 at 22:53, Anton Tagunov wrote: Hello John! JM I am confused (and it has been awhile since I last looked at what is JM required). A DataSource should implement at least one of Referencable JM and Serializable; the specification recommends both. Are you advocating JM that we implement neither? Yes. But probably I really do not understand something essential. Disclaimer: yet have not read all JNDI spec though. Okay, imagine we have a separate Factory and Product. Factory is ObjectFactory, it creates Product. You say it is recommended that Product implements Referenceable or Serializable. But how can this be utilized? I believe there is only one way for it: if we have an object of type Product Product product; and we have a writeable object of class javax.naming.Context Context context; then we may call context.bind( ..., product ); and instead of storing the product itself the context will store either a reference to it, obtained via product.getReference(); or product's serialized form. That sounds like a good description. With Tomcat we're in a different position. Tomcat takes ResourceParams and unconditionally creates a Reference object all by itself populating it with the config data. This Reference also contains the factory class we have configured. What happens if tomcat changes its process to use the standard jndi pattern described above? What about a developer wishing to use dbcp with another servlet container or app server? Why are you advocating that dbcp tie itself exclusively to implementation details of tomcat? (btw, i do use tomcat almost exclusively myself). But what use for our product to implement Referenceable then? It will never have Context.bind() called on it. How can you presume that? So I'm for implementing neither Referenceable nor Serializable. In fact BasicDataSourceFactory/BasicDataSource implement none of this and work find with Tomcat. AT As I understand Tomcat JNDI resource infrastructure, it is enough AT to have an object that implements javax.naming.spi.ObjectFactory JM Are you saying that we can assume that if we meet tomcat's requirements JM for binding to its jndi implementation, that we will meet the JM requirements for a generic jndi implementation? Or that we should only JM worry about tomcat's version? Let's face it. Tomcat makes such a specialized use of the Reference object that our factories this way or other fit only into Tomcat. I don't understand the basis for that statement. You appear to be advocating changes to require only use in tomcat, but jdbc2pool is not currently written that way. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Do we need Referenceable?
On Tue, 2003-07-08 at 08:47, David Graham wrote: It does not seem overly complicated and the work is already done. Is there some bug that requires simplification of the design? Code rarely seems complicated to the original author and bugs are not the only triggers for refactoring. That class is over 1700 lines long and is fairly complex. The version I am looking at is 1500 lines. Here is the breakdown: 150 lines preamble - license and class javadoc 610 lines properties (getters/setters) and associated javadoc 150 lines ObjectFactory implementation 40 lines serialization code which leaves about 550 lines of what i consider logic that might require some analysis. It really is not that much. Are there groups of functionality int there that could be refactored into separate classes? The ObjectFactory implementation should be separated into its own class, but I just found it easier to implement ObjectFactory and Referenceable in the same class as they generally have to be modified together. The 40 lines of serializable code can be eliminated with a dependency on commons-lang or it can be moved to a different class, but its not that much savings. It could be possible to build a slightly less complicated version by not allowing specification of per user limits (such as max connections). But I'd still like to maintain a version that does allow it. john mcnally Maintaining a class that large is difficult. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - 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]
[dbcp] NPE in JNDI lookup [was Re: [dbcp] Do we need Referenceable?]
It would better to enter this as a bug: http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Commonsversion=Nightly+Buildscomponent=Dbcprep_platform=Otherop_sys=otherpriority=Otherbug_severity=Majorbug_status=NEWassigned_to=cc=bug_file_loc=http%3A%2F%2Fshort_desc=comment=maketemplate=Remember+values+as+bookmarkable+templateform_name=enter_bug Details on the stacktrace and possibly the jndi configuration would be helpful when trying to reproduce. john mcnally On Tue, 2003-07-08 at 07:44, Vanita Shroff wrote: Hello Anton: I am trying to use DBCP for a standalone client-server application that does not have any middle layer like Tomcat. And I am trying to use JNDI to bind the object. As per my experience, Jdbc2Pool and DriverAdapterCPDS need to be referenceable in order to bind for standalone applications. The problem I am running into is I am successful in binding the object, but when I do a lookup on the Jdbc2Pool object from client it gives me nullpointerexception. It cannot find the dsInstanceMap that stores the instance value. Any suggestions? Hope this helps in the decision. Vanita - Original Message - From: Anton Tagunov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:01 AM Subject: [dbcp] Do we need Referenceable? Hello, All develpers interested in DBCP! I was reviewing code of Jdbc2PoolDataSource when I hit this question. I even have done a good deal of reading on JNDI yesterday to educate myself on the subject, although I did not master it _all_ though. Now I have a question: do we really need DriverAdapterCPDS and Jdbc2PoolDataSource(Factory) to implement javax.naming.Referenceable? As I understand Tomcat JNDI resource infrastructure, it is enough to have an object that implements javax.naming.spi.ObjectFactory As I understand Referencealbe interface on an object is needed if we want to * first create an object manually * then do .getReference() on it * then bind this reference to a JNDI context It looks like the Tomcat usage scenario is different. As I understand http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html it is * we configure ResourceParameters section in server.xml (or whatever) * at runtime Tomcat creates an object of the class named as 'factory' in those parameters and casts it to the ObjectFactoryInterface * when an instance is needed getObjectInstance() is invoked on those, the first parameter containing the set of properties configured under ResrouceParameters I would have nothing against implementing Referenceable by if it was coming for free to us. But this is not the case. Jdbc2DataSource had to go into greatest quirks and tricks because of this. I would even say that this has determined its design and that it has made this design overcomplicated. The trouble is this: with a DataSource factory we need the client to receive always the same object from the lookup() method. So this is a trivial factory, it always creates the same object. We could bind the object directly into JNDI, but Tomcat does allow us only the factory approach, Okay, so good so far. But, if this only object that is created with the factory is Referenceable, it has to implement .getReference() such that factory.getObjectInstance( reference, ... ) would return the same instance. It would be trivial - as the factory always returns one object, but the trouble is that the code in Jdbc2PoolDataSource for some reason fears that two factory instances will be created at runtime. If this really happens we need to embed the object itself into the reference... ufff... Well, it's got messy. But so is the code in Jdbc2DataSource. So, can we enlighten our burden and just nuke Referenceable from Jdbc2DataSource? The usage scenario it supports seems not be used in practice. I have not studied DriverAdapterCPDS to see how it handles the Referenceable interface. Probably it just records all the config data there to reconstruct the original Reference with which it has been created and thus allows its own clone to be created. As DriverAdapterCPDS does not pool connections itself, having two identically configured DriverAdapterCPDS does not cause the troubles that having two identically configured Jdbc2PoolDataSource would. But while it does not seem to create dramatical trouble it does not give any advantage in my view either. Maybe nuke Referenceable from it altogether? BTW it looks like DriverAdapterCPDS was created first and the Referenceable implementing code was just copied from it to the Jdbc2PoolDataSource. So probably it is a code that does the right thing (tm :) in Jdbc2PoolDataSource anyway. Thoughts? -Anton (And sorry for the message being quite messy itself -- really have got to run right now
Re: [dbcp] NPE in JNDI lookup
On Tue, 2003-07-08 at 10:52, Vanita Shroff wrote: Hi John: I shall report the NPE bug on bugzilla alongwith the jndi configuration. I am totally newbie to JNDI. I have one question. For generic JNDI implementation, if we bind the pool (Jdbc2PoolDataSource ) on the server, should the client get a new pool on every lookup? It is possible and Jdbc2PoolDataSource (DS) attempts to account for that possibility, so that even if the lookup returns a different object, as long as it looked up the DS with the same name, the DS will use the same pool of connections. So I am curious to understand the problem you are seeing. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
non-release (vendor/developer) tags
Is there a policy in jakarta-commons on tagging the cvs repo? Here is my situation: I use dbcp in its current HEAD state. It is stable for my usage. However there is a critical bug and the desire by developers to rewrite large portions of the code, essentially removing some code that was added since its last release. In the past when I have started a refactoring on a codebase that has had a long fairly stable period, but no release, I add a PRE_SOME_CHANGE type of tag. If I added such a tag to dbcp should I expect that it will persist forever? In httpd, I see tags that start with the developer name. Presumably, it is then up to that developer to remove the tag, if they no longer require it; and others should leave it alone. Are such developer tags acceptable in jakarta-commons? Would non-release tags be better marked by the developer that made it, or should more generic names be used? If I were to create a PRE_SOME_CHANGE tag, I would be inclined to leave it for posterity, in the event someone else had started depending on it, and would expect others to leave it alone as well. But if it was JMCNALLY_1, I would remove it as soon as I was able to move to a released state and it would give others the ability to contact me if they wondered if the tag had outlived its usefulness. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: non-release (vendor/developer) tags
It is possible, unless disallowed by the cvs admin. It can be used as a way of managing a release as well as cleaning up a mistake. In some environments it may be more difficult to freeze development on a branch or the release is just not suppose to include everything on the branch. A release team may create a temporary tag, so that it is not confused with an actual release, they then move the tag around during testing and when ready, the official release tag is created and the temporary tag is removed. That might not be the best explanation, but anyway it is possible and has uses whether or not such a uses would be considered best practice I'm not sure. john mcnally On Mon, 2003-07-07 at 19:43, David Graham wrote: I don't see any problem either but I think a generic name is preferable. Can you actually untag the code? I thought once it was tagged it was there forever. David --- Craig R. McClanahan [EMAIL PROTECTED] wrote: I don't see aany problem with non-release tags like this. Craig On Mon, 7 Jul 2003, John McNally wrote: Date: 07 Jul 2003 18:34:58 -0700 From: John McNally [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: non-release (vendor/developer) tags Is there a policy in jakarta-commons on tagging the cvs repo? Here is my situation: I use dbcp in its current HEAD state. It is stable for my usage. However there is a critical bug and the desire by developers to rewrite large portions of the code, essentially removing some code that was added since its last release. In the past when I have started a refactoring on a codebase that has had a long fairly stable period, but no release, I add a PRE_SOME_CHANGE type of tag. If I added such a tag to dbcp should I expect that it will persist forever? In httpd, I see tags that start with the developer name. Presumably, it is then up to that developer to remove the tag, if they no longer require it; and others should leave it alone. Are such developer tags acceptable in jakarta-commons? Would non-release tags be better marked by the developer that made it, or should more generic names be used? If I were to create a PRE_SOME_CHANGE tag, I would be inclined to leave it for posterity, in the event someone else had started depending on it, and would expect others to leave it alone as well. But if it was JMCNALLY_1, I would remove it as soon as I was able to move to a released state and it would give others the ability to contact me if they wondered if the tag had outlived its usefulness. john mcnally - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - 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]
jdbc2pool [was Re: DBCP status?]
Have looked a couple of weeks ago * jdbc2 part seemed out of operation to me (just can't go into a release) I've seen a couple statements like this. No one presents any reasons for their statement though. I started this pool and use it in production, so have dual interest in hearing what the problems are. I see one bug entered against it, but I would not classify it as a blocker. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] cpdsadapter needs a Statement implementation
I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. When first writing cpdsapapter, I determined that using DelegatingConnection was not possible as it allowed reopening of a closed Connection. The code in jdbc2pool and cpdsadapter attempts to be fully jdbc2 (or later) compliant and the specification requires that a Connection object be unusable after close() is called. Now cpdsadapter needs a Statement implementation which will require a ResultSet implementation. Taking another look at DelegatingConnection, it could be used as the base class for a jdbc2 compliant Connection as long as the child class creates a no-op for the activate method. Does anyone see a problem with that approach? The only problem I have with going that route is the situation regarding the abandoned connection code. I thought it was already agreed that this code would be removed many months ago, but I am seeing revived debate and the possibility of retaining some of the code for possible logging. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] should Connection.close() render associated Statementobjects unusable.
I think that currently an application could call Connection.close() while retaining a reference to a Statement object and continue using it. The specification does not require Connection.close() to call Statement.close on any associated Statement(s). Is there a use case for closing a Connection while expecting a Statement to remain active? The general principal when developing a jdbc compliant pool is that the application should experience similar behavior whether a Connection came from a pool or not. I would expect that if a Connection was actually physically closed that operations on its Statement(s) or ResultSets to fail. Would anyone counter that expectation? This situation would appear to be the opposite of the abandoned connection problem, where helping a badly coded application would be straightforward and receiving an sql exception after calling ResultSet.next() on a closed Connection would be preferrable to having multiple threads continuing to use ResultSets while the Connection keeps getting returned to the pool. A related question: I have never found a reason to keep multiple Statements on a single Connection open. The spec states that only a single ResultSet can be open on a Statement at a time and that multiple Statements should be used if multiple open ResultSets are required. Should this be interpreted to mean multiple open Statements per Connection are allowed? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] cpdsadapter needs a Statement implementation
On Sun, 2003-07-06 at 20:51, David Graham wrote: --- John McNally [EMAIL PROTECTED] wrote: I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. Can you explain the uses of the cpdsadapter classes? Having multiple implementations like this seems counter productive. In jdbc2+, a connection pool would not normally wrap a DataSource or Driver. The specification is written so that vendors supply a ConnectionPoolDataSource (CPDS) which would normally be used by a pooling DataSource. Jdbc2PoolDataSource is written to use a CPDS. I created DriverAdapterCPDS, so that it can still be used with jdbc implementations that do not yet implement the newer specification. The jdbc2 specification for a Connection object returned by CPDS.getPooledConnection().getConnection() is that it should always return a new object, only one should be open at any given time, and after Connection.close() is called that object is no longer usable. john mcnally john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] FileUpload 1.0 Final Release Plan
On Sun, 2003-06-22 at 22:23, Martin Cooper wrote: Release Candidate 1 of the Commons FileUpload component has proved to be stable, with no new showstopper issues reported since that release, and only minor documentation updates applied. Therefore, I propose that the tip of the main trunk in CVS be released as FileUpload 1.0 Final. I will act as the Release Manager. -- Vote: FileUpload 1.0 Final Release Plan [X] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
DBCP has 5 open bugs. I recently was looking at 18905 and modified some test code so that it is possible to reproduce. I did not get to the solution, so the test is not activated. It looks like 20649, could be resolved in some fashion by removing the use of AbandonedObjectPool. Getting rid of this code has already been proposed and agreed upon, if someone wants to submit a patch to do so. But the bug is only 2 weeks old, I don't think it can be declared as suffering from neglect. I am the primary developer of the jdbc2pool and cpdsadapter packages. I do not see any reason to merge the code into one package with the rest of dbcp. They seem packaged appropriately to me. The main thing that needs to be done here is to rename the jdbc2 in the names to something else. I don't know what is a better name, but we should not release with jdbc in the class or package names. If anyone wants to become an active developer on dbcp, they are welcome, but I think having at least one patch submitted before people start calling for a vote on new committers should be a minimum. Remember that once you are a committer on dbcp, you too get to subscribe to the deluge known as [EMAIL PROTECTED] in order to watch for the one email a month that might be related to a problem or question on dbcp. john mcnally On Sun, 2003-06-22 at 19:33, David Graham wrote: DBCP is very inactive. Struts dropped it from the distribution due to the lack of development support. David Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - 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: Questions about jdbc2pooldatasource and cpdsadapter
I do not plan any api changes that would affect your usage and I do use
the DataSource and backing ConnectionPoolDataSource in a manner similar
to your example and always connecting as the single user. I have not
noticed any problems.
BasicDataSource uses a Driver to supply the physical connections as
well, so you should be able to use that if you wish.
john mcnally
On Wed, 2003-06-04 at 00:36, hicham ABASSI wrote:
Hy,
I have a JDBC driver v1.0. It doesn't implement the Datasource interface.
This is a Centura SQLBase DB.
I failout to create a JNDI Datasource in Tomcat because this driver doesn't provide
Datasource object.
I need to create a Datasource to using it in JSTL sql tags. (sql:query... )
i can create datasource in a servletcontextlistener with theses the packages :
a.. org.apache.commons.dbcp.cpdsadapter
b.. org.apache.commons.dbcp.jdbc2pool
Here is the theory code :
--
package com.lc.rm.servlets;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.sql.*;
import org.apache.commons.dbcp.*;
import org.apache.commons.dbcp.jdbc2pool.*;
import org.apache.commons.dbcp.cpdsadapter.*;
import javax.servlet.jsp.jstl.core.*;
public class ResourceManagerListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
ServletContext application = sce.getServletContext( );
DataSource ds = null;
try {
DriverAdapterCPDS cpds = new DriverAdapterCPDS();
cpds.setDriver(JdbcDriverClassName);
cpds.setUrl(jdbcUrl);
cpds.setUser(username);
cpds.setPassword(password);
Jdbc2PoolDataSource tds = new Jdbc2PoolDataSource();
tds.setConnectionPoolDataSource(cpds);
tds.setDefaultMaxActive(10);
tds.setDefaultMaxWait(5);
tds.setDefaultAutoCommit(false);
tds.setDefaultMaxIdle(1);
ds = tds;
}
catch (Exception e) {
application.log(Error creating connection pool: , e);
}
// Assign this datasource to the default JSTL Datasource
Config.set(application, Config.SQL_DATASOURCE, ds);
}
public void contextDestroyed(ServletContextEvent sce) {
ServletContext application = sce.getServletContext( );
}
}
But these packages are not released in the 1.0.
Are they stable ?
If not, how to do this with org.apache.commons.dbcp package ?
I need a Datasource, not a driver.
The examples show how to create a PoolDatasource or a PoolDriver.
I regret that i can't create a PoolDatasource with JOCL. is it correct ?
i see that only PoolDriver can read JOCL file.
a.. tomcat 4.1.24
b.. commons-dbcp
c.. SQLBase 7
d.. Windows2000
e.. jdk1.4.1_02
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit:jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2poolTestJdbc2PoolDataSource.java
Anyone have a clue what went wrong with this commit? I committed the
two files: TesterDriver.java and TestJdbc2PoolDataSource.java, with the
following commit log:
Bugzilla number: 18905 - Jdbc2PoolDataSource fails on correct username and password
if first getConnection call uses an incorrect password. This commit alters other
test methods to allow reproduction of the bug. The bug is not fixed yet so the
testIncorrectPassword method javadoc gives instructions on reproducing the bug.
Modified Files:
* src/test/org/apache/commons/dbcp/TesterDriver.java - added a set of valid users and
passwords that are compared against if a request for a Connection includes user info.
* src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java - switched
to use
valid u/p as declared by TesterDriver. Added documentation to testIncorrectPassword
on reproducing 18905
I received the following messages during the commit and the log as
reported in the email is messed up. However the commit appears to have
succeeded and the log message is correctly stored within cvs.
Checking in src/test/org/apache/commons/dbcp/TesterDriver.java;
/home/cvs/jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/TesterDriver.java,v
-- TesterDriver.java
new revision: 1.3; previous revision: 1.2
done
cvs [status aborted]: no such directory
`src/test/org/apache/commons/dbcp'
cvs [status aborted]: no such directory
`src/test/org/apache/commons/dbcp/jdbc2pool'
cvs [status aborted]: no such directory `u'
More commits to come...
Checking in
src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java;
/home/cvs/jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java,v
-- TestJdbc2PoolDataSource.java
new revision: 1.8; previous revision: 1.7
done
cvs [status aborted]: no such directory
`src/test/org/apache/commons/dbcp'
cvs [status aborted]: no such directory
`src/test/org/apache/commons/dbcp/jdbc2pool'
cvs [status aborted]: no such directory `u'
Mailing the commit message...
john mcnally
On Sun, 2003-06-01 at 21:54, [EMAIL PROTECTED] wrote:
jmcnally2003/06/01 21:54:13
Modified:dbcp/src/test/org/apache/commons/dbcp TesterDriver.java *
src/test/org/apache/commons/dbcp/TesterDriver.java
- added a set of valid users and passwords that are
compared against if a request for a Connection
includes user info. *
src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java
- switched to use valid u/p as declared by
TesterDriver. Added documentation to
testIncorrectPassword on reproducing 18905
dbcp/src/test/org/apache/commons/dbcp/jdbc2pool
TestJdbc2PoolDataSource.java *
src/test/org/apache/commons/dbcp/TesterDriver.java
- added a set of valid users and passwords that are
compared against if a request for a Connection
includes user info. *
src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java
- switched to use valid u/p as declared by
TesterDriver. Added documentation to
testIncorrectPassword on reproducing 18905
Log:
Bugzilla number: 18905 - Jdbc2PoolDataSource fails on correct username and password
if first getConnection call uses an incorrect password. This commit alters other
test methods to allow reproduction of the bug. The bug is not fixed yet so the
testIncorrectPassword method javadoc gives instructions on reproducing the bug.
Revision ChangesPath
1.3 +52 -5
jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/TesterDriver.java
Index: TesterDriver.java
===
RCS file:
/home/cvs/jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/TesterDriver.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TesterDriver.java 15 Apr 2003 23:34:34 - 1.2
+++ TesterDriver.java 2 Jun 2003 04:54:11 - 1.3
@@ -68,20 +68,67 @@
import java.sql.SQLException;
import java.util.Properties;
+/**
+ * Mock object implementing the codejava.sql.Driver/code interface.
+ * Returns codeTestConnection/code's from getConnection methods.
+ * Valid username, password combinations are:
+ *
+ * table
+ * trthuser/ththpassword/th/tr
+ * trtdfoo/tdtdbar/td/tr
+ * trtdu1/tdtdp1/td/tr
+ * trtdu2/tdtdp2/td/tr
+ * trtdusername/tdtdpassword/td/tr
+ * /table
+ */
public class TesterDriver implements Driver {
+private static Properties validUserPasswords = new Properties
Re: [patch] [fileupload] [proposal] lib property in build.xml
Is there any reason you are only changing one use of the lib directory?
john mcnally
On Sun, 2003-06-01 at 14:13, Arnaud Vandyck wrote:
robert burrell donkin [EMAIL PROTECTED] wrote:
that sounds fine. please supply a patch against CVS HEAD (see
http://jakarta.apache.org/commons/patches.html for more details).
done ;-)
On Friday, May 30, 2003, at 09:13 AM, Arnaud Vandyck wrote:
Hi all,
I am working on packaging fileupload to Debian. Because of some
requierments in Debian, I have to specify the CLASSPATH my self (or
tell to ant where it is). But I do not have any lib directory, so
ant craches. I've been obliged to comment the additionnal classpath
information in the javac task.
My proposal is to change the reference to the lib directory to a
reference to a property so I can override it from my ant call.
Thanks for your time,
-- Arnaud Vandyck, STE fi, ULg
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/fileupload/build.xml,v
retrieving revision 1.5
diff -u -r1.5 build.xml
--- build.xml 27 Oct 2002 18:47:51 - 1.5
+++ build.xml 1 Jun 2003 21:10:03 -
@@ -9,6 +9,7 @@
property name=distdir value=dist/property
property name=javadocdir value=target/docs/apidocs/property
property name=final.name value=commons-fileupload-1.0-dev/property
+ property name=lib value=lib/property
!-- The test runner to execute --
property name=test.runner value=junit.textui.TestRunner/
@@ -34,7 +35,7 @@
pathelement location=src/java/pathelement
/src
classpath
-fileset dir=lib
+fileset dir=${lib}
include name=*.jar/include
/fileset
/classpath
-
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: [VOTE] FileUpload 1.0 RC1 Release Plan
+1 john mcnally On Sun, 2003-06-01 at 10:40, Martin Cooper wrote: The FileUpload component has been in Beta for some time now. All outstanding bug reports have been resolved, and all deprecated methods removed, so it's time to create a release candidate as the next step towards a FileUpload 1.0 Final release. Therefore, I propose that the tip of the main trunk in CVS be released as FileUpload 1.0 Release Candidate 1. I will act as the Release Manager. -- Vote: FileUpload 1.0 Release Candidate 1 Release Plan [X] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- Here's my own +1. -- Martin Cooper - 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: [VOTE] FileUpload 1.0 Beta 1 Release Plan
+1 john mcnally On Sat, 2003-02-08 at 14:20, Martin Cooper wrote: The FileUpload component has been stable for a while now, but available only from nightly builds. It's time to create a milestone release against which a final series of bug fixes and documentation updates can occur before a FileUpload 1.0 Final release is created. Therefore, I propose that the tip of the main trunk in CVS be released as a FileUpload 1.0 Beta 1 release. I will act as the Release Manager. -- Vote: FileUpload 1.0 Beta 1 Release Plan [X] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- -- Martin Cooper - 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: DBCP: Jdbc2PoolDataSource needs attention
On Fri, 2002-11-01 at 10:04, Roytman, Alex wrote: Dear apache-commons developers, Jdbc2PoolDataSource is a very useful component however I believe it is not up to release quality yet While working with it I found some things I would like to improve or change. Please forgive me if I misunderstood certain things in Jdbc2PoolDataSource design as I could only spend limited time testing, debugging and reading its source 1. mutable poolable keys are very dangerous and lead to errors. One subtle error which rendered entire component useless in case of getConnection(username, password) was due to this error http://issues.apache.org/bugzilla/show_bug.cgi?id=13235 I have made the keys immutable. 2. new pool gets created for every different user getConnection(username, password). Also due to pool design if user wants eviction each pool will span an eviction thread which can easily bring any server to its knees. I think creating new pool for each user is related to ability to configure each user separately. My believe it is really not an objective because a) as much as possible in their projects people should use pools which are fully configured and do not use getConnection(username, password) but getConnection() instead and b) if they do need pool which caters for application where username/password is supplied by user for each session rather then configured in application this pool should have no reason to configure different users differently (as it has no prior knowledge of its users) Also for this kind of pool it is important to be efficient as number of users can be very high and we should be extra careful to survive programming mistakes or malicious users in this case A new pool only gets created for each user that is configured with a perUserMaxActive value and possibly other perUser values. This might be used to have a user that can write and a readOnly user, for example. You state that separate DataSources should be setup for each of these. I don't know enough cases to determine if that is the case, if others agree, we can drop the per user configuration, but I would prefer to keep unless given more definitive reasons it is bad. But it would not effect the number of threads as the overall number of pools will be the same in either case. 3. In current implementation once a pool for particular user/password got created and have some idle connection a user with INVALID password but right user name can grab connections from the pool (have not tested but it looks like it is the case) I have fixed this. 4. failed connections get suck in active pool I was not able to reproduce this, but if the mutable, poolable keys were the problem, it should be fixed. As soon as I get my changes into cvs maybe you could repeat your tests? 5. Not sure why we need to keep a static map of all pools by datasource. J2EE environment will call jndi environment getObjectInstance() only once to create a pool and then the environment will keep the reference and will not call factory method on each object lookup but return previously created instance Tomcat may do this, I do not know. But I do not think a jndi service is required to return the same instance to every lookup. Is there a specification that says J2EE containers will cache instances? The jdbc spec mentions use of static fields as a way to code around the fact that there might be multiple instances which should be referring to the same pool of connections. john mcnally -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
On Fri, 2002-11-08 at 15:05, Henri Yandell wrote: ... Looking at it, and thinking in the usual stop-start way, we have a jdbc2pool project, so assuming that is okay, then jdbcutils is okay [to match beanutils]. I didn't consult with a lawyer when creating the project. The code from jdbc2pool has been merged into dbcp and back to turbine where it started. Thanks for the reminder, I will clear out jdbc2pool. I have still retained the jdbc2pool terminology in the new location. I'll have to consider changing that. john mcnally -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] Release Manager Job Vacancy
Please deprecate the StringStack class before the next release. It is not a Stack implementation and is confusing as part of the collections package. john mcnally On Sat, 2002-10-12 at 17:51, Stephen Colebourne wrote: [collections] needs a release. The code appears to be in a releasable state (I've done some tidying tonight of odds and ends). We are currently lacking a Release Manager however. Does anyone fancy the job ??? Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[collections][lang] deprecate StringStack
This class is badly named and I am not sure it belongs in collections. The original use of this class was to join sql fragments together to form a where clause or a list of columns, etc. So its class doc should be something like: This class provides a way to collect a list of unique strings and join them with an optional separator. This behavour is almost similar to StringUtils.join method though that does not handle the unique requirement. Maybe a suitable replacement could be added to lang.StringUtils? StringStack's original source was torque and we will adjust to the removal of the class. It really should be deprecated, I'm not sure I see the value in trying to create a Stack or List implementation out of the current class. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-fileupload
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-06-16/commons-fileupload.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 4 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI, Tomcat, Distributed Apps, et al.
With new JDBC specs you can do stuff like:
DataSource ds = context.lookup(jdbc/whatever);
if (ds instanceof ConnectionPoolDataSource)
{
/* return a connection from the pool: */
PooledConnection pc = ds.getPooledConnection();
Connection conn = pc.getConnection();
return conn;
}
else /* return a non-pooled connection */
return ds.getConnection();
Applications should not use ConnectionPoolDataSource or
PooledConnection. These interfaces are used to define the interaction
between a pooling DataSource implementation and a jdbc2+ driver
implementation. A ConnectionPoolDataSource is a source of new db
connections for a connection pool.
john mcnally
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-fileupload
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-06-11/commons-fileupload.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 4 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-fileupload
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-06-08/commons-fileupload.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 5 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-fileupload
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-06-07/commons-fileupload.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 5 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] 1.0 release soon
In the event maven and gump are not cooperating, I did make the change to jakarta-turbine-fulcrum. john mcnally On Fri, 2002-05-03 at 10:26, Waldhoff, Rodney wrote: Any remaining to-dos for a 1.0 commons-pool release? My list is done. I just removed the KeyedObjectPool.numActive and KeyedObjectPool.numIdle methods, so we may want to wait for a clean gump build, but otherwise I think we're OK. (Bugzilla is also clear of pool-related bugs.) - Rod -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: minor commons-pool interface change
This is a pretty easy change and as long as this work is getting us very close to a pool package release, I am happy to do so. A little more below: On Tue, 2002-04-30 at 23:33, Waldhoff, Rodney wrote: Sorry for the cross-post, but this seems an appropriate occasion. Future snip/ I've just deprecated those methods in KeyedObjectPool, and I'd like to remove them altogether before the next pool release. snip/ I believe this line is what has caused the series of later emails. As pool has not been released, what does the next release mean? The first one or the one following the first. I assume it means the first. But there can be confusion, I think. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [LOGGING] ClassLoader Problems
It does not seem that static factory methods like Log.getLogger(String) or Category.getInstance(String) are the best way to invoke logging within a component meant to be used within a larger system. I should say it might not be a bad way to invoke the logger, but hardcoding the String key to be the classname where the logger is used appears to be a bad choice. A component needs to have a way to allow the system using the component to override the region/category. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [LOGGING] ClassLoader Problems
Craig R. McClanahan wrote: On Mon, 22 Apr 2002, John McNally wrote: Date: Mon, 22 Apr 2002 10:58:16 -0700 From: John McNally [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [LOGGING] ClassLoader Problems It does not seem that static factory methods like Log.getLogger(String) or Category.getInstance(String) are the best way to invoke logging within a component meant to be used within a larger system. I should say it might not be a bad way to invoke the logger, but hardcoding the String key to be the classname where the logger is used appears to be a bad choice. A component needs to have a way to allow the system using the component to override the region/category. Good versus bad is a pretty emotion-laden discussion starter :-) I just thought it might limit the usefulness of a component, or potentially force the consumer to live with problems due to the use of that design. I'm glad to see it is possible to still use the commons components within multiple webapp contexts even though commons-logging is shared. Thanks for the info. I still wonder about the use case of a application that uses commons-pool (assuming it would use commons-logging) in two packages and would prefer to have the logging segregated along the package lines. E.g. myapp.foo and myapp.bar both using the pool code for different reasons. Assuming this is possible, just ignore me until I actually need to do this and I look for a way to accomplish it. Thanks, john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Query String Parser
http://cvs.apache.org/viewcvs/jakarta-turbine-fulcrum/src/util/org/apache/fulcrum/util/parser/ contains StringValueParser which will handle the parsing/manipulating part. Nothing to create them though. john mcnally Henri Yandell wrote: I don't believe so. I'd imagine the Tomcat project could easily donate one? Hen On Mon, 15 Apr 2002, Bob Lee wrote: Is there a class to parse/manipulate/create query strings in the Commons? Thanks, Bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [FileUpload] Delete uploaded files on exit
applied. thanks. john mcnally Kelvin Tan wrote: I've attached a patch for uploaded files to be deleted when the JVM exits properly. Basically a call to deleteOnExit for the uploaded file. I didn't really want a bunch of tmp files lying around. Regards, Kelvin Name: patch.txt patch.txtType: Plain Text (text/plain) Encoding: quoted-printable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[pool] release - what needs to be done?
Turbine has dropped usage of its own object pooling component in favor of using the commons-pool. We would like to see a release of the component, soon. The code seems robust and reasonably bug free, so what do the author(s) feel is necessary to have a release? What can I do to help? john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DBCP] : DelegatingConnection/PoolableConnection Bug ?
I'm not sure what is being proposed here, so if this is wrong let me
know. But code that is something like the following is not a good idea:
Connection con = pool.getConnection();
...do something...
con.close();
...
if (!con.isClosed())
con.close();
I think dbcp hands out the same Connection objects over and over again.
Once the first close() is called, another thread may access the
connection, so that now isClosed would return false and the connection
is closed again while another thread is using it.
The jdbc2 spec says that a pool should always return a new Connection
object from the getConnection method, and if dbcp does this, maybe this
coding style has some merit, though I am kind of confused as to its
purpose.
fyi, jdbc2pool in the sandbox does hand out new logical Connections for
each call to getConnection.
And once isClosed() returns true, it will always return true.
john mcnally
Anjan wrote:
Hi Rodney!,
Thank you for acknowledging that this could need a fix.
Use Case : Our software can use multiple databases(oracle, mysql)
at the same time. During initialization, I get a connection from each
database and do some queries in a LOOP. The finally {} block cleans up any
connections if there were any exceptions. That's where I try to find if
it's closed -- connection.isClose() . If it's not closed, I close it to
prevent leakage.
FIX : You understood me correctly. Yes, As far as the client program is
concerned, if a previous block of code has already closed the connection,
then the connection.isClosed() should return true. To get this
behavior, we need to modify PoolableConnection? Can you suggest how to fix
this ?
Thank you,
Best Regards,
ANJAN. B
-Original Message-
From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 1:32 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [DBCP] : DelegatingConnection/PoolableConnection Bug ?
Can't say that I use Connection.isClosed often if at all, nor that I fully
understand the use cases here.
Technically speaking, if the underlying connection isn't closed, then
PoolableConnection still has an open channel to the database. Does that
mean isClosed should return true?
I think you're suggesting that PoolableConnection.isClosed should return
true when the connection is in the pool, false when it's out of the pool
(and the underlying connection isn't closed either). Sounds reasonable to
me.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DBCP] : DelegatingConnection/PoolableConnection Bug ?
Anjan wrote:
Hi Rodney/John,
I'm not sure what is being proposed here, so if this is wrong let me
know. But code that is something like the following is not a good idea:
Connection con = pool.getConnection();
...do something...
con.close();
...
if (!con.isClosed())
con.close();
As I said earlier, what I'm doing here is something like this
void func() {
Connection conn = null;
try {
for (i = 0; i NUM_DATABASES; ++i) {
conn = DriverManager.getConnection(driverURL);
// do something with connection ...
conn.close();
}
} // end try
catch() {
//.
}
finally {
// Try to be sure to clean the resources
if (!conn.isClosed()) {
conn.close();
} // end if
} // end finally
} //end func
I would suggest inverting try/catch/finally and for loop so you have
for
try
conn = getConnection
catch
...
finally
conn.close()
end for
or if you want the exception to abort the for loop
try
for
try
conn = getConnection
finally
conn.close()
end for
catch
These variation will guarantee that close be called once and only once.
john mcnally
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [dbcp] JDBC 3.0 and JDK 1.4
Here is a patch that allows dbcp to be compiled under jdk 1.3 and 1.4.
The TesterXXX classes are Lev's noop versions. I implemented working
versions for the DelegatingXXX classes. The new methods are surrounded
by comments.
I modified the build system to copy the src to a build directory and
then the comments that hide the code for 1.3 are removed if
java.sql.Savepoint is available.
john mcnally
Lev Assinovsky wrote:
I attached the classes modified for JSK 1.4/JDBC 3.0
Use it as you want.
--
Lev AssinovskyPeterlink Web
ProgrammerSt. Petersburg, Russia
Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á
E-mail: [EMAIL PROTECTED]
Name: dbcp_jdbc3.0.tar.gz
dbcp_jdbc3.0.tar.gzType: Unix Tape Archive (application/x-tar)
Encoding: base64
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
? jdbc3.patch
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/dbcp/build.xml,v
retrieving revision 1.5
diff -u -r1.5 build.xml
--- build.xml 16 Jan 2002 00:19:36 - 1.5
+++ build.xml 18 Mar 2002 09:01:56 -
@@ -59,6 +59,7 @@
property name=source.src.test value=${source.src}/test/
property name=source.doc value=${basedir}/doc/
property name=dest value=${basedir}/dist/
+ property name=dest.src value=${dest}/src/
property name=dest.classes value=${dest}/classes/
property name=dest.doc value=${dest}/docs/
property name=dest.doc.api value=${dest.doc}/api/
@@ -69,6 +70,7 @@
available property=available-src-java file=${source.src.java}/ !-- does
this module have java src? --
available property=available-src-test file=${source.src.test}/ !-- does
this module have test src? --
available property=jndi.present classname=javax.naming.Context/
+ available property=jdbc3.present classname=java.sql.Savepoint/
/target
@@ -168,10 +170,31 @@
target name=build depends=init,build-java description=compiles source
files/
- target name=build-java depends=init if=available-src-java
+ target name=copy-src depends=init
+ mkdir dir=${dest.src}/
+
+!-- the source code directory --
+copy todir=${dest.src}/org filtering=yes
+fileset dir=${source.src.java} defaultexcludes=no
+include name=**/*.java/
+include name=**/*.xml/
+include name=**/*.properties/
+include name=**/package.html/
+/fileset
+/copy
+
+ /target
+
+ target name=prepare-jdbc3 if=jdbc3.present
+ replace dir=${dest.src} token=/* JDBC_3_ANT_KEY value= /
+ replace dir=${dest.src} token=JDBC_3_ANT_KEY */ value= /
+ /target
+
+ target name=build-java depends=copy-src, prepare-jdbc3
+if=available-src-java
mkdir dir=${dest.classes}/
+
javac destdir=${dest.classes}
- srcdir=${source.src.java}
+ srcdir=${dest.src}
classpath=${classpath}
debug=false
deprecation=true
@@ -182,9 +205,19 @@
/target
target name=build-test depends=init,build-java if=available-src-test
+ mkdir dir=${dest.src}/
+!-- the source code directory --
+copy todir=${dest.src}/org filtering=yes
+fileset dir=${source.src.test} defaultexcludes=no
+include name=**/*.java/
+/fileset
+/copy
+
+ antcall target=prepare-jdbc3 /
+
mkdir dir=${dest.classes}/
javac destdir=${dest.classes}
- srcdir=${source.src.test}
+ srcdir=${dest.src}
classpath=${classpath}
debug=false
deprecation=true
Index: src/java/org/apache/commons/dbcp/DelegatingConnection.java
===
RCS file:
/home/cvspublic/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DelegatingConnection.java
--- src/java/org/apache/commons/dbcp/DelegatingConnection.java 14 Apr 2001 17:15:17
- 1.1.1.1
+++ src/java/org/apache/commons/dbcp/DelegatingConnection.java 18 Mar 2002 09:01:56
+-
@@ -172,4 +172,95 @@
((DelegatingConnection)_conn).passivate();
}
}
-}
\ No newline at end of file
+
+// JDBC 3.0
+/* JDBC_3_ANT_KEY
+
+public void setHoldability(int holdability) throws SQLException
+{
+checkOpen();
+_conn.setHoldability(holdability);
+}
+
+public int getHoldability() throws SQLException
+{
+checkOpen
Re: Db bean issue
Jason R Lee wrote: Ya, I guess turbine is more of a 'struts for the back end' so maybe i need to narrow my approache or view like you're saying. I'm not sure what to make of this statement. Turbine is a web-application framework and contains code useful for presentation as well as persistence. The persistence framework is separate and could be used with any servlet or other gui frontend. Turbine's presentation framework is flexible and allows multiple technologies to be used (jsp, velocity, etc.). Struts was started as some felt that a system that concentrated on only using jsp as the presentation technology would be easier for those trying to learn jsp. Now I believe struts is going in the direction of allowing templating systems such as velocity to be used as well. (Which I guess should be expected as velocity kicks butt over jsp.) So I would not say turbine is a struts for the back end, though torque, stratum, fulcrum (subprojects of turbine) can be used with struts or any other presentation layer. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Db bean issue
jakarta-turbine-torque john mcnally Jason R Lee wrote: Hello anyone who's out there, I have an 'issue' that is rearing its head again and wld like to get anyones take on it. It concerns beans db and the lack (or maybe not) of a kinda jakarta proj/framework like struts, but addresses the back end. I know, there's EJB, etc... But, after working on EJB and non-EJB projects, I'm not convinved EJB is any more scalable or distributable than a good implementation of data aware beans - or something along those lines. I helped design a quite popular, big air travel site that took a non-EJB approach and worked well and scaled across 15 Sun boxes without a hitch. However, the implementation was a little complex and now that I'm working on another project, I'd like to have the same thing at a simpler level. So I guess I'm just kinda saying hi to the Commons proj and trying to see if anyone has thought about this issue. Especially since there is no Jakarta sub-project or Commons portion addressing this issue. Thanks and hi, - Jason -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[lang] PATCH add serialize method to lang.Objects
Here is another try with a better subject. Also changed the serialize
method to return null instead of throwing an exception, so it behaves
similarly to the deserialize method. Though I think both methods
throwing an exception would be better.
previous message:
Here is a patch to add a serialize method to Objects to complement the
deserialize method. Also included are unit tests for Objects.
john mcnally
package org.apache.commons.lang;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Turbine must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*Apache Turbine, nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
import java.util.HashMap;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
/**
* Unit tests {@link org.apache.commons.lang.Objects}.
*
* @author a href=mailto:[EMAIL PROTECTED];John McNally/a
*/
public class ObjectsTest extends TestCase
{
private static final String FOO = foo;
private static final String BAR = bar;
private static final String MAP_ERROR =
Map did not serialize and deserialize to equivalent map;
public ObjectsTest(String name)
{
super(name);
}
public void testIsNull()
{
Object o = FOO;
Object dflt = BAR;
assertEquals(dflt was not returned when o was null, dflt,
Objects.isNull(null, dflt));
assertEquals(dflt was returned when o was not null, o,
Objects.isNull(o, dflt));
}
public void testDeserialize()
{
serializeDeserialize();
}
public void testSerialize()
{
serializeDeserialize();
}
private void serializeDeserialize()
{
HashMap original = new HashMap();
original.put(FOO, BAR);
original.put(BAR, FOO);
byte[] ser = Objects.serialize(original);
HashMap deser = (HashMap)Objects.deserialize(ser);
assertEquals(MAP_ERROR, original.get(FOO), deser.get(FOO));
assertEquals(MAP_ERROR, original.get(BAR), deser.get(BAR));
}
public void testEquals()
{
assertTrue(Objects.equals(null, null) returned false,
Objects.equals(null, null));
assertTrue(Objects.equals(\foo\, null) returned true,
!Objects.equals(FOO, null));
assertTrue(Objects.equals(null, \bar\) returned true,
!Objects.equals(null, BAR));
assertTrue(Objects.equals(\foo\, \bar\) returned true
Re: Silly Question
SequencedHashMap is the consequence of moving sandbox/util/SequencedHashtable into collections. So there is no reason to add SequencedHashtable again (this time as is.) I think what ought to be done is to fix the javadoc in both classes. Remove the This class is thread-safe declaration in SequencedHashMap. Add some text to SequencedHashtable to the affect of what Michael states below and deprecate it. john mcnally Michael A. Smith wrote: On Thu, 24 Jan 2002, Scott Sanders wrote: Are you asking whether SequencedHashtable should be committed to the collections component unaltered? Yes. I'm not a committer, so weigh my thoughts how you wish: In my opinion, no. While a synchronized version may be worthwhile, I think it would be better implemented wrapping the impl in SequencedHashMap using Collections.synchronizedMap. Having it inherit from Hashtable rather than HashMap doesn't really add anything other than increased headache in maintenance (any bug fixes would need to be applied to both SequencedHashtable and SequencedHashMap) Asking whether no-JDK 1.2 collection types can go into the collections component? Yes. Again, I'm not a committer, so weigh my thoughts how you wish: The commons collections component is attempting to fill holes left unfilled by Sun's implementations[1]. Non-JDK 1.2-based collections could appropriately fit within that charter, thus should certainly be allowed in the collections component. For example, a Heap implementation that orders things based on a priority specified when inserting the item into the heap (requires add(Object o, int priority) which doesn't exist anywhere in the JDK 1.2 collections API). regards, michael [1] http://jakarta.apache.org/commons/collections.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jdbc2pool
Thanks for the package correction. put unit test classes in the same package, put the source in a parallel tree. src/java/org/... src/test/org/... runtime/blackbox tests i am up for suggestions, but org.apache.commons.jdbctool.test would be good. john mcnally Andy Olliver wrote: Here are some small changes to the files of jakarta-sandbox-jdbc2pool to correct the old package name - I can only read from CVS, so here is a zip of changed files. I started off using DBCP, but it doesn't seem to support all the SQL I am using, so perhaps this alternative will help. If so I will look to create the necessary factory classes to integrate with Tomcat 4 (unless someone has done this already..) I believe all classes in this project should now belong to: org.apache.commons.jdbc2pool not org.apache.commons.torque I am hoping to do some testing on this solution, should I be creating a test package: test.apache.commons.jdbc2pool for any usefull test classes? Andy Name: changes.zip changes.zipType: Zip Compressed Data (application/x-zip-compressed) Encoding: base64 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jdbc2pool
2. Jdbc2 driver implementation will supply a CPDS that should be used when pooling connections. DBCP does not use this interface instead it pools the older style Connection objects. I'm not sure I follow you here. If you've got a DataSource that pools the connections, what's left for the pool package to do? If your DataSource doesn't pool connections, isn't Connection the right object to pool? Just out of curiousity, why is ConnectionPoolDataSource important to you? At the application level, for instance, J2EE applications deal in terms of javax.sql.DataSource implementations -- CPDS look like its only relevant if you want to build XADataSource things for distributed transactions. A CPDS and XADS are two different beasts. Both are possible backends for a DataSource. In jdbc2 it is not correct to pool Connection objects. You are supposed to pool PooledConnections which are supplied by the CPDS and both are implemented by the jdbc driver. (you can also write a pool that pools XAConnections provided by a XADS, but that is something totally different.) An application will not interact at all with a PooledConnection object, they are only used by the pool to obtain Connection objects which are passed to the app. So the DBCP is not pooling the correct objects in a jdbc2 context. However, it is pooling PreparedStatements which is a good thing and not included as part of PooledConnection in jdbc2. PooledConnection objects are supposed to have the necessary hooks to make pooling PreparedStatements easier in jdbc3. So according to Rod's comments should I assume that DBCP will not be altered to work with a CPDS until jdbc3 is finalized? I think it should be possible to use wrappers similar to how I interpret DBCP working now to implement PreparedStatement pooling, though it would not necessarily follow the spirit of the jdbc2 spec, that probably does not matter when a significant efficiency can be had by bending the rules. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/jdbc2pool - New directory
Randy Speh wrote: Could you please give me hint on how the new jdbc2pool connection pool is supposed to be used? I would like to use a OracleConnectionPoolDataSource to pool some connections and in another case I'd like to use a DataSource object managed by WebSphere. The pool will use any ConnectionPoolDataSource (CPDS) as its backend supply of physical database connections. The backend datasource is specified using the setDataSourceName method which is used to find the CPDS using jndi. The maximum number of connections can be configured on a per user basis; the rest of the properties are set globally. The Jdbc2PoolDataSource can be instantiated and initialized using standard bean introspection methods. So it should be deployable using any tool meant for use with DataSources or general javabeans. It does use Properties for the per user maximum connections as well as the jndi environment properties, which are both optional. I do not know how well these might be supported by the standard tools. All the other properties are String's or int's. In torque the DataSource(s) can be bound to jndi using a simple properties file to determine initialization. The internal pools are stored in a class attribute Map, so several instances of the DataSource will share the same connections. This arrangement is given as an example in the specification. A better cache than a HashMap could be used to add more functionality, but such optimizations are being left until the future of this pool code is better determined. Finally the pool can be initialized and used as a normal class, here is an example using the DriverAdapterCPDS that comes with the pool: DriverAdapterCPDS pcds = new DriverAdapterCPDS(); pcds.setDriver(org.gjt.mm.mysql.Driver); pcds.setUrl(jdbc:mysql://localhost/test); pcds.setUser(root); pcds.setPassword(xxx); Jdbc2PoolDataSource tds = new Jdbc2PoolDataSource(); tds.setConnectionPoolDataSource(pcds); tds.setDefaultMaxConnections(10); tds.setMaxExpiryTime(3600); tds.setConnectionWaitTimeout(10); tds.setLogInterval(300); DataSource ds = tds; ... Connection con = ds.getConnection(); john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
commit privileges
I would like to be able to commit some code from the turbine and its subprojects to the sandbox. Can I get commit permissions. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
torque and my work on its connection pool.
I guess there has been some discussion on whether commons should come up with an alternative to torque or whether torque should be moved to commons. I am unclear on why torque is unsatisfactory due to its current location. I will have read up on that discussion, if anyone has useful pointers to the discussion in the archive that would be great, otherwise I will find them. But I will take a moment to describe my work on updating torque as this work seems to have come up in an validation framework thread. Torque currently relies on an internal connection pool. I would like that this reliance dependence be broken, so i looked at the jdbc2 api regarding connection pooling and decided to adopt it for use in torque as that should maximize the number of pools available. So for torque the part of the jdbc2 api that is relevant is 1. The connection is retrieved through DataSource.getConnection 2. The connection is returned (or disposed of) through Connection.close() It is possible the commons dbcp package meets these requirements and so it could be used with torque. I looked at dbcp and it did not seem to be jdbc2 compliant. In looking at the pool it had many classes, so the design was difficult for me to get a handle on. I opted instead to make torque's connection pool jdbc2 compliant. As torque's cp was two classes this seemed like a much easier task. Actually it turned out to not be that simple (but it is still two classes), so in hindsight maybe I should have taken the additional time to figure out the commons dbcp and then try to become a member of the commons and push through an upgrade of the dbcp to the latest jdbc api. Are the maintainers of the commons dbcp interested in updating their pool to be jdbc2 (or 3) compliant? I think they would be well served by looking at the work I have done on torque's dbcp. I will post a link to the files if they are interested. I created an adapter for use with jdbc drivers that do not implement the latest api that would likely be useful if and when the commons dbcp was updated. john mcnally -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
