Re: New Commons Committer: Dain Sundstrom
SVN and JIRA karma granted. On 7/20/07, Phil Steitz <[EMAIL PROTECTED]> wrote: Please join us in welcoming Dain Sundstrom as a new Commons committer. Dain is an apache committer active on multiple ASF projects who has been contributing patches to [dbcp] faster than we can commit them :) We are happy to have him among us as a Commons committer. Welcome, Dain! - 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]
New Commons Committer: Dain Sundstrom
Please join us in welcoming Dain Sundstrom as a new Commons committer. Dain is an apache committer active on multiple ASF projects who has been contributing patches to [dbcp] faster than we can commit them :) We are happy to have him among us as a Commons committer. Welcome, Dain! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: > On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: > >> On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >>> Are there any DBCP-1.3 release plans? Based on the JIRAs I think we >>> are close to being ready to release. Are there any items that are >>> planned but don't have JIRAs? >> >> There are two things that I would like to at least talk about that >> relate to various JIRAs and comments on the list: >> >> 1) Intended current and future contract of close() on a connection >> pool, in particular the contract of BasicDataSource.close. The >> javadoc says "Close and release all connections that are currently >> stored in the connection pool associated with our data source." Some >> users interpret this - incorrectly - to mean that close will close >> *active* as well as idle connections. Even when AbandonedConfig is >> used (in which case the pool holds references to connections that >> have >> been checked out), close only closes idle connections (since the >> "pool" is really and idle object pool). So the answer to the >> question >> in, e.g. DBCP-221, is "sorry, no way to do that." Javadoc should be >> improved in any case. >> >> 2) Immutable-once-initialized status of BasicDataSource. I am >> inclined to close DBCP-221 as WONTFIX, but in this case we should >> rip out the remnants of what must have seemed like a good idea at the >> time to support "restart". This is sort of related to 1), because if >> we are going to attempt to allow BasicDataSource to be mutable >> once it >> has been initialized, I don't see any way to do that consistently >> without closing or appropriately modifying connections that have been >> checked out. Since we don't do that now, we can't really support >> this. My vote would be to keep BasicDataSource >> "immutable-once-initialized". > > I think these are basically the same issue. I agree with the > comments in DBCP-221 which seems to want a lingering close. This > is in line with how I expect close to work (having not read any of > the pooling code yet). > > I think the root of this problem is we don't have a clear start/ > stop life-cycle methods. Currently, we are using the first > getConnection() for start and close() for stop, which I think are > good choices. Maybe we could keep those choices, and introduce an > explicit start(), stop() and stop(long maxWait). This way we can > support the close lingering and close immediately options people > seem to be asking for. Once we have this functionality, it should > be easy to add restart() which would close() lingering the existing > inner datasource and create/start a new one. > > I'm not sure this is something that can be done without changes to > pool, but I'll take a look at it today. I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I am fine waiting to DBCP 1.4, since unless we are talking about different things, this really amounts to a significant change to both dbcp and pool. If what we want is to *always* track open connections and have the "lingering close" apply to the active (i.e. checked out) as well as idle connections, we need to follow through on what looks like it was the original plan of moving AbandonedObjectPool to pool and use this _all the time_ in place of GenericObjectPool, which is really just an idle object pool (maintains no references to borrowed objects). In any case, we need to get a pool release out ASAP since pool 1.3 introduced some bugs that are causing problems (see for example POOL-97) since dbcp started using this version. Synchronization was increased in pool 1.3 as well. The hang here is lack of volunteer time and difficulty getting into the codebase. I have only recently started working on the pool code base. The compositepool package includes an alternative impl that we have been thinking about as a pool 2.0. The plan that I proposed a while back (http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg94027.html) was to push out a pool 1.3.1 patch release fixing POOL-97 (when reviewing the patch there, remember that dbcp statement pooling can create quite a few pools) and other bugs fixed since 1.3 and have DBCP 1.3 depend on that, both fully backward compatible with current versions. I still think we should do that. I can handle the RM duty for both of these and close a couple more of the pool bugs, but what we need to speed things up is more eyeballs validating and testing and contributing - and applying - patches. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-20072007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-20072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-20072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-20072007.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-20072007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressHandler [javac] return (org.apache.ws.jax
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-20072007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-20072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-20072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-20072007.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-20072007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressHandler [javac] return (org.apache.ws.jax
[EMAIL PROTECTED]: Project commons-jelly-tags-util (in module commons-jelly) 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-jelly-tags-util has an issue affecting its community integration. This issue affects 7 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-util : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-util-20072007.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/util] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-20072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20072007.jar:/srv/gump/public/workspace/jakarta-commons/lang/commons-lang-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-20072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: commons-beanutils-bean-collections-1.7.0.jar (try downloading from http://jakarta.apache.org/commons/beanutils/) Total time: 2 seconds Finished at: Fri Jul 20 17:30:15 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 05001620072007, vmgump:vmgump-public:05001620072007 Gump E-mail Identifier (unique within run) #3. -- 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-jelly-tags-util (in module commons-jelly) 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-jelly-tags-util has an issue affecting its community integration. This issue affects 7 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-util : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-util-20072007.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/util] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-20072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-20072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20072007.jar:/srv/gump/public/workspace/jakarta-commons/lang/commons-lang-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-20072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: commons-beanutils-bean-collections-1.7.0.jar (try downloading from http://jakarta.apache.org/commons/beanutils/) Total time: 2 seconds Finished at: Fri Jul 20 17:30:15 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 05001620072007, vmgump:vmgump-public:05001620072007 Gump E-mail Identifier (unique within run) #3. -- 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-digester (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-digester has an issue affecting its community integration. This issue affects 49 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - authx-example : Apache Authentication and Authorization Framework - commons-betwixt : Commons Betwixt Package - commons-chain : GoF "Chain of Responsibility" pattern - commons-configuration : Jakarta commons - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-services : Basic Services Architecture - commons-validator : Validation Framework - db-ddlutils : Easy-to-use component for working with Database Definition (... - eyebrowse : Web-based mail archive browsing - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - invicta : Open-source build management tool. - jakarta-lucene : Java Based Search Engine - jakarta-taglibs-jmstags : JMS Taglib - jakarta-tomcat : Servlet 2.2 and JSP 1.1 Reference Implementation - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote : Connectors to various web servers - jakarta-tomcat-coyote-tomcat3 : Connectors to various web servers - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-http11 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-jcs : Cache - lucene-java : Java Based Search Engine - maven : Project Management Tools - maven-bootstrap : Project Management Tools - myfaces : JavaServer(tm) Faces implementation - naming-config : Apache Directory Naming Component - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - quartz : Job Scheduler - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - tapestry : Component-based web application framework organized around i... - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-digester/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-digester.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-digester/gump_work/build_jakarta-commons_commons-digester.html Work Name: build_jakarta-commons_commons-digester (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist [Working Directory: /srv/gump/public/workspace/jakarta-commons/digester] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/pu
[EMAIL PROTECTED]: Project commons-digester (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-digester has an issue affecting its community integration. This issue affects 49 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - authx-example : Apache Authentication and Authorization Framework - commons-betwixt : Commons Betwixt Package - commons-chain : GoF "Chain of Responsibility" pattern - commons-configuration : Jakarta commons - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-services : Basic Services Architecture - commons-validator : Validation Framework - db-ddlutils : Easy-to-use component for working with Database Definition (... - eyebrowse : Web-based mail archive browsing - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - invicta : Open-source build management tool. - jakarta-lucene : Java Based Search Engine - jakarta-taglibs-jmstags : JMS Taglib - jakarta-tomcat : Servlet 2.2 and JSP 1.1 Reference Implementation - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote : Connectors to various web servers - jakarta-tomcat-coyote-tomcat3 : Connectors to various web servers - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-http11 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-jcs : Cache - lucene-java : Java Based Search Engine - maven : Project Management Tools - maven-bootstrap : Project Management Tools - myfaces : JavaServer(tm) Faces implementation - naming-config : Apache Directory Naming Component - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - quartz : Job Scheduler - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - tapestry : Component-based web application framework organized around i... - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-digester/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-digester.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-digester/gump_work/build_jakarta-commons_commons-digester.html Work Name: build_jakarta-commons_commons-digester (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist [Working Directory: /srv/gump/public/workspace/jakarta-commons/digester] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/pu
[DBCP] close issues
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says "Close and release all connections that are currently stored in the connection pool associated with our data source." Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the "pool" is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is "sorry, no way to do that." Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support "restart". This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource "immutable-once-initialized". I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/ stop life-cycle methods. Currently, we are using the first getConnection() for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I did attach a patch to DBCP-221 that stops BasicDataSource from recreating the inner PoolingDataSource once close has been called. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: > On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: > >> I would love to have a fix for DBCP-44; but that could wait on pool >> 1.4 if necessary (and Ipersonally see no way to fix it just within >> dbcp. It would be great if I was wrong on that). > > I think the makeObject method is over synchronized. Actually, the > class doesn't look it's synchronized properly at all. I'll take a > shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. Yes, and at least for dbcp 1.3, I would prefer not to hop all the way to 1.5 required JDK level. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. Before writing another one, have a look at the compositepool package in pool head. -dain - 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]
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514366
]
Dain Sundstrom commented on DBCP-44:
Ok one more comment before I get lunch My sample code above is bad. It is
a hard loop (duh). Instead of hard looping, the second check on the
idleCollection could wait for a item to become available (easy with a
concurrent queue). Which leave the possibility that someone sneaks in and
steals the new connection we were waiting for :( As, I said it will take some
experimentation to get this right, but that is the fun part.
> [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
> -
>
> Key: DBCP-44
> URL: https://issues.apache.org/jira/browse/DBCP-44
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.1
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Layton
> Fix For: 1.3
>
> Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
> testConcurrency.java
>
>
> The GenericObjectPool Evictor thread can potentially cause a deadlock between
> its connection factory and java.sql.DriverManager. The deadlock occurs when
> the
> Evictor thread is trying to make enough connections to bring the pool's idle
> connections up to what's specified in minIdle, at the same time a connection
> is
> being requested through DriverManager.getConnection(). See the attached stack
> trace dump:
> Found one Java-level deadlock:
> =
> "Thread-0":
> waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
> which is held by "main"
> "main":
> waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
> org.apache.commons.dbcp.PoolableConnectionFactory),
> which is held by "Thread-0"
>
> Java stack information for the threads listed above:
> ===
> "Thread-0":
> at java.sql.DriverManager.getConnection(DriverManager.java:158)
> - waiting to lock <0x698c2b48> (a java.lang.Class)
> at
> org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - locked <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
> at
> org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
> at
> org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
> at
> org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
> at java.lang.Thread.run(Thread.java:595)
> "main":
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - waiting to lock <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
> at
> org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
> at java.sql.DriverManager.getConnection(DriverManager.java:525)
> - locked <0x698c2b48> (a java.lang.Class)
> at java.sql.DriverManager.getConnection(DriverManager.java:193)
> - locked <0x698c2b48> (a java.lang.Class)
> at Deadlock.main(Deadlock.java:83)
>
> Found 1 deadlock.
> The deadlock occurs when GenericObjectPool.addObject() calls synchronized
> method
> PoolableConnectionFactory.makeObject(), meanwhile static synchronized
> DriverManager.getConnection() is called. makeObject() waits for the lock on
> DriverManager to be released, whereas DriverManager waits for the lock on the
> PoolableConnectionFactory instance to be released.
> The Java program below, based on ManualPoolingDriverExample.java provided with
> DBCP, duplicates the deadlock for me within several seconds of being run:
> import java.sql.*;
> import org.apache.commons.pool.*;
> import org.apache.commons.pool.impl.*;
> import org.apache.commons.dbcp.*;
>
> /**
> * Duplicate DBCP pool deadlocking.
> *
> * Compile with:
> * /usr/java/jdk1.5.0/bin/javac
> * -classpath
> commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
> * Deadlock.java
> *
> * Run with:
> * /usr/java/jdk1.5.0/bin/java
> * -classpath
> commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
> * Deadlock
> *
> * Locks still occur when compiled and run with J2SDK 1.4.1_03.
> */
> public class Deadlock {
>
> private static final int ACTIVE = 10;
>
> priv
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514364
]
Dain Sundstrom commented on DBCP-44:
BTW it isn't the evictor thread that is problematic per say (it could have
other issues :)). It is the fact that when generic object pool calls
makeObject it is holding a lock on the whole pool. This type of lock holding
open out call is bound to cause dead locks. The example in this issue is a
dead lock between a thread using a DBCP pool to get a connection and a thread
that goes directly to the DriveManager for a connection.
> [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
> -
>
> Key: DBCP-44
> URL: https://issues.apache.org/jira/browse/DBCP-44
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.1
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Layton
> Fix For: 1.3
>
> Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
> testConcurrency.java
>
>
> The GenericObjectPool Evictor thread can potentially cause a deadlock between
> its connection factory and java.sql.DriverManager. The deadlock occurs when
> the
> Evictor thread is trying to make enough connections to bring the pool's idle
> connections up to what's specified in minIdle, at the same time a connection
> is
> being requested through DriverManager.getConnection(). See the attached stack
> trace dump:
> Found one Java-level deadlock:
> =
> "Thread-0":
> waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
> which is held by "main"
> "main":
> waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
> org.apache.commons.dbcp.PoolableConnectionFactory),
> which is held by "Thread-0"
>
> Java stack information for the threads listed above:
> ===
> "Thread-0":
> at java.sql.DriverManager.getConnection(DriverManager.java:158)
> - waiting to lock <0x698c2b48> (a java.lang.Class)
> at
> org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - locked <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
> at
> org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
> at
> org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
> at
> org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
> at java.lang.Thread.run(Thread.java:595)
> "main":
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - waiting to lock <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
> at
> org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
> at java.sql.DriverManager.getConnection(DriverManager.java:525)
> - locked <0x698c2b48> (a java.lang.Class)
> at java.sql.DriverManager.getConnection(DriverManager.java:193)
> - locked <0x698c2b48> (a java.lang.Class)
> at Deadlock.main(Deadlock.java:83)
>
> Found 1 deadlock.
> The deadlock occurs when GenericObjectPool.addObject() calls synchronized
> method
> PoolableConnectionFactory.makeObject(), meanwhile static synchronized
> DriverManager.getConnection() is called. makeObject() waits for the lock on
> DriverManager to be released, whereas DriverManager waits for the lock on the
> PoolableConnectionFactory instance to be released.
> The Java program below, based on ManualPoolingDriverExample.java provided with
> DBCP, duplicates the deadlock for me within several seconds of being run:
> import java.sql.*;
> import org.apache.commons.pool.*;
> import org.apache.commons.pool.impl.*;
> import org.apache.commons.dbcp.*;
>
> /**
> * Duplicate DBCP pool deadlocking.
> *
> * Compile with:
> * /usr/java/jdk1.5.0/bin/javac
> * -classpath
> commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
> * Deadlock.java
> *
> * Run with:
> * /usr/java/jdk1.5.0/bin/java
> * -classpath
> commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
> * Deadlock
> *
> * Locks still occur when compiled and run with J2SDK 1.4.1_03.
> */
> public class Deadlock {
>
> private static final int ACTIVE = 10;
>
> pri
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514362
]
Dain Sundstrom commented on DBCP-44:
This will take experimentation, but off the top of my head, I'd do somthing
like this:
while(true) {
synchronized(idleCollection) {
if (!idleCollection.isEmpty()) {
return idleCollection.removeFirst();
}
}
Future future = this.allocationFutureAtomic.get();
if (allocationFuture == null) {
future = new AllocationFuture();
if (this.allocationFutureAtomic.weakCompareAndSet(null, future)) {
future.get();
}
}
}
The AllocationFuture would create new connection(s), add them to the idle pool,
and then clear the future atomic. Of course this can be done with primitives,
but it is more painful to code. It would be cleaner to use an executor to
process the future, so it can potentially be done on another thread which isn't
holding locks, and if the makeObject() hangs you, don't have to interrupt an
application thread. All of this becomes more difficult when you try to
implement a keyed pool due to double book keeping of a global count and per key
count.
Anyway, I'll experiment with some implementations and if I come up with
anything good, I'll post it.
> [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
> -
>
> Key: DBCP-44
> URL: https://issues.apache.org/jira/browse/DBCP-44
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.1
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Layton
> Fix For: 1.3
>
> Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
> testConcurrency.java
>
>
> The GenericObjectPool Evictor thread can potentially cause a deadlock between
> its connection factory and java.sql.DriverManager. The deadlock occurs when
> the
> Evictor thread is trying to make enough connections to bring the pool's idle
> connections up to what's specified in minIdle, at the same time a connection
> is
> being requested through DriverManager.getConnection(). See the attached stack
> trace dump:
> Found one Java-level deadlock:
> =
> "Thread-0":
> waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
> which is held by "main"
> "main":
> waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
> org.apache.commons.dbcp.PoolableConnectionFactory),
> which is held by "Thread-0"
>
> Java stack information for the threads listed above:
> ===
> "Thread-0":
> at java.sql.DriverManager.getConnection(DriverManager.java:158)
> - waiting to lock <0x698c2b48> (a java.lang.Class)
> at
> org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - locked <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
> at
> org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
> at
> org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
> at
> org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
> at java.lang.Thread.run(Thread.java:595)
> "main":
> at
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> - waiting to lock <0x65df7030> (a
> org.apache.commons.dbcp.PoolableConnectionFactory)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
> at
> org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
> at java.sql.DriverManager.getConnection(DriverManager.java:525)
> - locked <0x698c2b48> (a java.lang.Class)
> at java.sql.DriverManager.getConnection(DriverManager.java:193)
> - locked <0x698c2b48> (a java.lang.Class)
> at Deadlock.main(Deadlock.java:83)
>
> Found 1 deadlock.
> The deadlock occurs when GenericObjectPool.addObject() calls synchronized
> method
> PoolableConnectionFactory.makeObject(), meanwhile static synchronized
> DriverManager.getConnection() is called. makeObject() waits for the lock on
> DriverManager to be released, whereas DriverManager waits for the lock on the
> PoolableConnectionFactory instance to be released.
> The Java program below, based on ManualPoolingDriverExample.java provided with
> DBCP, duplicates the deadlock for me within several seconds of being run:
> import java.sql.
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[ https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514358 ] Holger Hoffstätte commented on DBCP-44: --- Hi Dain, I agree that the evictor thread is problematic (it should go away and/or be replaced by a custom evictor thingy that gets scheduled externally), but it is not clear to me how you could make makeObject() non-synchronized. If you want to go for the usual create-and-CAS pattern you risk a potential double allocation, and pool is definitely used for situations where this would be *very* bad. A multi-staged locking hierarchy (implemented with the new ReentrantReadWrite locks) could help us to the effect that you outlined wrt. the lock ordering. Entering readers (pool consumers) all would have to pass the global writer lock entrance; once someone is inside, the periodic evictor has to enqueue at the fron t door until he gets the write lock, and can proceed. Completely concurrent (lock-free) eviction would be much harder. A mutli-staged locking hierarchy would also enable us to properly decouple some of the other paths inside borrow/returnObject. For returnObject I have already submitted such a simple patch. > [dbcp] Evictor thread in GenericObjectPool has potential for deadlock > - > > Key: DBCP-44 > URL: https://issues.apache.org/jira/browse/DBCP-44 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.1 > Environment: Operating System: All > Platform: All >Reporter: Eric Layton > Fix For: 1.3 > > Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, > testConcurrency.java > > > The GenericObjectPool Evictor thread can potentially cause a deadlock between > its connection factory and java.sql.DriverManager. The deadlock occurs when > the > Evictor thread is trying to make enough connections to bring the pool's idle > connections up to what's specified in minIdle, at the same time a connection > is > being requested through DriverManager.getConnection(). See the attached stack > trace dump: > Found one Java-level deadlock: > = > "Thread-0": > waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class), > which is held by "main" > "main": > waiting to lock monitor 0x0809aad4 (object 0x65df7030, a > org.apache.commons.dbcp.PoolableConnectionFactory), > which is held by "Thread-0" > > Java stack information for the threads listed above: > === > "Thread-0": > at java.sql.DriverManager.getConnection(DriverManager.java:158) > - waiting to lock <0x698c2b48> (a java.lang.Class) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > - locked <0x65df7030> (a > org.apache.commons.dbcp.PoolableConnectionFactory) > at > org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996) > at > org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978) > at > org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124) > at > org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090) > at java.lang.Thread.run(Thread.java:595) > "main": > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > - waiting to lock <0x65df7030> (a > org.apache.commons.dbcp.PoolableConnectionFactory) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771) > at > org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) > at java.sql.DriverManager.getConnection(DriverManager.java:525) > - locked <0x698c2b48> (a java.lang.Class) > at java.sql.DriverManager.getConnection(DriverManager.java:193) > - locked <0x698c2b48> (a java.lang.Class) > at Deadlock.main(Deadlock.java:83) > > Found 1 deadlock. > The deadlock occurs when GenericObjectPool.addObject() calls synchronized > method > PoolableConnectionFactory.makeObject(), meanwhile static synchronized > DriverManager.getConnection() is called. makeObject() waits for the lock on > DriverManager to be released, whereas DriverManager waits for the lock on the > PoolableConnectionFactory instance to be released. > The Java program below, based on ManualPoolingDriverExample.java provided with > DBCP, duplicates the deadlock for me within several seconds of being run: > import java.sql.*; > import org.apache.commons.pool.*; > import org.apache.commons.pool.imp
Re: [csv] getting involved
Jump right in. :) I've an urge for such a thing to exist here, but after changing jobs a while back my itch went away. On 7/19/07, Matt Benson <[EMAIL PROTECTED]> wrote: Announcing my intent to commit in [csv]. I'll be starting small... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[ https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-44: --- Attachment: DBCP-44.patch This is an architectural problem in commons-pool. GenericObjectPool.borrowObject() is synchronized so when it needs to make a new object, that method is called within a synchronized block. Here are the stack traces of the deal lock in our case: [EMAIL PROTECTED], priority=5, in group 'main', status: 'MONITOR' blocks [EMAIL PROTECTED] waiting for [EMAIL PROTECTED] borrowObject():781, GenericObjectPool.java connect():176, PoolingDriver.java getConnection():525, DriverManager.java getConnection():140, DriverManager.java main():107, Deadlock.java [EMAIL PROTECTED] daemon, priority=5, in group 'main', status: 'MONITOR' blocks [EMAIL PROTECTED] waiting for [EMAIL PROTECTED] getConnection():138, DriverManager.java createConnection():68, DriverManagerConnectionFactory.java makeObject():329, PoolableConnectionFactory.java addObject():1059, GenericObjectPool.java ensureMinIdle():1040, GenericObjectPool.java access$100():128, GenericObjectPool.java run():1117, GenericObjectPool.java mainLoop():512, Timer.java run():462, Timer.java This is a classic two lock dead lock. The main thread acquires the locks on DriveManager then GenericObjectPool, and at the same time the timer thread attempts to acquire them in the opposite order GenericObjectPool and then DriveManger. There are really only two ways to fix this 1) guarantee locks are always acquired in the same order or 2) eliminate one of the locks. The first one is not really possible as both objects are generally publicly accessible, and the second fix will require a complex change to the GenericObjectPool code. Attached is a patch that adds the Deadlock class, which has a main method that causes the dead lock.The patch also fixes the synchronization in PoolableConnectionFactory. I also added property to TesterDriver to cause the thread to sleep in getConnection so the dead lock can be reproduced. I'm going to attempt to write a new pool using the Java5 concurrent code which doesn't call makeObject inside of a synchronized block. > [dbcp] Evictor thread in GenericObjectPool has potential for deadlock > - > > Key: DBCP-44 > URL: https://issues.apache.org/jira/browse/DBCP-44 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.1 > Environment: Operating System: All > Platform: All >Reporter: Eric Layton > Fix For: 1.3 > > Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, > testConcurrency.java > > > The GenericObjectPool Evictor thread can potentially cause a deadlock between > its connection factory and java.sql.DriverManager. The deadlock occurs when > the > Evictor thread is trying to make enough connections to bring the pool's idle > connections up to what's specified in minIdle, at the same time a connection > is > being requested through DriverManager.getConnection(). See the attached stack > trace dump: > Found one Java-level deadlock: > = > "Thread-0": > waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class), > which is held by "main" > "main": > waiting to lock monitor 0x0809aad4 (object 0x65df7030, a > org.apache.commons.dbcp.PoolableConnectionFactory), > which is held by "Thread-0" > > Java stack information for the threads listed above: > === > "Thread-0": > at java.sql.DriverManager.getConnection(DriverManager.java:158) > - waiting to lock <0x698c2b48> (a java.lang.Class) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > - locked <0x65df7030> (a > org.apache.commons.dbcp.PoolableConnectionFactory) > at > org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996) > at > org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978) > at > org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124) > at > org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090) > at java.lang.Thread.run(Thread.java:595) > "main": > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > - waiting to lock <0x65df7030> (a > org.apache.com
Re: [DBCP] Release 1.3 soon?
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says "Close and release all connections that are currently stored in the connection pool associated with our data source." Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the "pool" is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is "sorry, no way to do that." Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support "restart". This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource "immutable-once-initialized". I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/stop life-cycle methods. Currently, we are using the first getConnection () for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. We should also address DBCP-4 (by using jdk logging, since we have bumped to 1.4 level). I think it would be good to start adding some simple instrumentation in 1.3 that we could add to in subsequent releases. Having things like physical connection opens / closes, pool high water marks, waits, etc., loggable would make debuggng and performance tuning much easier. In the future, I'd like these events to be available via a listener interface, so I can write monitoring code (like an mbean). Of course working out that interface takes time, so I think we should add the logging in 1.3 and a listener in 1.4. Are there any notes on how we'd like to use util.Logging (log names, levels, etc.)? I will finish reviewing recent patches tomorrow and come up with a straw man release plan this weekend if no one beats me to it. I'll look at DBCP-44 since I think it is an easy small fix. Then the close() issue and finally logging, unless someone beats me to them. BTW, it is getting challenging to write new patches with the current patches I have out. I have been trying to keep patches so there aren't file overlaps. I may need to start putting ordering information into the patches like apply after DBCP-1234. Thanks for all of your help on this, Dain. No prob. This code is like programming crack for me Small tasks for a big programming high :) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] JIRAs [was: Release 1.3 soon?]
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: Here are some open JIRAs I think we can close: Fixed: DBCP-194 BasicDataSource.setLogWriter should not do createDataSource DBCP-102 setReadOnly & setAutoCommit called too many times DBCP-97 setAutoCommit(true) when returning connection to the pool DBCP-212 PoolingDataSource closes physical connections +1 and thanks for verifying 97. Invalid: DBCP-209 Is DataSource.getConnection(user, pass) working the way it is suppose to? User should be using either SharedPoolDataSource or the PerUserPoolDataSource. DBCP-53 commons dbcp does not supports Firebird DB Torque bug or misconfiguration by user. +1 Won't fix DBCP-115 allow to set >= 6 parameters to do non-global SSL Request for mysql specific feature DBCP-152 add a socketFactory attribute to BasicDataSource (to allow SSL "thread"-safe) Request for mysql specific feature +1 If you grant me DBCP JIRA karma, I can make these changes myself. I'm a JIRA admin, so you just need to grant me karma here (email) and I can add the permission to JIRA myself. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL "thread"-safe)
[ https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514273 ] Dain Sundstrom commented on DBCP-152: - Ralf, Security is a very important issue for me, so I'm not saying that I don't want to support security features or that I don't want anyone to implement security fixes. You are requesting that we add a socketFactory factory property to DBCP, which is about 7 lines of code. The problem is once we add this property, we have no standard way to pass this information to the JDBC driver. One option, as you have suggested, is to add the socketFactory property to the properties object passed to driver.connect(url, properties). If that is your ultimate goal, we already have a mechanism in DBCP to pass properties to the connection factory addConnectionProperty(name, value). Additionally, since there is no standard for this property, it is likely that any vendor that supported the property chose a different name (e.g., socketFactoryName, sockteFactoryClass, etc.). There are other databases that pass this type of connection security information via the JDBC connect URL, which makes since since the security properties apply to all connections and not just a single connection. Unfortunately, there is no standard way to encode properties into a JDBC connect URL. Fortunately, we have a standard set the connect URL setUrl(url). To reiterate, security is very important to me, and if there were a standard way to support this type of configuration, I would submit a patch. In this specific case, I think there is any way to support your request without it being vendor specific, and I do not want to see DBCP expanded with vendor specific extensions. I suggest that you make a request for enhancement with the JDBC expert group (http://jcp.org/en/jsr/detail?id=221), and if they approve security enhancements, we will support them. > [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL > "thread"-safe) > > > Key: DBCP-152 > URL: https://issues.apache.org/jira/browse/DBCP-152 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.2 > Environment: Operating System: All > Platform: Other >Reporter: Ralf Hauser >Priority: Minor > Fix For: 1.3 > > > An app that accesses 2 datasources at two different places with different > security policies via SSL (different set of permitted ciphers) currently is > out > of luck (http://lists.mysql.com/java/8689). > The basic datasource should be enhanced with > > String socketFactory = ""; > and the corresponding getter and setter method, etc. > org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then > hand-over this full className via its Properties argument to enable different > SSL policies per datasource (so, since the application programmer doesn't have > the thread under her control, I guess it should rather be called > "dataSource-safe"). > The jdbc driver implementation can then use this to take the appropriate > socket > factory when creating a connection. > See also http://lists.mysql.com/java/8695 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r558040 - /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java
Author: ozeigermann
Date: Fri Jul 20 09:20:20 2007
New Revision: 558040
URL: http://svn.apache.org/viewvc?view=rev&rev=558040
Log:
New to manager hierarchical locking as required by file resource manager.
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java?view=auto&rev=558040
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/HierarchicalLockManager.java
Fri Jul 20 09:20:20 2007
@@ -0,0 +1,7 @@
+package org.apache.commons.transaction.locking;
+
+
+// Takes care of hierarchical locking with folders and resources
+public class HierarchicalLockManager extends ReadWriteLockManager {
+
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r558038 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking: GenericLockManager.java LockException.java ReadWriteLockManager.jav
Author: ozeigermann
Date: Fri Jul 20 09:19:46 2007
New Revision: 558038
URL: http://svn.apache.org/viewvc?view=rev&rev=558038
Log:
Preparation for deadlock detection
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/LockException.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/ReadWriteLockManager.java
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/GenericLockManager.java?view=diff&rev=558038&r1=558037&r2=558038
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
Fri Jul 20 09:19:46 2007
@@ -1,44 +1,47 @@
package org.apache.commons.transaction.locking;
+import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
public abstract class GenericLockManager implements LockManager {
-
-protected final ConcurrentHashMap globalLocks = new
ConcurrentHashMap();
-protected final ConcurrentHashMap globalOwners = new
ConcurrentHashMap();
+
+protected ConcurrentHashMap locks = new ConcurrentHashMap();
+
+protected Map> threads = new ConcurrentHashMap>();
@Override
public L get(K key) {
-return globalLocks.get(key);
+return locks.get(key);
}
-
+
@Override
public L putIfAbsent(K key, L lock) {
L existingLock = get(key);
if (existingLock == null) {
-L concurrentlyInsertedLock = globalLocks.putIfAbsent(key, lock);
+L concurrentlyInsertedLock = locks.putIfAbsent(key, lock);
if (concurrentlyInsertedLock != null)
lock = concurrentlyInsertedLock;
}
return lock;
-
+
}
-
+
@Override
public L remove(K key) {
-return globalLocks.remove(key);
+return locks.remove(key);
}
+@Override
public Iterable getAll() {
-return globalLocks.values();
+return locks.values();
}
-// FIXME
-public Set getAllForCurrentThread() {
-// TODO Auto-generated method stub
-return null;
+@Override
+public Iterable getAllForCurrentThread() {
+return threads.get(Thread.currentThread());
}
+public abstract L create();
}
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/LockException.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/LockException.java?view=diff&rev=558038&r1=558037&r2=558038
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/LockException.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/LockException.java
Fri Jul 20 09:19:46 2007
@@ -87,6 +87,11 @@
super(cause);
}
+public LockException(Throwable cause, Code code) {
+super(cause);
+this.code = code;
+}
+
/**
* Returns the formal reason for the exception.
*
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/ReadWriteLockManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/ReadWriteLockManager.java?view=diff&rev=558038&r1=558037&r2=558038
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/ReadWriteLockManager.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/ReadWriteLockManager.java
Fri Jul 20 09:19:46 2007
@@ -1,16 +1,136 @@
package org.apache.commons.transaction.locking;
+import java.util.Collection;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentSkipListSet;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.locks.Condition;
+import java.util.conc
svn commit: r558035 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking: IntrinsicLockManager.java NativeLockManager.java
Author: ozeigermann
Date: Fri Jul 20 09:16:44 2007
New Revision: 558035
URL: http://svn.apache.org/viewvc?view=rev&rev=558035
Log:
Renamed Native- to IntrinsicLockManager
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/IntrinsicLockManager.java
- copied, changed from r556343,
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/NativeLockManager.java
Removed:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/NativeLockManager.java
Copied:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/IntrinsicLockManager.java
(from r556343,
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/NativeLockManager.java)
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/IntrinsicLockManager.java?view=diff&rev=558035&p1=jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/NativeLockManager.java&r1=556343&p2=jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/IntrinsicLockManager.java&r2=558035
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/NativeLockManager.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/locking/IntrinsicLockManager.java
Fri Jul 20 09:16:44 2007
@@ -1,8 +1,9 @@
package org.apache.commons.transaction.locking;
-public class NativeLockManager extends GenericLockManager
implements LockManager {
+public class IntrinsicLockManager extends GenericLockManager
implements LockManager {
+@Override
public Object create() {
return new Object();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r558034 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file: FileResourceManager.java TxFileResourceManager.java
Author: ozeigermann
Date: Fri Jul 20 09:15:31 2007
New Revision: 558034
URL: http://svn.apache.org/viewvc?view=rev&rev=558034
Log:
Adapted to new resource package. File manager still lacks implementation.
Removed:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/TxFileResourceManager.java
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/TxFileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/TxFileResourceManager.java?view=diff&rev=558034&r1=558033&r2=558034
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/TxFileResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/file/TxFileResourceManager.java
Fri Jul 20 09:15:31 2007
@@ -32,11 +32,13 @@
import org.apache.commons.transaction.TransactionalResourceManager;
import
org.apache.commons.transaction.AbstractTransactionalResourceManager.AbstractTxContext;
import org.apache.commons.transaction.locking.LockException;
+import org.apache.commons.transaction.resource.ResourceManager;
+import org.apache.commons.transaction.resource.StreamableResource;
import org.apache.commons.transaction.util.FileHelper;
public class TxFileResourceManager extends
AbstractTransactionalResourceManager
implements
-FileResourceManager {
+ResourceManager {
private Log logger = LogFactory.getLog(getClass());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r558028 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction: AbstractTransactionalResourceManager.java TransactionalResourceManager.java
Author: ozeigermann
Date: Fri Jul 20 09:09:17 2007
New Revision: 558028
URL: http://svn.apache.org/viewvc?view=rev&rev=558028
Log:
Removed suspend/resume code as this is not applicable to our implementation.
Might be reintroduced by an XA implementation later.
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/TransactionalResourceManager.java
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/AbstractTransactionalResourceManager.java
Modified:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/AbstractTransactionalResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/AbstractTransactionalResourceManager.java?view=diff&rev=558028&r1=558027&r2=558028
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/AbstractTransactionalResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/AbstractTransactionalResourceManager.java
Fri Jul 20 09:09:17 2007
@@ -16,8 +16,6 @@
*/
package org.apache.commons.transaction;
-import java.util.HashSet;
-import java.util.Set;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReadWriteLock;
@@ -27,7 +25,7 @@
/**
* Not thread-safe. FIXME: Should it be?
- *
+ *
* @author olli
*
* @param
@@ -35,10 +33,6 @@
public abstract class AbstractTransactionalResourceManager implements
TransactionalResourceManager {
protected ThreadLocal activeTx = new ThreadLocal();
-protected Set activeTransactions = new HashSet();
-
-protected Set suspendedTransactions = new HashSet();
-
protected abstract T createContext();
/**
@@ -64,67 +58,6 @@
return (txContext.isMarkedForRollback());
}
-/**
- * Suspends the transaction associated to the current thread. I.e. the
- * associated between the current thread and the transaction is deleted.
- * This is useful when you want to continue the transaction in another
- * thread later. Call [EMAIL PROTECTED] #resumeTransaction(TxContext)} -
possibly in
- * another thread than the current - to resume work on the transaction.
- *
- * Caution: When calling this method the returned identifier for
- * the transaction is the only remaining reference to the transaction, so
be
- * sure to remember it or the transaction will be eventually deleted (and
- * thereby rolled back) as garbage.
- *
- * @return an identifier for the suspended transaction, will be needed to
- * later resume the transaction by
- * [EMAIL PROTECTED] #resumeTransaction(TxContext)}
- *
- * @see #resumeTransaction(TxContext)
- */
-public T suspendTransaction() {
-T txContext = getActiveTx();
-
-if (txContext == null) {
-throw new IllegalStateException("Active thread " +
Thread.currentThread()
-+ " not associated with a transaction!");
-}
-
-suspendedTransactions.add(txContext);
-setActiveTx(null);
-return txContext;
-}
-
-/**
- * Resumes a transaction in the current thread that has previously been
- * suspened by [EMAIL PROTECTED] #suspendTransaction()}.
- *
- * @param suspendedTx
- *the identifier for the transaction to be resumed, delivered
by
- *[EMAIL PROTECTED] #suspendTransaction()}
- *
- * @see #suspendTransaction()
- */
-public void resumeTransaction(T suspendedTx) {
-T txContext = getActiveTx();
-
-if (txContext != null) {
-throw new IllegalStateException("Active thread " +
Thread.currentThread()
-+ " already associated with a transaction!");
-}
-
-if (suspendedTx == null) {
-throw new IllegalStateException("No transaction to resume!");
-}
-
-if (!suspendedTransactions.contains(suspendedTx)) {
-throw new IllegalStateException("Transaction to resume needs to be
suspended!");
-}
-
-suspendedTransactions.remove(txContext);
-setActiveTx(suspendedTx);
-}
-
@Override
public void startTransaction() {
if (getActiveTx() != null) {
@@ -133,7 +66,6 @@
}
T txContent = createContext();
setActiveTx(txContent);
-activeTransactions.add(txContent);
}
@@ -148,7 +80,6 @@
txContext.dispose();
setActiveTx(null);
-activeTransactions.remove(txContext);
}
@Override
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transa
svn commit: r558033 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource: ./ ResourceEvent.java ResourceInterceptor.java ResourceManager.jav
Author: ozeigermann
Date: Fri Jul 20 09:14:53 2007
New Revision: 558033
URL: http://svn.apache.org/viewvc?view=rev&rev=558033
Log:
New package for streamable resources. Will be implemented by transactional file
resource manager. Could also offer access to content from a CMS.
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceEvent.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceInterceptor.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceManager.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/StreamableResource.java
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceEvent.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceEvent.java?view=auto&rev=558033
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceEvent.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceEvent.java
Fri Jul 20 09:14:53 2007
@@ -0,0 +1,13 @@
+package org.apache.commons.transaction.resource;
+
+public interface ResourceEvent {
+enum EventType {
+ACCESS, READ, CREATE, DELETE, WRITE, MOVE, COPY, COMMIT, ROLLBACK,
PROPERTYSET
+};
+
+String getPath();
+String getDestinationPath();
+String propertyName();
+
+EventType getEventType();
+}
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceInterceptor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceInterceptor.java?view=auto&rev=558033
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceInterceptor.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceInterceptor.java
Fri Jul 20 09:14:53 2007
@@ -0,0 +1,7 @@
+package org.apache.commons.transaction.resource;
+
+
+public interface ResourceInterceptor {
+boolean beforeCompletion(ResourceEvent event);
+void afterCompletion(ResourceEvent event);
+}
\ No newline at end of file
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceManager.java?view=auto&rev=558033
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceManager.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/ResourceManager.java
Fri Jul 20 09:14:53 2007
@@ -0,0 +1,15 @@
+package org.apache.commons.transaction.resource;
+
+import java.io.IOException;
+
+import org.apache.commons.transaction.locking.LockException;
+
+public interface ResourceManager {
+R getResource(String path) throws IOException, LockException;
+
+String getRootPath() throws IOException, LockException;
+
+void addInterceptor(ResourceInterceptor interceptor);
+
+void removeInterceptor(ResourceInterceptor interceptor);
+}
\ No newline at end of file
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/StreamableResource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/StreamableResource.java?view=auto&rev=558033
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/StreamableResource.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/resource/StreamableResource.java
Fri Jul 20 09:14:53 2007
@@ -0,0 +1,51 @@
+package org.apache.commons.transaction.resource;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+impo
svn commit: r558031 - in /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory: ./ OptimisticTxMap.java PessimisticTxMap.java TxMap.java
Author: ozeigermann
Date: Fri Jul 20 09:13:20 2007
New Revision: 558031
URL: http://svn.apache.org/viewvc?view=rev&rev=558031
Log:
Reintroduces transactional memory implementations. However, they no longer wrap
a map, but hide the wrapped map as an implementation detail.
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/OptimisticTxMap.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/PessimisticTxMap.java
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/TxMap.java
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/OptimisticTxMap.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/OptimisticTxMap.java?view=auto&rev=558031
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/OptimisticTxMap.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/memory/OptimisticTxMap.java
Fri Jul 20 09:13:20 2007
@@ -0,0 +1,340 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.transaction.memory;
+
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.locks.ReadWriteLock;
+import java.util.concurrent.locks.ReentrantReadWriteLock;
+
+import org.apache.commons.transaction.TransactionalResourceManager;
+import org.apache.commons.transaction.locking.LockException;
+
+/**
+ * Wrapper that adds transactional control to all kinds of maps that implement
+ * the [EMAIL PROTECTED] Map} interface. By using a naive optimistic
transaction control
+ * this wrapper has better isolation than [EMAIL PROTECTED] TxMap}, but
+ * may also fail to commit.
+ *
+ *
+ * Start a transaction by calling [EMAIL PROTECTED] #startTransaction()}. Then
perform the
+ * normal actions on the map and finally either call
+ * [EMAIL PROTECTED] #commitTransaction()} to make your changes permanent or
+ * [EMAIL PROTECTED] #rollbackTransaction()} to undo them.
+ * Caution: Do not modify values retrieved by [EMAIL PROTECTED]
#get(Object)} as
+ * this will circumvent the transactional mechanism. Rather clone the value or
+ * copy it in a way you see fit and store it back using
+ * [EMAIL PROTECTED] #put(Object, Object)}.
+ * Note: This wrapper guarantees isolation level
+ * SERIALIZABLE.
+ * Caution: This implementation might be slow when large amounts of
+ * data is changed in a transaction as much references will need to be copied
+ * around.
+ *
+ * @version $Id: OptimisticMapWrapper.java 493628 2007-01-07 01:42:48Z joerg $
+ * @see TxMap
+ * @see PessimisticTxMap
+ */
+public class OptimisticTxMap extends TxMap implements Map,
+TransactionalResourceManager {
+
+private Set activeTransactions = new
HashSet();
+private ReadWriteLock commitLock = new ReentrantReadWriteLock();
+
+private long commitTimeout = 1000 * 60; // 1 minute
+
+private long accessTimeout = 1000 * 30; // 30 seconds
+public void rollbackTransaction() {
+MapTxContext txContext = getActiveTx();
+super.rollbackTransaction();
+activeTransactions.remove(txContext);
+}
+
+public void commitTransaction() throws LockException {
+commitTransaction(false);
+}
+
+public void commitTransaction(boolean force) throws LockException {
+MapTxContext txContext = getActiveTx();
+
+if (txContext == null) {
+throw new IllegalStateException(
+"Active thread " + Thread.currentThread() + " not associated
with a transaction!");
+}
+
+if (txContext.isMarkedForRollback()) {
+throw new IllegalS
svn commit: r558030 - /jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java
Author: ozeigermann
Date: Fri Jul 20 09:10:30 2007
New Revision: 558030
URL: http://svn.apache.org/viewvc?view=rev&rev=558030
Log:
Base interface for a transaction including more than one resource manager. 2PC
is not intended.
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java
Added:
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java?view=auto&rev=558030
==
---
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java
(added)
+++
jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/Transaction.java
Fri Jul 20 09:10:30 2007
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.transaction;
+
+public interface Transaction {
+public void setTransactionTimeout(long mSecs);
+
+public void start();
+
+void setRollbackOnly();
+
+boolean isRollbackOnly();
+
+public void rollback();
+
+public void commit();
+
+boolean enlistResourceManager(TransactionalResourceManager
resourceManager);
+
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Missing check for UNKNOWN
Hi all,
I got a ParserInitializationException from FtpClient.listFiles().
After some debugging, I found that the cause was the ftp server
returning "UNKNOWN Type: L8" as the system type (instead of something
like "UNIX Type L8").
The fix, it seems, is to add a check for "UNKNOWN" in
DefaultFTPFileEntryParserFactory.createFileEntryParser(key):
For example:
if (ukey.indexOf(FTPClientConfig.SYST_UNIX) >= 0
|| ukey.indexOf("UNKNOWN") >= 0) // XXX this fixes it
Is this fix reasonable? Is it a known bug? Is there a version of commons-net
that contains this fix?
Thanks,
Allan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TRANSACTION-16) TX collections / TX object model
Hi, Dennis! No need to subscribe to the dev list. We can handle the issue over JIRA: https://issues.apache.org/jira/browse/TRANSACTION-16 Just add comments there. The code that I am referring to is in SVN in the TRANSACTION_2 branch. You can just use this link as a starting point: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/ Note that this is work in progress and subject to many, many changes. OK. I would be more than glad to see you invest some time into this after your vavation :) Cheers Oliver 2007/7/15, Dennis Thrysøe <[EMAIL PROTECTED]>: Oliver Zeigermann (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/TRANSACTION-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512556 > ] > > Oliver Zeigermann commented on TRANSACTION-16: > -- > > I have now tried to set up new landmarks for commons transaction 2.0. > All Java 5 features, including Generics and the concurrent package > are allowed now. > > Dennis, could you try and see where your work could fit in? > Especially, considering the new "internal" TransactionManager, > LockManager and LockPolicy. > > Does this make sense to you in the first place? Hi, Note that I am not on the mailing list for the time being. Too much traffic, and not much of relavance to me. I am unsure where I can read about the stuff you are referring to above. The wiki contains some notes from the 27th of june on version 2.0 - is that it? Therefore I'm not sure about the internal mechanisms you refer to. But, 1) Regarding locking, I'm hoping to implement MVCC support to avoid locking per se. Otherwise I would probably make much sense to use the already existing locking functionality in my implementations. 2) If you mean a TransactionManager as the term is used in JTA, I haven't implemented such a beast. I have a dummy/mock for testing purposes, that's all. Besides from the above I was considering moving all of my implementations into a single unified one for all kinds of objects. Since the "transactional object model" is based on recording method invocations, it could just as well be used for collections etc. The "depth" of recorded invocations could be declarable (for instance so only interface-method-invocations are recorded for collections. The problem with this is that any optimizations possible from the knowledge of the interface in question, are lost. If Java 6 and "our" dedicated class loader (or compile-time enhancing) could be assumed, the implementation could go to the ultimate level of transparancy with bytecode instrumentation that intercepts all field reads and writes. A whole area that I haven't put much thought into yet is distribution. I guess it's really a separate concern from isolation and transaction protection though. I'm on vacation these couple of weeks, but I'll see if I can put a bit of effort into this afterwards. -dennis --- The information in this email is confidential and may be legally protected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction 2.0] stripping to its very core
Sounds like a good idea. Could you set up such a project structure? The main problem with xa is that we can not suspend/resume with given the current implementation that relies on ReentrantReadWriteLock. Reason is that you can not transfer locks from one thread to another. I will investigate if this can be changed easily. For the time being I will add a new flavor of tx maps as I am no longer sure that there really is no use case for them. Oliver 2007/7/20, Joerg Heinicke <[EMAIL PROTECTED]>: Oliver Zeigermann zeigermann.de> writes: > I am proposing to strip Commons Transaction to its very core. > Deleted: > - no more XA classes: We really can not an implement an XA resource > with the existing implementation Hi Oliver, reducing ctx to a core is a good idea. I only would not like to see the XA stuff been dropped completely. I think it's quite important for getting ctx "sold". I have a second project in maven 2 sense in mind as commons jci does: http://marc.info/?l=jakarta-commons-dev&m=117571327222719&w=4. So we would have commons-transaction.jar and a commons-transaction-xa.jar. WDYT? Joerg - 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]
[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514215 ] Oliver Zeigermann commented on TRANSACTION-9: - Locking === I agree to what Peter says about locking of files/folders and locking in general. What about a HierarchicalLockManager that takes care of all that stuff for us? Might even be reuseable. I will add an empty impementation for us to remember to later fill it. Interfaces I will add the interfaces to the SVN soon. Let us base further discussions on what is in SVN from then on. That might make things a bit easier. I will also propose a simple interceptor (instead of listener) concept that is "inspired" by how it works in XA and Spring MVC. Concerning Jörg's comments: 1. setProperty() is supposed to return the old value, but maybe that does not make that much sense? WDYT? 2. append has been added to writeStream() 3. the filter thing sounds interesting: Do you have code for that? 4. I have no really elegant solution to the create-Problem. Distinguishing between FileResource and DirectoryResource introduces many problems, some of them requiring excessive casting. I have been there before. Currently I favor the createAsFile/Directory() solution. > [transaction] Add full file management capabilities to the FileResourceManager > -- > > Key: TRANSACTION-9 > URL: https://issues.apache.org/jira/browse/TRANSACTION-9 > Project: Commons Transaction > Issue Type: Improvement > Environment: Operating System: All > Platform: All >Reporter: Peter Fassev >Assignee: Oliver Zeigermann >Priority: Minor > Fix For: 2.0 > > Attachments: filemanager.zip > > > Hi, > As stated in the doc the FileResourceManager is: > "A resource manager for streamable objects stored in a file system" > I agree, that this is a resource manager, but it could be easily extended, to > support a full file management system. It will be very helpful to have > additional methods like renameResource(), getResourceSize(), > getResourceTime(), > setResourceTime() etc. This are common file operations, which should be > managed > by the FileResourceManager. > Further it will be very helpful to have (real) support for resource > collections > (folders). It will be necessary to distinguish between single resources > (files) > and collections (folders). > Together, this features will enable a transactional access to any file based > resources - for instance a document repository. > Are there plans for such extensions and if not, will they actually fit in the > goals of the transaction library? > If not, please open the underlying structure, like the inner class > TransactionContext, in order to add extensions the file management. For > instance, it will be good to have a separate factory method, which creates > the > context. > If you are interested in this proposal, I am ready to contribute to this > project. I consider myself as an experienced java developer and I will be > glad > to help you. > Best regards > Peter Fassev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (NET-164) WhoisClient should not use the platform's default Encoding
[ https://issues.apache.org/jira/browse/NET-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulrich Mayring updated NET-164: --- Attachment: FingerClient.java FingerClient can now accept encoding as additional parameter. Old method calls new method with encoding parameter null, so old behavior remains unchanged. > WhoisClient should not use the platform's default Encoding > -- > > Key: NET-164 > URL: https://issues.apache.org/jira/browse/NET-164 > Project: Commons Net > Issue Type: Improvement >Reporter: Ulrich Mayring > Attachments: FingerClient.java > > > Currently the WhoisClient is extending the FingerClient, which sends its > request like so: > output = new DataOutputStream(new BufferedOutputStream(_output_, 1024)); > output.writeBytes(__query.toString()); > This obviously uses the platform's default encoding, which may be workable > for Finger requests, but today's Whois services oftentimes support foreign > characters via some IDN scheme and therefore usually run under utf-8. It > should therefore either be configurable which encoding is used for the > request, or, alternatively, the query interface should be changed to not > accept strings, but only bytes. Then it's the client's responsibility to do > the appropriate thing. > As it is now, there is no way to use this WhoisClient for IDN-aware Whois > registries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (DBCP-53) 'not supported' error given against Firebird DB
I've moved this issue over to the Torque JIRA project, rather than closing and asking the user to open one there. Hen On 7/20/07, Henri Yandell (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-53: -- Summary: 'not supported' error given against Firebird DB (was: [dbcp] commons dbcp does not supports Firebird DB.) > 'not supported' error given against Firebird DB > --- > > Key: DBCP-53 > URL: https://issues.apache.org/jira/browse/DBCP-53 > Project: Commons Dbcp > Issue Type: Bug > Environment: Operating System: Windows XP > Platform: PC >Reporter: DMoL > Fix For: 1.3 > > > I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple example > not works. Here is the log output: > 15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory > setProperty > SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported > by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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]
[jira] Updated: (DBCP-53) 'not supported' error given against Firebird DB
[ https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-53: -- Summary: 'not supported' error given against Firebird DB (was: [dbcp] commons dbcp does not supports Firebird DB.) > 'not supported' error given against Firebird DB > --- > > Key: DBCP-53 > URL: https://issues.apache.org/jira/browse/DBCP-53 > Project: Commons Dbcp > Issue Type: Bug > Environment: Operating System: Windows XP > Platform: PC >Reporter: DMoL > Fix For: 1.3 > > > I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple > example > not works. Here is the log output: > 15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory > setProperty > SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported > by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (NET-165) FTP: using "stat" to retrieve dirlisting over control connection
FTP: using "stat" to retrieve dirlisting over control connection
Key: NET-165
URL: https://issues.apache.org/jira/browse/NET-165
Project: Commons Net
Issue Type: Wish
Reporter: Stefan Tauner
Priority: Minor
dirlisting over a data connection with "list" is usually quite slow in
comparision with "stat" because the latter doesnt need to set up a data
connection but gets all data back through the control connection.
the behaviour is defined in rfc 959 (_the_ ftp rfc) on page 33 ("STATUS
(STAT)").
i am new to commons net, so i am not sure whats the best way to implement this,
but i think an option to turn the existing FTPClient.listFiles() methods into
using stat instead of list would be the best option. that way it would not
break any existing code and the upgrade would be easy too...
i am not sure how many server implementations are actually supporting this, but
mine does and since it would be optional (and non default) behaviour, i dont
think thats a problem anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514170 ] Peter Fassev commented on TRANSACTION-9: Regarding the JCR (Java Content Repository), I don't think we are doing the same thing. Here is the short description from the JCP 170 Site: "A Content Repository is a high-level information management system that is a superset of traditional data repositories. A content repository implements "content services" such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. It is these "content services" that differentiate a Content Repository from a Data Repository." The JCP is about content, and not just about transactional file system access. The file access may be a part of such system, but I think there are also other application areas. For instance, I don't like the Idea of saving and retrieving 2 GByte files in RDBS - I would prefer to manage them as pure files. > [transaction] Add full file management capabilities to the FileResourceManager > -- > > Key: TRANSACTION-9 > URL: https://issues.apache.org/jira/browse/TRANSACTION-9 > Project: Commons Transaction > Issue Type: Improvement > Environment: Operating System: All > Platform: All >Reporter: Peter Fassev >Assignee: Oliver Zeigermann >Priority: Minor > Fix For: 2.0 > > Attachments: filemanager.zip > > > Hi, > As stated in the doc the FileResourceManager is: > "A resource manager for streamable objects stored in a file system" > I agree, that this is a resource manager, but it could be easily extended, to > support a full file management system. It will be very helpful to have > additional methods like renameResource(), getResourceSize(), > getResourceTime(), > setResourceTime() etc. This are common file operations, which should be > managed > by the FileResourceManager. > Further it will be very helpful to have (real) support for resource > collections > (folders). It will be necessary to distinguish between single resources > (files) > and collections (folders). > Together, this features will enable a transactional access to any file based > resources - for instance a document repository. > Are there plans for such extensions and if not, will they actually fit in the > goals of the transaction library? > If not, please open the underlying structure, like the inner class > TransactionContext, in order to add extensions the file management. For > instance, it will be good to have a separate factory method, which creates > the > context. > If you are interested in this proposal, I am ready to contribute to this > project. I consider myself as an experienced java developer and I will be > glad > to help you. > Best regards > Peter Fassev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-20072007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/junit/dist/junit-20072007.jar:/srv/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/srv/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependencies: dom4j-1.4.jar commons-jelly-1.0-RC1.jar commons-jelly-tags-jsl-1.0.jar commons-jelly-tags-log-1.0.jar commons-jelly-tags-velocity-1.0.jar commons-jelly-tags-xml-1.1.jar (try downloading from http://jakarta.apache.org/commons/jelly/libs/xml/) maven-1.0.2.jar maven-model-3.0.0.jar velocity-1.4.jar commons-jelly-tags-fmt-1.0.jar Total time: 2 seconds Finished at: Fri Jul 20 01:33:34 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0820072007, vmgump:vmgump-public:0820072007 Gump E-mail Identifier (unique within run) #42. -- 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-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-20072007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20072007.jar:/srv/gump/public/workspace/junit/dist/junit-20072007.jar:/srv/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/srv/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependencies: dom4j-1.4.jar commons-jelly-1.0-RC1.jar commons-jelly-tags-jsl-1.0.jar commons-jelly-tags-log-1.0.jar commons-jelly-tags-velocity-1.0.jar commons-jelly-tags-xml-1.1.jar (try downloading from http://jakarta.apache.org/commons/jelly/libs/xml/) maven-1.0.2.jar maven-model-3.0.0.jar velocity-1.4.jar commons-jelly-tags-fmt-1.0.jar Total time: 2 seconds Finished at: Fri Jul 20 01:33:34 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0820072007, vmgump:vmgump-public:0820072007 Gump E-mail Identifier (unique within run) #42. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r557936 - /jakarta/commons/proper/beanutils/trunk/build.xml
Author: niallp Date: Fri Jul 20 02:29:37 2007 New Revision: 557936 URL: http://svn.apache.org/viewvc?view=rev&rev=557936 Log: Fix ant build (conf directory has been zapped) Modified: jakarta/commons/proper/beanutils/trunk/build.xml Modified: jakarta/commons/proper/beanutils/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/build.xml?view=diff&rev=557936&r1=557935&r2=557936 == --- jakarta/commons/proper/beanutils/trunk/build.xml (original) +++ jakarta/commons/proper/beanutils/trunk/build.xml Fri Jul 20 02:29:37 2007 @@ -49,9 +49,6 @@ - - - @@ -134,19 +131,11 @@ - - - - - - - -
[EMAIL PROTECTED]: Project commons-beanutils (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-beanutils has an issue affecting its community integration. This issue affects 114 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-embed-optional : Java based build tool - authx-example : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-beanutils : Bean Utilities - commons-betwixt : Commons Betwixt Package - commons-chain : GoF "Chain of Responsibility" pattern - commons-configuration : Jakarta commons - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-fileupload : Commons File Upload Package - commons-javaflow : Commons Javaflow - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-services : Basic Services Architecture - commons-validator : Validation Framework - db-ddlutils : Easy-to-use component for working with Database Definition (... - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - eyebrowse : Web-based mail archive browsing - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - fulcrum-upload : Services Framework - htmlunit : A tool for testing web based applications - invicta : Open-source build management tool. - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - 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-12 : Cactus Servlet Sample (J2EE 1.2) - j
[EMAIL PROTECTED]: Project commons-beanutils (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-beanutils has an issue affecting its community integration. This issue affects 114 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-embed-optional : Java based build tool - authx-example : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-beanutils : Bean Utilities - commons-betwixt : Commons Betwixt Package - commons-chain : GoF "Chain of Responsibility" pattern - commons-configuration : Jakarta commons - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-fileupload : Commons File Upload Package - commons-javaflow : Commons Javaflow - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-services : Basic Services Architecture - commons-validator : Validation Framework - db-ddlutils : Easy-to-use component for working with Database Definition (... - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - eyebrowse : Web-based mail archive browsing - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - fulcrum-upload : Services Framework - htmlunit : A tool for testing web based applications - invicta : Open-source build management tool. - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - 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-12 : Cactus Servlet Sample (J2EE 1.2) - j
[jira] Created: (NET-164) WhoisClient should not use the platform's default Encoding
WhoisClient should not use the platform's default Encoding -- Key: NET-164 URL: https://issues.apache.org/jira/browse/NET-164 Project: Commons Net Issue Type: Improvement Reporter: Ulrich Mayring Currently the WhoisClient is extending the FingerClient, which sends its request like so: output = new DataOutputStream(new BufferedOutputStream(_output_, 1024)); output.writeBytes(__query.toString()); This obviously uses the platform's default encoding, which may be workable for Finger requests, but today's Whois services oftentimes support foreign characters via some IDN scheme and therefore usually run under utf-8. It should therefore either be configurable which encoding is used for the request, or, alternatively, the query interface should be changed to not accept strings, but only bytes. Then it's the client's responsibility to do the appropriate thing. As it is now, there is no way to use this WhoisClient for IDN-aware Whois registries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL "thread"-safe)
[ https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514130 ] Ralf Hauser commented on DBCP-152: -- Allowing for a non-global SSL socket factory has nothing to do with mysql. Even if JDBC as a standard has not arrived there yet in their thinking, it it is relatively easy why not adding a concept that can support good security without jdbc. Socket security after all may well be considered as an orthogonal issue to both JDBC and RDBMs behind them. Anyway, just because you personally don't have the time to contribute that (and neither do I for now unfortunately :( ), I think it is a lame approach to resolve enhancement requests as "won't fix" since there may be someone else who has the time to do so. see also DBCP-155 > [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL > "thread"-safe) > > > Key: DBCP-152 > URL: https://issues.apache.org/jira/browse/DBCP-152 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.2 > Environment: Operating System: All > Platform: Other >Reporter: Ralf Hauser >Priority: Minor > Fix For: 1.3 > > > An app that accesses 2 datasources at two different places with different > security policies via SSL (different set of permitted ciphers) currently is > out > of luck (http://lists.mysql.com/java/8689). > The basic datasource should be enhanced with > > String socketFactory = ""; > and the corresponding getter and setter method, etc. > org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then > hand-over this full className via its Properties argument to enable different > SSL policies per datasource (so, since the application programmer doesn't have > the thread under her control, I guess it should rather be called > "dataSource-safe"). > The jdbc driver implementation can then use this to take the appropriate > socket > factory when creating a connection. > See also http://lists.mysql.com/java/8695 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-155) [dbcp] allow to set >= 6 parameters to do non-global SSL
[ https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514125 ] Ralf Hauser commented on DBCP-155: -- I certainly agree that you should not break the standards. However, if you can offer a structure that can operate with global system properties (a blunt standard that has definitely almost outlived itself), but also allows to support thread-safe connection factories, I don't why you shouldn't do that see also DBCP-152. > [dbcp] allow to set >= 6 parameters to do non-global SSL > > > Key: DBCP-155 > URL: https://issues.apache.org/jira/browse/DBCP-155 > Project: Commons Dbcp > Issue Type: Improvement > Environment: Operating System: All > Platform: Other >Reporter: Ralf Hauser >Priority: Minor > Fix For: 1.3 > > > to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html, > it should be possible to call DriverManager.getConnection() with properties > to replace the below 4: > -Djavax.net.ssl.keyStore=path_to_keystore_file > -Djavax.net.ssl.keyStorePassword=* > -Djavax.net.ssl.trustStore=path_to_truststore_file > -Djavax.net.ssl.trustStorePassword=* > futhermore, adding a property > - "useSSL" and > - "requireSSL" > would also help. > plus the socketFactory-Class I asked for before (COM-2747) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
