[jira] Updated: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=all ] Jochen Wiedmann updated IO-99: -- Attachment: IO-99.patch Proposed patch, in order to get this done (please note, that releases are waiting for this, as Henri wrote). After considering Martin's and Stephen's suggestions, I followed Stephen's: The possibility to restart the thread raises, IMO, synchronization questions, which I do not want to address right now. The evaluation, whether a restart is required and a possible implementation may well be left for 1.4, IMO. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Priority: Critical Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-204) BasicDataSource doesn't include CallableStatement Pooling
BasicDataSource doesn't include CallableStatement Pooling - Key: DBCP-204 URL: http://issues.apache.org/jira/browse/DBCP-204 Project: Commons Dbcp Issue Type: New Feature Environment: All Reporter: Wei Chen Priority: Minor Hello =) I had explored DBCP source code to cook for my project need recently. As it's said that the Database Connection Pool (DBCP) component can be used in applications where JDBC resources need to be pooled. Apart from JDBC connections, this provides support for pooling Statement and PreparedStatement instances as well. I am curious that why it does not support for pooling CallableStatement. Does anybody know why the developer did not implement this furture?Are there some special consideration or some reason else? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-266) Log or throw exception in PropertyUtilsBean, not both
Log or throw exception in PropertyUtilsBean, not both - Key: BEANUTILS-266 URL: http://issues.apache.org/jira/browse/BEANUTILS-266 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: all Reporter: Brian Ewins This commit (related to BEANUTILS-224): http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffr1=471989r2=471990 improved the error message for illegal arguments, but also introduced a log message for that same exception. Best practice is to log or throw but not both, since this often results in the error being logged multiple times - when it was created and when the exception is caught. In addition this is logging the problem as an error when it may in fact be handled by the caller, so at worst its a debug-level message. I switched up to 1.7 recently and this has been filling up my logs. I know I can work around it by disabling logging for this component but the existence of this log message seems like an oversight. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-266) Log or throw exception in PropertyUtilsBean, not both
[ http://issues.apache.org/jira/browse/BEANUTILS-266?page=comments#action_12455282 ] Brian Ewins commented on BEANUTILS-266: --- Rereading that I see I could have been clearer: I mean just remove this line: log.error(Method invocation failed, e); from PropertyUtilsBean.invokeMethod() Log or throw exception in PropertyUtilsBean, not both - Key: BEANUTILS-266 URL: http://issues.apache.org/jira/browse/BEANUTILS-266 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: all Reporter: Brian Ewins This commit (related to BEANUTILS-224): http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffr1=471989r2=471990 improved the error message for illegal arguments, but also introduced a log message for that same exception. Best practice is to log or throw but not both, since this often results in the error being logged multiple times - when it was created and when the exception is caught. In addition this is logging the problem as an error when it may in fact be handled by the caller, so at worst its a debug-level message. I switched up to 1.7 recently and this has been filling up my logs. I know I can work around it by disabling logging for this component but the existence of this log message seems like an oversight. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 10 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: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04122006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04122006.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
[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 10 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: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-04122006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04122006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04122006.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
Re: Looking for a home for a small project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hen, Thanks for the reply. Henri Yandell wrote: Apologies for the delay in replying on this - you may want to mention this on the Http Components mailing list as it sounds like it fits their interest. I will certainly do so, but this component covers URLConnections in general, not just HttpURLConnections. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdDc69CaO5/Lv0PARAp6eAJ0asT2GVltj2HP+QCk6nMlmEp115ACgm/fn Tp4jFmel1r1TxRSk4Y0ULSA= =VWuV -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-266) Log or throw exception in PropertyUtilsBean, not both
[ http://issues.apache.org/jira/browse/BEANUTILS-266?page=all ] Niall Pemberton updated BEANUTILS-266: -- Fix Version/s: 1.8.0 Priority: Minor (was: Major) This has nothing to do with the change made 3 weeks ago (revision 471990 for BEANUTILS-224) which didn't change the logging at all. Anyway, thats academic - I don't think we should remove the logging statement since having the original stack trace could be useful debugging information - but changing it to debug level rather than error would be a good idea IMO. Log or throw exception in PropertyUtilsBean, not both - Key: BEANUTILS-266 URL: http://issues.apache.org/jira/browse/BEANUTILS-266 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: all Reporter: Brian Ewins Priority: Minor Fix For: 1.8.0 This commit (related to BEANUTILS-224): http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffr1=471989r2=471990 improved the error message for illegal arguments, but also introduced a log message for that same exception. Best practice is to log or throw but not both, since this often results in the error being logged multiple times - when it was created and when the exception is caught. In addition this is logging the problem as an error when it may in fact be handled by the caller, so at worst its a debug-level message. I switched up to 1.7 recently and this has been filling up my logs. I know I can work around it by disabling logging for this component but the existence of this log message seems like an oversight. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-266) Log or throw exception in PropertyUtilsBean, not both
[ http://issues.apache.org/jira/browse/BEANUTILS-266?page=comments#action_12455368 ] Brian Ewins commented on BEANUTILS-266: --- Whoops, my bad on thinking that was the responsible change. However - why not initCause() the caught exception rather than log it? It is possible to do this even while keeping compatibility with jdk1.3 (I see this is the target in the project xml). One way of doing this is already in the commons: org.apache.commons.httpclient.util.ExceptionUtil.initCause() The advantage is that (on newer jdks) when you eventually do log the exception that PUB throws, you'll see the whole stacktrace, not half here, half further back in the log. Log or throw exception in PropertyUtilsBean, not both - Key: BEANUTILS-266 URL: http://issues.apache.org/jira/browse/BEANUTILS-266 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: all Reporter: Brian Ewins Priority: Minor Fix For: 1.8.0 This commit (related to BEANUTILS-224): http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffr1=471989r2=471990 improved the error message for illegal arguments, but also introduced a log message for that same exception. Best practice is to log or throw but not both, since this often results in the error being logged multiple times - when it was created and when the exception is caught. In addition this is logging the problem as an error when it may in fact be handled by the caller, so at worst its a debug-level message. I switched up to 1.7 recently and this has been filling up my logs. I know I can work around it by disabling logging for this component but the existence of this log message seems like an oversight. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for a home for a small project
Hi Christopher, ever considered apache labs? http://labs.apache.org/ Simone Christopher Schultz wrote: Hen, Thanks for the reply. Henri Yandell wrote: Apologies for the delay in replying on this - you may want to mention this on the Http Components mailing list as it sounds like it fits their interest. I will certainly do so, but this component covers URLConnections in general, not just HttpURLConnections. -chris - 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: Looking for a home for a small project
On 12/4/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi Christopher, ever considered apache labs? http://labs.apache.org/ Labs is only open to ASF committers - so thats only an option if Christopher is a committer on an Apache project already. Niall Simone Christopher Schultz wrote: Hen, Thanks for the reply. Henri Yandell wrote: Apologies for the delay in replying on this - you may want to mention this on the Http Components mailing list as it sounds like it fits their interest. I will certainly do so, but this component covers URLConnections in general, not just HttpURLConnections. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons Digester 1.8 released
Commons Digester 1.8 is now available. The Commons Digester package lets users configure an XML to Java object mapping module. Digester 1.8 contains a few new features and a small number of bug fixes. Full details can be found in the release notes: http://www.apache.org/dist/jakarta/commons/digester/RELEASE-NOTES.txt Digester is available in either binary or source form from the Digester downloads page: http://jakarta.apache.org/site/downloads/downloads_commons-digester.cgi For more information on Commons Digester, visit the Digester home page: http://jakarta.apache.org/commons/digester/ -Rahul Akolkar on behalf of the Jakarta Commons community - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for a home for a small project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall, Niall Pemberton wrote: On 12/4/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi Christopher, ever considered apache labs? http://labs.apache.org/ Labs is only open to ASF committers - so thats only an option if Christopher is a committer on an Apache project already. I am not currently a committer on an Apache project. Oddly enough, this project itself is likely to make me a committer on velocity-tools. I offered to write some unit tests for a component that I declared broken and wrote this small testing component to prove that it had been fixed. So... ideally I'd like to have a project that is blessed by Apache since I'd like to use it in unit tests for another Jakarta project. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdHce9CaO5/Lv0PARAv5SAJ45AsswoKIniiKS1yfTPhGpK8YzCgCgrw6h uJ7ToK1ZZqABlnbaCh406oU= =0Ksg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-101) The method EndianUtils.writeSwappedDouble() and EndianUtils.readSwappedDouble() do not match!
The method EndianUtils.writeSwappedDouble() and EndianUtils.readSwappedDouble()
do not match!
-
Key: IO-101
URL: http://issues.apache.org/jira/browse/IO-101
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 1.2
Environment: I was running Windows XP SP2 and using Commons IO 1.2,
Java 1.5 update 9 when I got this problem.
Reporter: José Pinto
Priority: Critical
Code:
public static void main(String[] args) {
double[] tests = new double[] {34.345, -345.5645, 545.12,
10.043, 7.123456789123};
for (int i = 0; i tests.length ;i++) {
byte[] buffer = new byte[8];
EndianUtils.writeSwappedDouble(buffer, 0, tests[i]);
double val = EndianUtils.readSwappedDouble(buffer, 0);
System.out.println(val);
}
}
Result:
34.344969482421874
-345.5645
545.11951171875
10.043
7.123456789123
Note:
In my opinion the values shouldn't be changed at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for a home for a small project
On 12/4/06, Christopher Schultz [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 12/4/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi Christopher, ever considered apache labs? http://labs.apache.org/ Labs is only open to ASF committers - so thats only an option if Christopher is a committer on an Apache project already. I am not currently a committer on an Apache project. Oddly enough, this project itself is likely to make me a committer on velocity-tools. I offered to write some unit tests for a component that I declared broken and wrote this small testing component to prove that it had been fixed. So... ideally I'd like to have a project that is blessed by Apache since I'd like to use it in unit tests for another Jakarta project. Any code being brought into the ASF needs to come through the incubation process - AFAIK that can be in one of two ways - either as full blown incubator[1] podling (i.e. project) or theres a shortened process[2] for smaller code imports into an existing project (The mantissa code was recently brought into Commons Math using this mechanism). Whatever the mechanism though - seems like the best approach would be to discuss it first with the Velcoity developers. If they're sold on the idea they can then work with you on the best way to bring it in. Henning Schmiedehausen is already a Commons committer and both Nathan Bubna and Will Galss-Hussain are on the Jakarta PMC - so if they were interested in backing it I think it would be straight forward in it becoming a Commons component. If they're not interested then either you need someone else who is - or you could just propose it directly to the incubator and see if it gets any support. Niall [1] http://incubator.apache.org/ [2] http://incubator.apache.org/ip-clearance/ip-clearance-template.html Thanks, - -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for a home for a small project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall, Niall Pemberton wrote: Any code being brought into the ASF needs to come through the incubation process Thanks for the info. We'll see where it goes from here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdK4W9CaO5/Lv0PARAiRWAJ0aZ8pHH6kBOyiVMue13ZXdCOWBcwCfQFoG 3Zq8jY35vMzhNIOZiRe+faQ= =DOYN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)
[ http://issues.apache.org/jira/browse/DBCP-193?page=all ]
Henri Yandell updated DBCP-193:
---
Description:
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
DBCP-3
DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does
not allow double close without throwing (see DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in DBCP-28 because conn.isClosed() will return true and the client
will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and the
client may have already called close, so he ends up calling close() twice, see
what happens if the isClosed() in PoolableConnection returns true :
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
was:
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
http://issues.apache.org/jira/browse/DBCP-3
http://issues.apache.org/jira/browse/DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does
not allow double close without throwing (see
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in http://issues.apache.org/jira/browse/DBCP-28 because
conn.isClosed() will return true and the client will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and the
client may have already called close, so he ends up calling close() twice, see
what happens if the isClosed() in PoolableConnection returns true :
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
Changing links to just be the keys so we get the nice strikethroughs to show
things are fixed.
BasicDataSource returns negative values for NumActive when Oracle Driver
Connection#isClosed return true (End of file communication on CHannel)
---
Key: DBCP-193
URL: http://issues.apache.org/jira/browse/DBCP-193
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1, 1.2.2
Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK
1.4.2_08 / Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
Reporter: Philippe Mouawad
Priority: Blocker
Fix For: 1.3
Attachments:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java,
ShowsLeaksIfCheckForIsClosed.java, TestUtils.java
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
DBCP-3
DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp
does not allow double close without throwing (see DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in DBCP-28 because conn.isClosed() will return true and the client
will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and
the client may have already called close, so he ends up calling close()
twice, see what happens if the isClosed() in PoolableConnection returns true
: ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)
[
http://issues.apache.org/jira/browse/DBCP-193?page=comments#action_12455453 ]
Henri Yandell commented on DBCP-193:
Does DBCP-28 being fixed invalidate this issue as a problem?
BasicDataSource returns negative values for NumActive when Oracle Driver
Connection#isClosed return true (End of file communication on CHannel)
---
Key: DBCP-193
URL: http://issues.apache.org/jira/browse/DBCP-193
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1, 1.2.2
Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK
1.4.2_08 / Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
Reporter: Philippe Mouawad
Priority: Blocker
Fix For: 1.3
Attachments:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java,
ShowsLeaksIfCheckForIsClosed.java, TestUtils.java
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
DBCP-3
DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp
does not allow double close without throwing (see DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in DBCP-28 because conn.isClosed() will return true and the client
will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and
the client may have already called close, so he ends up calling close()
twice, see what happens if the isClosed() in PoolableConnection returns true
: ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=all ] Henri Yandell updated IO-99: Fix Version/s: 1.3 FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Priority: Critical Fix For: 1.3 Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r482411 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Author: bayard
Date: Mon Dec 4 15:35:54 2006
New Revision: 482411
URL: http://svn.apache.org/viewvc?view=revrev=482411
Log:
Applied the fix suggested by Mirko Friedenhagen in #IO-100. This isn't
something that it's easy to write a unit test for, but it is very easy to write
a platform dependent test and show that the new code correctly throws an
exception for '/etc/passwd'
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diffrev=482411r1=482410r2=482411
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Dec 4 15:35:54 2006
@@ -142,7 +142,10 @@
OutputStream out = new FileOutputStream(file);
IOUtils.closeQuietly(out);
}
-file.setLastModified(System.currentTimeMillis());
+boolean success = file.setLastModified(System.currentTimeMillis());
+if(!success) {
+throw new IOException(Unable to set the last modification time
for + file);
+}
}
//---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-100) FileUtils.touch should raise an IOException if I may not modify the file
[ http://issues.apache.org/jira/browse/IO-100?page=all ] Henri Yandell resolved IO-100. -- Fix Version/s: 1.3 Resolution: Fixed svn ci -m Applied the fix suggested by Mirko Friedenhagen in #IO-100. This isn't something that it's easy to write a unit test for, but it is very easy to write a platform dependent test and show that the new code correctly throws an exception for '/etc/passwd' src/java/org/apache/commons/io/FileUtils.java Sendingsrc/java/org/apache/commons/io/FileUtils.java Transmitting file data . Committed revision 482411. FileUtils.touch should raise an IOException if I may not modify the file Key: IO-100 URL: http://issues.apache.org/jira/browse/IO-100 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: Linux vmware-ap-mifr 2.6.4-52-default #1 Tue Jul 25 11:13:58 CEST 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] coms_core-trunk]$ java -version java version 1.5.0_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode, sharing) Reporter: Mirko Friedenhagen Fix For: 1.3 The documentation states, that FileUtils.touch implements the UNIX-touch command. However I may successfully FileUtils.touch files like /etc/passwd, which is not allowed on the shell as normal user. Looking at the implementation, you should propably raise an IOException if the returnvalue of `file.setLastModified(System.currentTimeMillis());` is `false`. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] Re: svn commit: r482411 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
In case this gets missed - this one does change the API in that we're
now throwing an Exception where we didn't used to before. Seems to me
that not throwing it before was a bug, therefore this is an acceptable
API change. I don't know if it was being left open because people felt
it was an unacceptable change, so sending this note.
On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: bayard
Date: Mon Dec 4 15:35:54 2006
New Revision: 482411
URL: http://svn.apache.org/viewvc?view=revrev=482411
Log:
Applied the fix suggested by Mirko Friedenhagen in #IO-100. This isn't
something that it's easy to write a unit test for, but it is very easy to write
a platform dependent test and show that the new code correctly throws an
exception for '/etc/passwd'
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diffrev=482411r1=482410r2=482411
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Dec 4 15:35:54 2006
@@ -142,7 +142,10 @@
OutputStream out = new FileOutputStream(file);
IOUtils.closeQuietly(out);
}
-file.setLastModified(System.currentTimeMillis());
+boolean success = file.setLastModified(System.currentTimeMillis());
+if(!success) {
+throw new IOException(Unable to set the last modification time for
+ file);
+}
}
//---
-
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: (IO-101) The method EndianUtils.writeSwappedDouble() and EndianUtils.readSwappedDouble() do not match!
[ http://issues.apache.org/jira/browse/IO-101?page=all ]
Henri Yandell updated IO-101:
-
Fix Version/s: 1.4
Assigning for looking at in 1.4. Looks like we're having classic data loss due
to the data type, so might not be a simple fix.
A unit test should be very easy to create from José's data above.
The method EndianUtils.writeSwappedDouble() and
EndianUtils.readSwappedDouble() do not match!
-
Key: IO-101
URL: http://issues.apache.org/jira/browse/IO-101
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 1.2
Environment: I was running Windows XP SP2 and using Commons IO 1.2,
Java 1.5 update 9 when I got this problem.
Reporter: José Pinto
Priority: Critical
Fix For: 1.4
Code:
public static void main(String[] args) {
double[] tests = new double[] {34.345, -345.5645, 545.12,
10.043, 7.123456789123};
for (int i = 0; i tests.length ;i++) {
byte[] buffer = new byte[8];
EndianUtils.writeSwappedDouble(buffer, 0, tests[i]);
double val = EndianUtils.readSwappedDouble(buffer, 0);
System.out.println(val);
}
}
Result:
34.344969482421874
-345.5645
545.11951171875
10.043
7.123456789123
Note:
In my opinion the values shouldn't be changed at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][fileupload] Releasing...?
If it helps, I'm happy to volunteer to do the RM stuff. I don't know if you have code on your laptop you're waiting to check in. Looks like we have the one issue to resolve (to which Jochen has a patch), and then we can start building etc. Hen On 11/17/06, Stephen Colebourne [EMAIL PROTECTED] wrote: IO 1.3 is about ready to go. I am in the process of moving laptops ATM and hoping that my old laptop hasn't completely died so I can extract everything off it. Stephen - Original Message From: Jochen Wiedmann [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Friday, 17 November, 2006 11:20:27 PM Subject: Re: [io][fileupload] Releasing...? On 11/17/06, Henri Yandell [EMAIL PROTECTED] wrote: 1) Should FileUpload wait on IO to release before releasing? Time frame? 2) Does this issue impact either release: http://issues.apache.org/jira/browse/IO-99 IMO, it doesn't. The situation sounds somewhat exotic and it is not even confirmed. -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (FILEUPLOAD-120) memory leak due to classloader leak (in commons.io)
[ http://issues.apache.org/jira/browse/FILEUPLOAD-120?page=all ] Henri Yandell updated FILEUPLOAD-120: - Fix Version/s: 1.2 Sounds like FileUpload 1.2 is waiting on IO 1.3 so it can fix this. As far as I understand, FileUpload will need a small amount of code change(?). memory leak due to classloader leak (in commons.io) --- Key: FILEUPLOAD-120 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-120 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.1.1 Environment: JBoss portal Reporter: Vera Mickaël Fix For: 1.2 commons.io opens a thread that is never stopped. The result is that a reference from a container class (jboss threads pool) to my webapp classloader is never released and my webapp classloader is never garbaged. After serveral deploy/undeploy cycles I experience an OutOfMemoryError : PermGen. I did open an issue in commons.io : https://issues.apache.org/jira/browse/IO-99 I also open an issue here as I think commons.fileupload have concerns about webapp environnements -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (FILEUPLOAD-118) Maven pom has invalid parent
[ http://issues.apache.org/jira/browse/FILEUPLOAD-118?page=all ] Henri Yandell closed FILEUPLOAD-118. Resolution: Fixed All commons children poms should now point to commons-parent. Maven pom has invalid parent Key: FILEUPLOAD-118 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-118 Project: Commons FileUpload Issue Type: Bug Reporter: Dain Sundstrom Priority: Blocker The correct parent for commons seems to be artifactId=commons-parent, but the pom has artifactId=commons. This prevents building with m2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Re: svn commit: r482411 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
I'm not thrilled about throwing an exception, but it probably fits with
the rest of [io].
BTW, [io] has release notes that are continuously updated, so you've got
another commit to do ;-)
Stephen
Henri Yandell wrote:
In case this gets missed - this one does change the API in that we're
now throwing an Exception where we didn't used to before. Seems to me
that not throwing it before was a bug, therefore this is an acceptable
API change. I don't know if it was being left open because people felt
it was an unacceptable change, so sending this note.
On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: bayard
Date: Mon Dec 4 15:35:54 2006
New Revision: 482411
URL: http://svn.apache.org/viewvc?view=revrev=482411
Log:
Applied the fix suggested by Mirko Friedenhagen in #IO-100. This isn't
something that it's easy to write a unit test for, but it is very easy
to write a platform dependent test and show that the new code
correctly throws an exception for '/etc/passwd'
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diffrev=482411r1=482410r2=482411
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Dec 4 15:35:54 2006
@@ -142,7 +142,10 @@
OutputStream out = new FileOutputStream(file);
IOUtils.closeQuietly(out);
}
-file.setLastModified(System.currentTimeMillis());
+boolean success =
file.setLastModified(System.currentTimeMillis());
+if(!success) {
+throw new IOException(Unable to set the last
modification time for + file);
+}
}
//---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] releases
Updating this thread; Digester, DbUtils, FileUpload and Discovery are now all released. That leaves us with: * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do. However there are 7 issues without a version which might mean they've not been looked at. * IO 1.3 - 1 issue to be resolved and then we can release. * FileUpload 1.2 - 1 issue to be resolved - blocked by IO 1.3. 7 unversioned. * Betwixt 0.8 - In the release process. Versions don't seem to be actively used in JIRA. BeanUtils is a fair way away, SCXML sounds like it'll be in a couple of months, Lang needs to decide if it should target 2.3 or 3.0 and start churning. DBCP 1.2.2 sounds like it getting closer and closer, 1 issue in 1.2.2, but 11 still unscheduled. Afaik, Pool is at the revolution stage, unless DBCP requires a minor release. Any others getting close? Validator and DbUtils are now back at the beginning of new dev releases. Discovery and Attributes are 6 foot under (I hope :) ). [off on a tangent] The unversioned-and-possibly-not-looked-at bit above is due to how I'm reading the JIRA projects. An issue coming in has 4 possible answers: 1) Put it in the currently working on version. 2) Put it in the next version. This is an acknowledgement that it's a problem, or that it's an enhancement that shows merit; but not a guarantee that it will go in that version. It's both 'next version' and 'someday'. Comments to the effect of unit-test + patch and we can push it up to [current-version] might be suitable. 3) Say No by resolving it wontfix etc. 4) Comment. This is a conversation with the aim of achieving one of 1, 2 or 3. I think this is a very low-energy, high-return way to manage our components. One of my todos is a weekly report that lets us know how many issues are in which state in the jira projects; and how many new ones there are that week etc. Also it should highlight ones that need a release [X resolved for an unreleased release and nothing unresolved - possible-release!]. Any thoughts? Hen On 11/17/06, Henri Yandell [EMAIL PROTECTED] wrote: This is cool - we're active enough that our internal dependencies are now important for release prioritizing. Sure a pain - but a good sign of activity. So, here's the ones I know of: Logging 1.1.1 Digester 1.8 IO 1.3 Betwixt 0.8 DbUtils 1.1 FileUpload 1.2 Discovery 0.4 Any missing? Seems that logging 1.1.1 is a blocker for digester, betwixt and discovery; and IO is a blocker for fileupload. And digester is a blocker for betwixt. So sounds like we should get logging 1.1.1 out asap, IO 1.3 out soon, dbutils can go whenever. ??? Is it worth thinking about things like this? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r482423 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/FileUtils.java
Author: scolebourne
Date: Mon Dec 4 16:12:58 2006
New Revision: 482423
URL: http://svn.apache.org/viewvc?view=revrev=482423
Log:
IO-100 - FileUtils.touch now throws an exception if it fails
Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?view=diffrev=482423r1=482422r2=482423
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Mon Dec 4 16:12:58 2006
@@ -22,6 +22,7 @@
Source compatible - Yes
Semantic compatible - Yes
+ Check the bug fixes section for semantic bug fixes
Deprecations from 1.2
@@ -55,6 +56,11 @@
- Fixed resource leak leading to 'Too many open files' error
- Previously did not destroy Process instances (as JDK Javadoc is so poor)
- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4801027
+
+- FileUtils.touch [IO-100]
+ - The touch method previously gave no indication when the file could not
+be touched successfully (such as due to access restrictions) - it now
+throws an IOException if the last modified date cannot be changed
- FileCleaner
- This now handles the situation where an error occurs when deleting the file
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diffrev=482423r1=482422r2=482423
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Dec 4 16:12:58 2006
@@ -133,6 +133,9 @@
* Implements the same behaviour as the touch utility on Unix. It creates
* a new file with size 0 or, if the file exists already, it is opened and
* closed without modifying it, but updating the file date and time.
+ * p
+ * NOTE: As from v1.3, this method throws an IOException if the last
+ * modified date of the file cannot be set
*
* @param file the File to touch
* @throws IOException If an I/O problem occurs
@@ -143,7 +146,7 @@
IOUtils.closeQuietly(out);
}
boolean success = file.setLastModified(System.currentTimeMillis());
-if(!success) {
+if (!success) {
throw new IOException(Unable to set the last modification time
for + file);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] releases
On 12/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Updating this thread; Digester, DbUtils, FileUpload and Discovery are now all released. That leaves us with: * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do. However there are 7 issues without a version which might mean they've not been looked at. I have reviewed the JIRA comments on the seven unversioned issues, although I have not looked at the proposed patches. All of them have had extensive discussion (although none very recently), and seem to have a variety of concerns noted in the comments. None of the issues strike me as things that are urgently needed for a 1.1.1 release, although it makes sense to look at them in the context of a 1.2 or 2.0. That being said, one of the fixes currently in the trunk was to fix the botched Maven metdata that did not declare the various logging implementation libraries to be optional. This causes a lot of pain for C-L 1.1 users who build with Maven, and therefore (in my book) justifies a 1.1.1release sooner rather than later. *That* being said :-), I don't have time to be RM for this, so I'm just hoping someone is willing to pick up that ball, and that the other developers agree with my assessments above. Craig
[jira] Updated: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[ http://issues.apache.org/jira/browse/BEANUTILS-49?page=all ]
Henri Yandell updated BEANUTILS-49:
---
Attachment: BEANUTILS-49.patch
Improved version of the patch with the return statement back in, and a now
incorrect comment removed.
Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: http://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assigned To: Niall Pemberton
Fix For: 1.8.0
Attachments: beanutils-49-ContextClassLoaderLocale.patch,
BEANUTILS-49.patch
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r482437 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt project.xml src/java/org/apache/commons/io/FileCleaner.java src/test/org/apache/commons/io/FileCleanerTestCase.java
Author: scolebourne
Date: Mon Dec 4 17:13:05 2006
New Revision: 482437
URL: http://svn.apache.org/viewvc?view=revrev=482437
Log:
IO-99 - FileCleaner.exitWhenFinished, to allow the thread to be terminated
includes some code from Jochen Wiedmann
Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/io/trunk/project.xml
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileCleanerTestCase.java
Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?view=diffrev=482437r1=482436r2=482437
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Mon Dec 4 17:13:05 2006
@@ -110,6 +110,9 @@
- This can be used as a calback in FileCleaner
- Together these allow FileCleaner to do a forceDelete to kill directories
+- FileCleaner.exitWhenFinished [IO-99]
+ - A new method that allows the internal cleaner thread to be cleanly
terminated
+
- WildcardFileFilter
- Replacement for WildcardFilter
- Accepts both files and directories
Modified: jakarta/commons/proper/io/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/project.xml?view=diffrev=482437r1=482436r2=482437
==
--- jakarta/commons/proper/io/trunk/project.xml (original)
+++ jakarta/commons/proper/io/trunk/project.xml Mon Dec 4 17:13:05 2006
@@ -224,6 +224,9 @@
nameJames Urie/name
/contributor
contributor
+ nameJochen Wiedmann/name
+/contributor
+contributor
nameFrank W. Zammetti/name
/contributor
/contributors
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java?view=diffrev=482437r1=482436r2=482437
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaner.java
Mon Dec 4 17:13:05 2006
@@ -29,6 +29,12 @@
* This utility creates a background thread to handle file deletion.
* Each file to be deleted is registered with a handler object.
* When the handler object is garbage collected, the file is deleted.
+ * p
+ * In an environment with multiple class loaders (a servlet container, for
+ * example), you should consider stopping the background thread if it is no
+ * longer needed. This is done by invoking the method
+ * [EMAIL PROTECTED] [EMAIL PROTECTED] #exitWhenFinished}, typically in
+ * [EMAIL PROTECTED] javax.servlet.ServletContextListener#contextDestroyed} or
similar.
*
* @author Noel Bergman
* @author Martin Cooper
@@ -39,47 +45,19 @@
/**
* Queue of codeTracker/code instances being watched.
*/
-private static ReferenceQueue /* Tracker */ q = new ReferenceQueue();
-
+static ReferenceQueue /* Tracker */ q = new ReferenceQueue();
/**
* Collection of codeTracker/code instances in existence.
*/
-private static Collection /* Tracker */ trackers = new Vector();
-
+static Collection /* Tracker */ trackers = new Vector();
/**
- * The thread that will clean up registered files.
+ * Whether to terminate the thread when the tracking is complete.
*/
-private static Thread reaper = new Thread(File Reaper) {
-
-/**
- * Run the reaper thread that will delete files as their associated
- * marker objects are reclaimed by the garbage collector.
- */
-public void run() {
-for (;;) {
-Tracker tracker = null;
-try {
-// Wait for a tracker to remove.
-tracker = (Tracker) q.remove();
-} catch (Exception e) {
-continue;
-}
-
-tracker.delete();
-tracker.clear();
-trackers.remove(tracker);
-}
-}
-};
-
+static volatile boolean exitWhenFinished = false;
/**
- * The static initializer that starts the reaper thread.
+ * The thread that will clean up registered files.
*/
-static {
-reaper.setPriority(Thread.MAX_PRIORITY);
-reaper.setDaemon(true);
-reaper.start();
-}
+static Thread reaper;
//---
/**
@@ -109,7 +87,7 @@
if (file == null) {
throw new NullPointerException(The file must not be null);
}
-
[jira] Commented: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=comments#action_12455486 ] Stephen Colebourne commented on IO-99: -- Please review and try the latest code in SVN. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Priority: Critical Fix For: 1.3 Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
http://issues.apache.org/jira/browse/BEANUTILS-49?page=comments#action_12455493
]
Henri Yandell commented on BEANUTILS-49:
Gut thoughts.
* We're improving the performance of something without having any numbers. So a
bit iffy there.
* The code has calls to WeakHashMap.isEmpty with a comment that seems to
indicate that this is going to cause the weak references to be re-evaluated. I
don't see how we can infer that - in fact the javadoc for WeakHashMap would
seem to imply that isEmpty does not re-evaluate things. I got into looking at
this out of worry that not synchronizing this 'purge' would cause bugs.
* While we're here } catch (SecurityException e) { /* SWALLOW - should we
log this? */ }. Should we? Should we throw an Exception? :) [yeah yeah, I
know... change of API].
* Is the unset(ClassLoader) method meant to be public? Is the
set(ClassLoader,Object) meant to be private? The class looks designed for
extension, should things be protected?
Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: http://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assigned To: Niall Pemberton
Fix For: 1.8.0
Attachments: beanutils-49-ContextClassLoaderLocale.patch,
BEANUTILS-49.patch
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [io] Re: svn commit: r482411 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Sorry, had left it til the evening to do (work intervened).
Thanks for adding that.
Hen
On 12/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I'm not thrilled about throwing an exception, but it probably fits with
the rest of [io].
BTW, [io] has release notes that are continuously updated, so you've got
another commit to do ;-)
Stephen
Henri Yandell wrote:
In case this gets missed - this one does change the API in that we're
now throwing an Exception where we didn't used to before. Seems to me
that not throwing it before was a bug, therefore this is an acceptable
API change. I don't know if it was being left open because people felt
it was an unacceptable change, so sending this note.
On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: bayard
Date: Mon Dec 4 15:35:54 2006
New Revision: 482411
URL: http://svn.apache.org/viewvc?view=revrev=482411
Log:
Applied the fix suggested by Mirko Friedenhagen in #IO-100. This isn't
something that it's easy to write a unit test for, but it is very easy
to write a platform dependent test and show that the new code
correctly throws an exception for '/etc/passwd'
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diffrev=482411r1=482410r2=482411
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Dec 4 15:35:54 2006
@@ -142,7 +142,10 @@
OutputStream out = new FileOutputStream(file);
IOUtils.closeQuietly(out);
}
-file.setLastModified(System.currentTimeMillis());
+boolean success =
file.setLastModified(System.currentTimeMillis());
+if(!success) {
+throw new IOException(Unable to set the last
modification time for + file);
+}
}
//---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r482487 - /jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh
Author: psteitz Date: Mon Dec 4 20:53:54 2006 New Revision: 482487 URL: http://svn.apache.org/viewvc?view=revrev=482487 Log: Fixed file spec on log copy op. Modified: jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh Modified: jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh?view=diffrev=482487r1=482486r2=482487 == --- jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh (original) +++ jakarta/commons/proper/commons-nightly/trunk/nightly_wrapper.sh Mon Dec 4 20:53:54 2006 @@ -31,5 +31,5 @@ # For now, scp the logs over to ~psteitz ssh people.apache.org mkdir /x1/home/psteitz/public_html/commons-nightlies/$time_stamp -scp /home/commons/public_html/nightly/logs* [EMAIL PROTECTED]:/x1/home/psteitz/public_html/commons-nightlies/$time_stamp +scp /home/commons/public_html/nightly/logs/* [EMAIL PROTECTED]:/x1/home/psteitz/public_html/commons-nightlies/$time_stamp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] releases
On 12/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Updating this thread; Digester, DbUtils, FileUpload and Discovery are now all released. That leaves us with: * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do. However there are 7 issues without a version which might mean they've not been looked at. * IO 1.3 - 1 issue to be resolved and then we can release. * FileUpload 1.2 - 1 issue to be resolved - blocked by IO 1.3. 7 unversioned. * Betwixt 0.8 - In the release process. Versions don't seem to be actively used in JIRA. BeanUtils is a fair way away, SCXML sounds like it'll be in a couple of months, Lang needs to decide if it should target 2.3 or 3.0 and start churning. DBCP 1.2.2 sounds like it getting closer and closer, 1 issue in 1.2.2, but 11 still unscheduled. Afaik, Pool is at the revolution stage, unless DBCP requires a minor release. I am cleaning up in prep for DBCP 1.2.2 - the only remaining issue will be closed when the release is cut, since it is just dropping collections dependency. I also need to either get a brilliant idea on the deadlock bugs now pushed to 1.3 (probably using new [pool] impl) or figure out a way to add appropriate warnings to the doc and release notes. Any others getting close? Validator and DbUtils are now back at the beginning of new dev releases. Discovery and Attributes are 6 foot under (I hope :) ). [off on a tangent] The unversioned-and-possibly-not-looked-at bit above is due to how I'm reading the JIRA projects. An issue coming in has 4 possible answers: 1) Put it in the currently working on version. 2) Put it in the next version. This is an acknowledgement that it's a problem, or that it's an enhancement that shows merit; but not a guarantee that it will go in that version. It's both 'next version' and 'someday'. Comments to the effect of unit-test + patch and we can push it up to [current-version] might be suitable. 3) Say No by resolving it wontfix etc. 4) Comment. This is a conversation with the aim of achieving one of 1, 2 or 3. I think this is a very low-energy, high-return way to manage our components. The problem that I keep running into when I try to do this is that it takes a fair amount of work to distinguish between 2) and 3) or to meaningfully do 4). Could be I am just slow. I agree that getting some kind of response is good. I am not sure I agree, however, with trying to jump to assigning fix versions before doing some work to understand what the issue is, or if there is in fact an issue at all. I just bounced a [dbcp] issue to OJB, for example, after spending a little time figuring out that it was in fact the [pool] config doing what OJB set it up to do by default that was causing the user problem. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-120) memory leak due to classloader leak (in commons.io)
[ http://issues.apache.org/jira/browse/FILEUPLOAD-120?page=comments#action_12455524 ] Jochen Wiedmann commented on FILEUPLOAD-120: Sounds like FileUpload 1.2 is waiting on IO 1.3 so it can fix this. As far as I understand, FileUpload will need a small amount of code change(?). Dunno. My intention was to wait for 1.3, then change the POM's (Maven 1 and 2) and see what happens. :-) memory leak due to classloader leak (in commons.io) --- Key: FILEUPLOAD-120 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-120 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.1.1 Environment: JBoss portal Reporter: Vera Mickaël Fix For: 1.2 commons.io opens a thread that is never stopped. The result is that a reference from a container class (jboss threads pool) to my webapp classloader is never released and my webapp classloader is never garbaged. After serveral deploy/undeploy cycles I experience an OutOfMemoryError : PermGen. I did open an issue in commons.io : https://issues.apache.org/jira/browse/IO-99 I also open an issue here as I think commons.fileupload have concerns about webapp environnements -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
