[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (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-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -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/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl] 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/beanutils/dist/commons-beanutils-core.jar:/srv/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-16072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-16072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (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-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -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/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jsl] 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/beanutils/dist/commons-beanutils-core.jar:/srv/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-16072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-16072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit]
[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, and has been outstanding for 8 runs. 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-16072007.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-core.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-16072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-16072007.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-16072007.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
[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, and has been outstanding for 8 runs. 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-16072007.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-core.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-16072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-16072007.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-16072007.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
test2
test2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test2
test2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512958 ] Jörg Heinicke commented on TRANSACTION-11: -- Yes, the two methods should definitely be added to the interface(s). I haven't had a look on the new stuff so I don't know exactly where they have to be added to. If there is a TransactionManager interface it should have the setDefaultTransactionTimeout(long) method. If there is a ResourceManager and reset() is of general use (which I'd assume if there is an implementation for FileResourceManager) reset() has to be added to that interface. Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: https://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1 Reporter: Jeremy Fujimoto-Johnson Assignee: Jörg Heinicke Fix For: 2.0 Attachments: commons-transaction-rm-patch.txt Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- 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]
Question regarding FTPClient.retrieve
I am using FTPClient class and would like to download a file from an FTP site. Here is what I am doing, but I cannot get it to download the file. Any help would be appreciated: ftp.connect(myHostname); ftp.login(myUsername, myPassword); File localFile = new File(C:\\test\\test.csv); FileOutputStream outStream = new FileOutputStream(localFile.getAbsoluteFile()); boolean result = ftp.retrieveFile(remoteFilename, outStream); ftp.disconnect(); TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp][pool] Performance / load tests
On 7/15/07, Phil Steitz [EMAIL PROTECTED] wrote: I have cleaned up some of my performance / load test code for [dbcp] and [pool] and would like to commit it somewhere so others can use and improve it. There is some common load generation code that should be factored out and I don't want to clutter the component codebases, so I am hesitant to commit to either pool or dbcp trunk. Any objections to my starting a [performance] sandbox component and seeding it with [dbcp] and [pool] performance tests? Any better ideas on where to put this code? +1 on putting it in as a component in sandbox. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513100
]
Maurice Codik Moscoso commented on FILEUPLOAD-136:
--
I'm seeing this issue as well-- threads taking up 100% of CPU spinning in a
loop, with jstack showing that same stack trace.
is there any indication that this is a fileupload bug? its possible that its
Jetty's fault... especially with the last few lines in that stack trace being
in Jetty code.
FileUpload race condition with used with Jetty 6
Key: FILEUPLOAD-136
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Environment: Running on Windows XP SP2 with Jetty 6 embedded and
Firefox 2.0.0.4
Reporter: Keith Kowalczykowski
Priority: Critical
Attachments: FileUploadTest.zip
When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
spins and never returns when the user clicks the stop button in their
browser while an upload is in progress.
Reproduction Steps:
* Create a simple servlet / html form which accepts a file upload using
commons file upload (or use the example code below).
* Upload a sufficiently large file that you have time to click the stop
button before the upload completes.
* Observe that the thread is now stuck within file upload.
Other Information:
Using jstack, I was able to get the following trace of where it is blocking.
It looks like it is on a read() call that file upload is making.
at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
at
org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
at
org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at test/Main$1.handle(Main.java:43)
at
org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
at org/mortbay/jetty/Server.handle(Server.java:285)
at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
at
org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
at
org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
at
org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
at jrockit/vm/RNI.c2java()V(Native Method)
-- end of trac
Originally I thought this was an issue with our code, however, I have since
isolated it to a simple test case. Bellow is a class file called Main which
when run will instantiate an instance of Jetty on port 8080 and an HTML
document that will post a file upload to the servlet. When the stop button is
pressed, you will see that the line Starting processing is printed, but
neither the Exception occured in processing or Processing completed are
printed. I have a full eclipse project (jars and all) on my machine that I
was planning on uploading with this ticket, however, I don't see a way to
attach a file. Therefore, I have copied and pasted the two files bellow. Let
me know if you want the full project.
=== Main.java ===
/**
*
*/
package test;
import java.io.IOException;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* @author Keith Kowalczykowski
*
*/
public class Main {
public static void main(String[] args) {
Handler handler = new AbstractHandler() {
public void handle(String arg0, HttpServletRequest arg1,
HttpServletResponse arg2, int arg3)
throws IOException,
ServletException
{
svn commit: r556774 - /jakarta/commons/proper/lang/trunk/xdocs/index.xml
Author: bayard Date: Mon Jul 16 17:00:42 2007 New Revision: 556774 URL: http://svn.apache.org/viewvc?view=revrev=556774 Log: Sadly the Chinese translation has followed the German translation into 404ity. Removing that link Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/index.xml?view=diffrev=556774r1=556773r2=556774 == --- jakarta/commons/proper/lang/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/index.xml Mon Jul 16 17:00:42 2007 @@ -89,7 +89,6 @@ li Oct 17, 2003 - a href=http://www.builder.com/;Builder.com/a has an article on Commons Lang v1.0 entitled a href=http://builder.com.com/article.jhtml?id=u00320021017yan01.htmamp;page=1amp;vf=tt;Jakarta Commons Lang project offers centralized utility functions/a -[and in a href=http://www.zdnet.com.cn/developer/tech/story/0,281602,39077840,00.htm;chinese/a]. /li li a href=http://ant.apache.org;Ant/a, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r556775 - /jakarta/commons/proper/lang/trunk/xdocs/index.xml
Author: bayard Date: Mon Jul 16 17:01:23 2007 New Revision: 556775 URL: http://svn.apache.org/viewvc?view=revrev=556775 Log: Builder.com indicates this was written in 2002, not 2003 Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/index.xml?view=diffrev=556775r1=556774r2=556775 == --- jakarta/commons/proper/lang/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/index.xml Mon Jul 16 17:01:23 2007 @@ -87,7 +87,7 @@ section name=Resources ul li -Oct 17, 2003 - a href=http://www.builder.com/;Builder.com/a has an article on Commons Lang v1.0 entitled +Oct 17, 2002 - a href=http://www.builder.com/;Builder.com/a has an article on Commons Lang v1.0 entitled a href=http://builder.com.com/article.jhtml?id=u00320021017yan01.htmamp;page=1amp;vf=tt;Jakarta Commons Lang project offers centralized utility functions/a /li li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513123
]
Paul Benedict commented on FILEUPLOAD-136:
--
Could it be related to this?
https://issues.apache.org/jira/browse/FILEUPLOAD-140. The ticket describes
about the socket blocking on read.
FileUpload race condition with used with Jetty 6
Key: FILEUPLOAD-136
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Environment: Running on Windows XP SP2 with Jetty 6 embedded and
Firefox 2.0.0.4
Reporter: Keith Kowalczykowski
Priority: Critical
Attachments: FileUploadTest.zip
When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
spins and never returns when the user clicks the stop button in their
browser while an upload is in progress.
Reproduction Steps:
* Create a simple servlet / html form which accepts a file upload using
commons file upload (or use the example code below).
* Upload a sufficiently large file that you have time to click the stop
button before the upload completes.
* Observe that the thread is now stuck within file upload.
Other Information:
Using jstack, I was able to get the following trace of where it is blocking.
It looks like it is on a read() call that file upload is making.
at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
at
org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
at
org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at test/Main$1.handle(Main.java:43)
at
org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
at org/mortbay/jetty/Server.handle(Server.java:285)
at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
at
org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
at
org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
at
org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
at jrockit/vm/RNI.c2java()V(Native Method)
-- end of trac
Originally I thought this was an issue with our code, however, I have since
isolated it to a simple test case. Bellow is a class file called Main which
when run will instantiate an instance of Jetty on port 8080 and an HTML
document that will post a file upload to the servlet. When the stop button is
pressed, you will see that the line Starting processing is printed, but
neither the Exception occured in processing or Processing completed are
printed. I have a full eclipse project (jars and all) on my machine that I
was planning on uploading with this ticket, however, I don't see a way to
attach a file. Therefore, I have copied and pasted the two files bellow. Let
me know if you want the full project.
=== Main.java ===
/**
*
*/
package test;
import java.io.IOException;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* @author Keith Kowalczykowski
*
*/
public class Main {
public static void main(String[] args) {
Handler handler = new AbstractHandler() {
public void handle(String arg0, HttpServletRequest arg1,
HttpServletResponse arg2, int arg3)
throws IOException,
ServletException
{
System.out.println(Starting processing);
try
{
// Create a
[jira] Commented: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[ https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513129 ] Keith Kowalczykowski commented on FILEUPLOAD-136: - is there any indication that this is a fileupload bug? its possible that its Jetty's fault... especially with the last few lines in that stack trace being in Jetty code. Maurice, I'm not sure who's fault it is. When I originally posted this issue, I took a look at the file upload code and it is quite complex, so I couldn't really figure out what was going on. They perform a lot of hard for-loops that are supposed to break out if some condition occurs, but obviously it is not occurring in this case. Therefore, I'm not sure whether the file upload code is incorrect, and they were just lucky that it worked correctly under (presumably) tomcat. Or if it truly is a bug in Jetty. I was hoping that someone here could confirm that it is a Jetty bug before passing it on to them, as I have no way to describe the problem to the jetty guys, or proof that it is even their problem. FileUpload race condition with used with Jetty 6 Key: FILEUPLOAD-136 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Environment: Running on Windows XP SP2 with Jetty 6 embedded and Firefox 2.0.0.4 Reporter: Keith Kowalczykowski Priority: Critical Attachments: FileUploadTest.zip When running commons file upload with Jetty 6, ServletFileUpload.parseRequest spins and never returns when the user clicks the stop button in their browser while an upload is in progress. Reproduction Steps: * Create a simple servlet / html form which accepts a file upload using commons file upload (or use the example code below). * Upload a sufficiently large file that you have time to click the stop button before the upload completes. * Observe that the thread is now stuck within file upload. Other Information: Using jstack, I was able to get the following trace of where it is blocking. It looks like it is on a read() call that file upload is making. at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922) at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897) at org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959) at org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910) at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119) at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64) at org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354) at org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126) at test/Main$1.handle(Main.java:43) at org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139) at org/mortbay/jetty/Server.handle(Server.java:285) at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502) at org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835) at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641) at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208) at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378) at org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226) at org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) at jrockit/vm/RNI.c2java()V(Native Method) -- end of trac Originally I thought this was an issue with our code, however, I have since isolated it to a simple test case. Bellow is a class file called Main which when run will instantiate an instance of Jetty on port 8080 and an HTML document that will post a file upload to the servlet. When the stop button is pressed, you will see that the line Starting processing is printed, but neither the Exception occured in processing or Processing completed are printed. I have a full eclipse project (jars and all) on my machine that I was planning on uploading with this ticket, however, I don't see a way to attach a file. Therefore, I have copied and pasted the two files bellow. Let me know if you want the full project. === Main.java === /** * */ package test; import java.io.IOException; import java.util.List; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.commons.fileupload.FileItem; import org.apache.commons.fileupload.disk.DiskFileItemFactory; import
[jira] Created: (DBCP-233) Allow connection, statement, and result set to be closed multiple times
Allow connection, statement, and result set to be closed multiple times --- Key: DBCP-233 URL: https://issues.apache.org/jira/browse/DBCP-233 Project: Commons Dbcp Issue Type: Improvement Reporter: Dain Sundstrom Fix For: 1.3 Attachments: CloseTwice.patch This patch allows Connection, Statement, PreparedStatement, CallableStatement and ResultSet to be closed multiple times. The first time close is called the resource is closed and any subsequent calls have no effect. This behavior is required as per the JavaDocs for these classes. The patch adds tests for closing all types multiple times and updates any tests that incorrectly assert that a resource can be closed more then once. This patch fixes DBCP-134 and DBCP-3 -- 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: (DBCP-233) Allow connection, statement, and result set to be closed multiple times
[ https://issues.apache.org/jira/browse/DBCP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-233: Attachment: CloseTwice.patch Allow connection, statement, and result set to be closed multiple times --- Key: DBCP-233 URL: https://issues.apache.org/jira/browse/DBCP-233 Project: Commons Dbcp Issue Type: Improvement Reporter: Dain Sundstrom Fix For: 1.3 Attachments: CloseTwice.patch This patch allows Connection, Statement, PreparedStatement, CallableStatement and ResultSet to be closed multiple times. The first time close is called the resource is closed and any subsequent calls have no effect. This behavior is required as per the JavaDocs for these classes. The patch adds tests for closing all types multiple times and updates any tests that incorrectly assert that a resource can be closed more then once. This patch fixes DBCP-134 and DBCP-3 -- 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]
