[jira] Created: (VFS-95) Wrong TEM Directory Logged

2006-10-11 Thread Thomas Hoppe (JIRA)
Wrong TEM Directory Logged
--

 Key: VFS-95
 URL: http://issues.apache.org/jira/browse/VFS-95
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Windows, J2SE
Reporter: Thomas Hoppe
Priority: Trivial


Although I do:

DefaultFileReplicator tempStore = new DefaultFileReplicator(new 
File(C:/temp)); 
((DefaultFileSystemManager)fsManager).setTemporaryFileStore(tempStore);

I get the following log entry:

[2006-10-11 08:31:32,579] INFO  
org.apache.commons.vfs.impl.DefaultFileReplicator - VfsLog.java(121) Using 
C:\DOCUME~1\THO\LOCALS~1\Temp\vfs_cache as temporary files store.


-- 
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: (IO-82) Test takes a long time to run in Mustang

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441375 
] 

Stephen Colebourne commented on IO-82:
--

I'd like to get IO 1.3 out soon. Hen, can you confirm this issue still exists?

 Test takes a long time to run in Mustang
 

 Key: IO-82
 URL: http://issues.apache.org/jira/browse/IO-82
 Project: Commons IO
  Issue Type: Bug
 Environment: Mustang RC b90 on Linux (x86)
 http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin
Reporter: Henri Yandell
 Fix For: 1.3


 [junit] Running org.apache.commons.io.FileCleanerTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec
 On 1.4.2 on the same machine/checkout, it takes only 1.x seconds.

-- 
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: Logging: SimpleLog not thread-safe

2006-10-11 Thread Simon Kitching
Hi Martin,

Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue. 

SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect would usually just
result in a malformed date string which may not be noticed anyway.

But it should be fixed; I'll try to do that this weekend.

Regards,

Simon

On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
 Hi,
  
 I'm not sure if anyone else uses the SimpleLog class - anyway I've
 noticed that SimpleLog.log is not thread-safe. The following code
 (starting on line 282):
  
 if(showDateTime) {
 buf.append(dateFormatter.format(new Date()));
 buf.append( );
 }
  
 makes an unsynchronized call to dateFormatter.format. As dateFormatter
 is an instance variable, and DateFormat.format is not thread-safe, this
 will cause problems if more than one thread tried to log at the same
 time.
  
 Solution: remove the dateFormatter instance variable and instantiate a
 new DateFormat each time in the log method, e.g.
  
 DateFormat dateFormatter = null;
 try {
 dateFormatter = new
 SimpleDateFormat(dateTimeFormat);
 }
 catch(IllegalArgumentException e) {
 dateFormatter = new
 SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
 }  
  
 Is anyone available who could make this change?
  
 Thanks, 
 Martin

 ___
 
 Martin Wilson
 [EMAIL PROTECTED]
 
 Bright Interactive: successfully delivering interactive websites and
 business applications
  http://www.bright-interactive.com/ http://www.bright-interactive.com
 0870 240 6520
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (LANG-284) TextTable for printing a fixedlength columns format text tables

2006-10-11 Thread David Leal (JIRA)
TextTable for printing a fixedlength columns format text tables
---

 Key: LANG-284
 URL: http://issues.apache.org/jira/browse/LANG-284
 Project: Commons Lang
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: David Leal


Just to suggest adding a TextTable class for printing in text (ASCII) format 
fixed columns table. It is usefull for printing information from command line 
application, that informs about directly on DOS Windows of Xterm direclty.

I am adding a patch a possible solution for that,

Thanks,

David

-- 
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: (LANG-284) TextTable for printing a fixedlength columns format text tables

2006-10-11 Thread David Leal (JIRA)
 [ http://issues.apache.org/jira/browse/LANG-284?page=all ]

David Leal updated LANG-284:


Attachment: TextTable.java

Implementation of TextTable.

 TextTable for printing a fixedlength columns format text tables
 ---

 Key: LANG-284
 URL: http://issues.apache.org/jira/browse/LANG-284
 Project: Commons Lang
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: David Leal
 Attachments: TextTable.java


 Just to suggest adding a TextTable class for printing in text (ASCII) format 
 fixed columns table. It is usefull for printing information from command line 
 application, that informs about directly on DOS Windows of Xterm direclty.
 I am adding a patch a possible solution for that,
 Thanks,
 David

-- 
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: r462769 - /jakarta/commons/proper/io/trunk/checkstyle.xml

2006-10-11 Thread niallp
Author: niallp
Date: Wed Oct 11 04:16:20 2006
New Revision: 462769

URL: http://svn.apache.org/viewvc?view=revrev=462769
Log:
Change checkstyle to allow @throws tags for exceptions which are sub-classes of 
exception(s) declared as thrown by the method.

Modified:
jakarta/commons/proper/io/trunk/checkstyle.xml

Modified: jakarta/commons/proper/io/trunk/checkstyle.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/checkstyle.xml?view=diffrev=462769r1=462768r2=462769
==
--- jakarta/commons/proper/io/trunk/checkstyle.xml (original)
+++ jakarta/commons/proper/io/trunk/checkstyle.xml Wed Oct 11 04:16:20 2006
@@ -39,6 +39,7 @@
 /module
 module name=JavadocMethod
   property name=allowUndeclaredRTE value=true/
+  property name=allowThrowsTagsForSubclasses value=true/
 /module
  /module
 /module



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462772 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java

2006-10-11 Thread niallp
Author: niallp
Date: Wed Oct 11 04:20:55 2006
New Revision: 462772

URL: http://svn.apache.org/viewvc?view=revrev=462772
Log:
Remove unused import of UnsupportedEncodingException and modify javadoc 
references to that class to use fully qualified name.

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=462772r1=462771r2=462772
==
--- 
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 
Wed Oct 11 04:20:55 2006
@@ -24,7 +24,6 @@
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.OutputStream;
-import java.io.UnsupportedEncodingException;
 import java.net.URL;
 import java.util.Collection;
 import java.util.Date;
@@ -871,7 +870,7 @@
  * @param encoding  the encoding to use, null means platform default
  * @return the file contents or null if read failed
  * @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported 
by the VM
+ * @throws java.io.UnsupportedEncodingException if the encoding is not 
supported by the VM
  */
 public static String readFileToString(
 File file, String encoding) throws IOException {
@@ -915,7 +914,7 @@
  * @param encoding  the encoding to use, null means platform default
  * @return the list of Strings representing each line in the file
  * @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported 
by the VM
+ * @throws java.io.UnsupportedEncodingException if the encoding is not 
supported by the VM
  * @since Commons IO 1.1
  */
 public static List readLines(File file, String encoding) throws 
IOException {
@@ -989,7 +988,7 @@
  * @param data  the content to write to the file
  * @param encoding  the encoding to use, null means platform default
  * @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported 
by the VM
+ * @throws java.io.UnsupportedEncodingException if the encoding is not 
supported by the VM
  */
 public static void writeStringToFile(File file,
 String data, String encoding) throws IOException {
@@ -1032,7 +1031,7 @@
  * @param encoding  the encoding to use, null means platform default
  * @param lines  the lines to write, null entries produce blank lines
  * @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported 
by the VM
+ * @throws java.io.UnsupportedEncodingException if the encoding is not 
supported by the VM
  * @since Commons IO 1.1
  */
 public static void writeLines(File file, String encoding, Collection 
lines) throws IOException {
@@ -1053,7 +1052,7 @@
  * @param lines  the lines to write, null entries produce blank lines
  * @param lineEnding  the line separator to use, null is system default
  * @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported 
by the VM
+ * @throws java.io.UnsupportedEncodingException if the encoding is not 
supported by the VM
  * @since Commons IO 1.1
  */
 public static void writeLines(File file, String encoding, Collection 
lines, String lineEnding) throws IOException {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462773 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java

2006-10-11 Thread niallp
Author: niallp
Date: Wed Oct 11 04:32:30 2006
New Revision: 462773

URL: http://svn.apache.org/viewvc?view=revrev=462773
Log:
javadoc changes only

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java?view=diffrev=462773r1=462772r2=462773
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
 Wed Oct 11 04:32:30 2006
@@ -183,6 +183,7 @@
 }
 
 /**
+ * @param out The OutputStream to write to.
  * @exception IOException
  *if an I/O error occurs. In particular, an 
codeIOException/code is thrown if the output
  *stream is closed.
@@ -229,6 +230,8 @@
 }
 
 /**
+ * @param enc The name of the character encoding
+ * @return String converted from the byte array.
  * @exception UnsupportedEncodingException
  *If the named charset is not supported
  * @see java.io.ByteArrayOutputStream#toString(String)



-
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

2006-10-11 Thread commons-jelly-tags-jsl development
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 36 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: 18 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-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11102006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11102006.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[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

2006-10-11 Thread commons-jelly-tags-jsl development
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 36 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: 18 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-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-11102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11102006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11102006.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[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: svn commit: r462772 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java

2006-10-11 Thread Stephen Colebourne

[EMAIL PROTECTED] wrote:

Remove unused import of UnsupportedEncodingException and modify javadoc

references to that class to use fully qualified name.

I wouldn't exactly describe it as unused, as it was used by the javadoc. 
I guess our IDEs must differ because this wasn't showing as a problem 
for me.


Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462795 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 06:35:19 2006
New Revision: 462795

URL: http://svn.apache.org/viewvc?view=revrev=462795
Log:
Javadoc style (less loud) and Checkstyle spaces

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java?view=diffrev=462795r1=462794r2=462795
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 Wed Oct 11 06:35:19 2006
@@ -95,7 +95,7 @@
  * @deprecated use codegetByteCount()/code - see issue IO-84
  */
 public int getCount() {
-return (int)getByteCount();
+return (int) getByteCount();
 }
 
 /** 
@@ -109,17 +109,16 @@
  * @deprecated use coderesetByteCount()/code - see issue IO-84
  */
 public synchronized int resetCount() {
-return (int)resetByteCount();
+return (int) resetByteCount();
 }
 
 /**
  * The number of bytes that have passed through this stream.
  * p
- * strongN.B./strong This method was introduced as an
- * alternative for the codegetCount()/code method
- * because that method returns an integer which will result
- * in incorrect count for files over 2GB being returned.
- * 
+ * NOTE: This method is a replacement for codegetCount()/code
+ * and was added because that method returns an integer which will
+ * result in incorrect count for files over 2GB.
+ *
  * @return the number of bytes accumulated
  */
 public long getByteCount() {
@@ -129,10 +128,9 @@
 /** 
  * Set the count back to 0. 
  * p
- * strongN.B./strong This method was introduced as an
- * alternative for the coderesetCount()/code method
- * because that method returns an integer which will result
- * in incorrect count for files over 2GB being returned.
+ * NOTE: This method is a replacement for coderesetCount()/code
+ * and was added because that method returns an integer which will
+ * result in incorrect count for files over 2GB.
  *
  * @return the count previous to resetting.
  */



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: svn commit: r462772 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java

2006-10-11 Thread Rahul Akolkar

On 10/11/06, Stephen Colebourne [EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:
 Remove unused import of UnsupportedEncodingException and modify javadoc
references to that class to use fully qualified name.

I wouldn't exactly describe it as unused, as it was used by the javadoc.
I guess our IDEs must differ because this wasn't showing as a problem
for me.


snip/

True, eclipse-based tooling doesn't seem to flag it (by default), but
code checkers like checkstyle do (by default). I prefer to leave such
imports in, but its one of those things that can probably be chalked
off to being a matter of taste (and thereby, conformance to existing
style).

-Rahul



Stephen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462807 - in /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io: input/CountingInputStream.java output/CountingOutputStream.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 07:05:02 2006
New Revision: 462807

URL: http://svn.apache.org/viewvc?view=revrev=462807
Log:
Javadoc, checkstyle and since tags

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java?view=diffrev=462807r1=462806r2=462807
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 Wed Oct 11 07:05:02 2006
@@ -20,8 +20,11 @@
 import java.io.InputStream;
 
 /**
- * A decorating input stream that counts the number of bytes that
- * have passed through so far.
+ * A decorating input stream that counts the number of bytes that have passed
+ * through the stream so far.
+ * p
+ * A typical use case would be during debugging, to ensure that data is being
+ * read as expected.
  *
  * @author Henri Yandell
  * @author Marcelo Liberato
@@ -34,15 +37,21 @@
 
 /**
  * Constructs a new CountingInputStream.
- * @param in InputStream to delegate to
+ *
+ * @param in  the InputStream to delegate to
  */
 public CountingInputStream(InputStream in) {
 super(in);
 }
 
+//---
 /**
- * Increases the count by super.read(b)'s return count
- * 
+ * Reads a number of bytes into the byte array, keeping count of the
+ * number read.
+ *
+ * @param b  the buffer into which the data is read, not null
+ * @return the total number of bytes read into the buffer, -1 if end of 
stream
+ * @throws IOException if an I/O error occurs
  * @see java.io.InputStream#read(byte[]) 
  */
 public int read(byte[] b) throws IOException {
@@ -52,8 +61,14 @@
 }
 
 /**
- * Increases the count by super.read(b, off, len)'s return count
+ * Reads a number of bytes into the byte array at a specific offset,
+ * keeping count of the number read.
  *
+ * @param b  the buffer into which the data is read, not null
+ * @param off  the start offset in the buffer
+ * @param len  the maximum number of bytes to read
+ * @return the total number of bytes read into the buffer, -1 if end of 
stream
+ * @throws IOException if an I/O error occurs
  * @see java.io.InputStream#read(byte[], int, int)
  */
 public int read(byte[] b, int off, int len) throws IOException {
@@ -63,8 +78,11 @@
 }
 
 /**
- * Increases the count by 1 if a byte is successfully read. 
+ * Reads the next byte of data adding to the count of bytes received
+ * if a byte is successfully read. 
  *
+ * @return the byte read, -1 if end of stream
+ * @throws IOException if an I/O error occurs
  * @see java.io.InputStream#read()
  */
 public int read() throws IOException {
@@ -72,10 +90,14 @@
 this.count += (found = 0) ? 1 : 0;
 return found;
 }
-
+
 /**
- * Increases the count by the number of skipped bytes.
- * 
+ * Skips the stream over the specified number of bytes, adding the skipped
+ * amount to the count.
+ *
+ * @param length  the number of bytes to skip
+ * @return the actual number of bytes skipped
+ * @throws IOException if an I/O error occurs
  * @see java.io.InputStream#skip(long)
  */
 public long skip(final long length) throws IOException {
@@ -84,6 +106,7 @@
 return skip;
 }
 
+//---
 /**
  * The number of bytes that have passed through this stream.
  * p
@@ -120,19 +143,21 @@
  * result in incorrect count for files over 2GB.
  *
  * @return the number of bytes accumulated
+ * @since Commons IO 1.3
  */
 public long getByteCount() {
 return this.count;
 }
 
 /** 
- * Set the count back to 0. 
+ * Set the byte count back to 0. 
  * p
  * NOTE: This method is a replacement for coderesetCount()/code
  * and was added because that method returns an integer which will
  * result in incorrect count for files over 2GB.
  *
- * @return the count previous to resetting.
+ * @return the count previous to resetting
+ * @since Commons IO 1.3
  */
 public synchronized long resetByteCount() {
 long tmp = this.count;

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java
URL: 

Re: [feedparser] Security patch

2006-10-11 Thread Kevin Burton

On 10/10/06, Nick Lothian [EMAIL PROTECTED] wrote:


Hi,

I'm a developer on the ROME RSS/Atom parser project
(http://rome.dev.java.net/). We were recently notified of a possible
security issue in our code
(http://www.somebits.com/weblog/tech/bad/xmlCode.html), which we've
fixed.

I'm aware that FeedParser is a dormant project, but the attached patch
will fix the same problem in the Apache-Commons project version.



FeedParser def isn't dormant

http://code.tailrank.com/feedparser

I just haven't officially announced that I'm moving it out of Apache.  Just
been to busy with official work to be a good maintainer :-/

I've also attached updated FeedParserImpl.java suitable for using with

Kevin's TailRank version (http://tailrank.com/code.php) (Hi Kevin!)



Sweet.

SAXBuilder.java is needed for both versions.


There is also an example RSS file which triggers the bug. (You'll need
some kind of monitoring tool to check for connections to example.com
on port 80).

Hopefully someone will find these useful.



Interesting.. I'll take a look.

Thanks.

Kevin

--
Founder/CEO Tailrank.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Blog: feedblog.org
Cell: 415-637-8078


[jira] Commented: (IO-82) Test takes a long time to run in Mustang

2006-10-11 Thread Henri Yandell (JIRA)
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441468 
] 

Henri Yandell commented on IO-82:
-

Yep, still there in the latest JDK:

[junit] Running org.apache.commons.io.FileCleanerTestCase
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 226.987 sec

 Test takes a long time to run in Mustang
 

 Key: IO-82
 URL: http://issues.apache.org/jira/browse/IO-82
 Project: Commons IO
  Issue Type: Bug
 Environment: Mustang RC b90 on Linux (x86)
 http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin
Reporter: Henri Yandell
 Fix For: 1.3


 [junit] Running org.apache.commons.io.FileCleanerTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec
 On 1.4.2 on the same machine/checkout, it takes only 1.x seconds.

-- 
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: r462818 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/input/CountingInputStream.java src/java/org/apache/commons/io/output/CountingOutputStream.ja

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 07:44:17 2006
New Revision: 462818

URL: http://svn.apache.org/viewvc?view=revrev=462818
Log:
IO-84 - Change int methods from deprecated to exception throwng

Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.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=462818r1=462817r2=462818
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Wed Oct 11 07:44:17 2006
@@ -63,6 +63,11 @@
   - Comment about result byte/char count being limited to an int, thus
 being inacurate for large streams
 
+- CountingInputStream/CountingOutputStream [IO-84]
+  - methods were declared as int thus the count was innacurate for large 
streams
+  - new long based methods getByteCount()/resetByteCount() added
+  - existing methods changed to throw an exception if the count is greater 
than an int
+
 
 Enhancements from 1.2
 -

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java?view=diffrev=462818r1=462817r2=462818
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
 Wed Oct 11 07:44:17 2006
@@ -110,49 +110,57 @@
 /**
  * The number of bytes that have passed through this stream.
  * p
- * strongWARNING/strong This method will return an
- * incorrect count for files over 2GB - use
- * codegetByteCount()/code instead.
+ * NOTE: From v1.3 this method throws an ArithmeticException if the
+ * count is greater than can be expressed by an codeint/code.
+ * See [EMAIL PROTECTED] #getByteCount()} for a method using a 
codelong/code.
  *
  * @return the number of bytes accumulated
- * @deprecated use codegetByteCount()/code - see issue IO-84
+ * @throws ArithmeticException if the byte count is too large
  */
-public int getCount() {
-return (int) getByteCount();
+public synchronized int getCount() {
+long result = getByteCount();
+if (result  Integer.MAX_VALUE) {
+throw new ArithmeticException(The byte count  + result +  is 
too large to be converted to an int);
+}
+return (int) result;
 }
 
 /** 
- * Set the count back to 0. 
+ * Set the byte count back to 0. 
  * p
- * strongWARNING/strong This method will return an
- * incorrect count for files over 2GB - use
- * coderesetByteCount()/code instead.
+ * NOTE: From v1.3 this method throws an ArithmeticException if the
+ * count is greater than can be expressed by an codeint/code.
+ * See [EMAIL PROTECTED] #resetByteCount()} for a method using a 
codelong/code.
  *
- * @return the count previous to resetting.
- * @deprecated use coderesetByteCount()/code - see issue IO-84
+ * @return the count previous to resetting
+ * @throws ArithmeticException if the byte count is too large
  */
 public synchronized int resetCount() {
-return (int) resetByteCount();
+long result = resetByteCount();
+if (result  Integer.MAX_VALUE) {
+throw new ArithmeticException(The byte count  + result +  is 
too large to be converted to an int);
+}
+return (int) result;
 }
 
 /**
  * The number of bytes that have passed through this stream.
  * p
- * NOTE: This method is a replacement for codegetCount()/code
+ * NOTE: This method is an alternative for codegetCount()/code
  * and was added because that method returns an integer which will
  * result in incorrect count for files over 2GB.
  *
  * @return the number of bytes accumulated
  * @since Commons IO 1.3
  */
-public long getByteCount() {
+public synchronized long getByteCount() {
 return this.count;
 }
 
 /** 
  * Set the byte count back to 0. 
  * p
- * NOTE: This method is a replacement for coderesetCount()/code
+ * NOTE: This method is an alternative for coderesetCount()/code
  * and was added because that method returns an integer which will
  * result in incorrect count for files over 2GB.
  *

Modified: 

[jira] Commented: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12441471 
] 

Stephen Colebourne commented on IO-84:
--

I've changed these from deprecated to throw an exception instead (although I'm 
open to -1/MIN_VALUE/MAX_VALUE too)

The reason is that most users will probably only care about smaller files, and 
inconveniencing the many for the few is too harsh a response to this 
problem.The javadoc together with an exception would seem to be a safe way to 
deal with the problem.

This call is now awaiting feedback or closure.


 Many classes are limited to length of stream  2 GB, and behave incorrectly 
 on larger streams
 -

 Key: IO-84
 URL: http://issues.apache.org/jira/browse/IO-84
 Project: Commons IO
  Issue Type: Bug
  Components: Utilities
Affects Versions: 1.2
 Environment: All
Reporter: Evgenii Philippov
 Fix For: 1.3

 Attachments: io-84-files-larger-than-2gb.patch


 java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will 
 behave incorrectly.
 For example, see 
 http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup
 Method: int copy(InputStream input, OutputStream output).
 The correct method would be: long copy(InputStream input, OutputStream 
 output).
 This issue may affect many classes and routines.

-- 
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: r462824 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 08:02:10 2006
New Revision: 462824

URL: http://svn.apache.org/viewvc?view=revrev=462824
Log:
Javadoc

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java?view=diffrev=462824r1=462823r2=462824
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
 Wed Oct 11 08:02:10 2006
@@ -19,6 +19,7 @@
 import java.io.IOException;
 import java.io.OutputStream;
 import java.io.UnsupportedEncodingException;
+import java.util.ArrayList;
 import java.util.List;
 
 /**
@@ -41,12 +42,13 @@
  * the contents don't have to be copied to the new buffer. This class is
  * designed to behave exactly like the original. The only exception is the
  * deprecated toString(int) method that has been ignored.
+ * 
  * @author a href=mailto:[EMAIL PROTECTED]Jeremias Maerki/a
  * @version $Id$
  */
 public class ByteArrayOutputStream extends OutputStream {
 
-private List buffers = new java.util.ArrayList();
+private List buffers = new ArrayList();
 private int currentBufferIndex;
 private int filledBufferSum;
 private byte[] currentBuffer;
@@ -166,7 +168,9 @@
  * Closing a ttByteArrayOutputStream/tt has no effect. The methods in
  * this class can be called after the stream has been closed without
  * generating an ttIOException/tt.
- * @throws IOException in case an I/O error occurs
+ *
+ * @throws IOException never (this method should not declare this exception
+ * but it has to now due to backwards compatability)
  */
 public void close() throws IOException {
 //nop
@@ -183,10 +187,11 @@
 }
 
 /**
- * @param out The OutputStream to write to.
- * @exception IOException
- *if an I/O error occurs. In particular, an 
codeIOException/code is thrown if the output
- *stream is closed.
+ * Writes the entire contents of this byte stream to the
+ * specified output stream.
+ *
+ * @param out  the output stream to write to
+ * @throws IOException if an I/O error occurs, such as if the stream is 
closed
  * @see java.io.ByteArrayOutputStream#writeTo(OutputStream)
  */
 public synchronized void writeTo(OutputStream out) throws IOException {
@@ -203,9 +208,13 @@
 }
 
 /**
+ * Gets the curent contents of this byte stream as a byte array.
+ * The result is independent of this stream.
+ *
+ * @return the current contents of this output stream, as a byte array
  * @see java.io.ByteArrayOutputStream#toByteArray()
  */
-public synchronized byte toByteArray()[] {
+public synchronized byte[] toByteArray() {
 int remaining = count;
 int pos = 0;
 byte newbuf[] = new byte[count];
@@ -223,6 +232,8 @@
 }
 
 /**
+ * Gets the curent contents of this byte stream as a string.
+ *
  * @see java.io.ByteArrayOutputStream#toString()
  */
 public String toString() {
@@ -230,10 +241,12 @@
 }
 
 /**
- * @param enc The name of the character encoding
- * @return String converted from the byte array.
- * @exception UnsupportedEncodingException
- *If the named charset is not supported
+ * Gets the curent contents of this byte stream as a string
+ * using the specified encoding.
+ *
+ * @param enc  the name of the character encoding
+ * @return the string converted from the byte array
+ * @throws UnsupportedEncodingException if the encoding is not supported
  * @see java.io.ByteArrayOutputStream#toString(String)
  */
 public String toString(String enc) throws UnsupportedEncodingException {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [feedparser] Security patch

2006-10-11 Thread Nick Lothian


 I'm aware that FeedParser is a dormant project, but the attached patch
 will fix the same problem in the Apache-Commons project version.

FeedParser def isn't dormant

http://code.tailrank.com/feedparser

I just haven't officially announced that I'm moving it out of Apache.  Just
been to busy with official work to be a good maintainer :-/



Sorry - I didn't mean to imply that you aren't working on it - I know
you've made the Tailrank stream available.

All I meant was that FeedParser is listed in
http://jakarta.apache.org/commons/dormant/index.html, which I believe
means that no one is actively maintaining the Apache version.

Nick

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (IO-79) [IO][PATCH] - file and directory pollers

2006-10-11 Thread JIRA
[ http://issues.apache.org/jira/browse/IO-79?page=comments#action_12441477 
] 

Holger Hoffstätte commented on IO-79:
-

It would be incredibly useful if this functionality could make optional use of 
an alternative backend, e.g. http://jnotify.sourceforge.net/. By default the 
Java mechanisms can be used but having a pluggable event provider abstraction 
interface would be nice.


 [IO][PATCH] - file and directory pollers
 

 Key: IO-79
 URL: http://issues.apache.org/jira/browse/IO-79
 Project: Commons IO
  Issue Type: Improvement
  Components: Utilities
Affects Versions: 1.1
 Environment: Operating System: other
 Platform: Other
Reporter: Jim Harrington
Priority: Minor
 Fix For: 1.4

 Attachments: file_directory_poller.jar


 Add classes that will monitor a file/directory and notify registered 
 observers 
 creation, deletion and content change events occur.  Source is in the 
 attachement file_directory_poller.jar as they are all new files.

-- 
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: (IO-86) Add DirectoryWalker based on FileFinder

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441483 
] 

Stephen Colebourne commented on IO-86:
--

Why a boolean? Firstly, because it reduces the jar file size slightly (each 
class is an overhead), but secondly because I wanted the handlers to be able to 
ignore the cancellation request (which they can't do with an exception because 
its too late by that point).

What you're suggesting now could almost argue for no cancellation behaviour at 
all - what does CancelledOperation(Exception) give over throwing an IOException 
directly?

I do agree that the code I checked in doesn't support the internal model of 
cancellation. This could be fixed by adding a setCancelled() method and a 
boolean flag. Maybe we are worrying too much about the sync cost of volatile?

 Add DirectoryWalker based on FileFinder
 ---

 Key: IO-86
 URL: http://issues.apache.org/jira/browse/IO-86
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 1.2
Reporter: Niall Pemberton
 Fix For: 1.3

 Attachments: FileFinder.java, FileFinderTestCase.java, 
 io-DirectoryWalker-cancellation-2.patch, io-filefinder-start-end.patch


 I'd like to propose adding a FileFinder back into Commons IO. This is a 
 simplified version of what was recently moved out of Commons IO into the 
 finder component currently in the sandbox.
 I believe this is a simpler, more generic implementation than the finder 
 component and therefore would be considered suitable for inclusion in Commons 
 IO. Although simpler it could be used as the basis for achieving the finder 
 component's aims - namely to emulate the unix find command.

-- 
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: r462832 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/output/NullWriter.java test/org/apache/commons/io/output/NullWriterTest.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 08:48:09 2006
New Revision: 462832

URL: http://svn.apache.org/viewvc?view=revrev=462832
Log:
IO-95 - Remove throws IOException from methods

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/NullWriter.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/NullWriterTest.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/NullWriter.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/NullWriter.java?view=diffrev=462832r1=462831r2=462832
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/NullWriter.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/NullWriter.java
 Wed Oct 11 08:48:09 2006
@@ -16,13 +16,12 @@
  */
 package org.apache.commons.io.output;
 
-import java.io.IOException;
 import java.io.Writer;
 
 /**
  * This [EMAIL PROTECTED] Writer} writes all data to the famous 
b/dev/null/b.
  * p
- * This [EMAIL PROTECTED] Writer} has no destination (file/socket etc.) and all
+ * This codeWriter/code has no destination (file/socket etc.) and all
  * characters written to it are ignored and lost.
  * 
  * @version $Id$
@@ -36,37 +35,37 @@
 }
 
 /** @see java.io.Writer#write(int) */
-public void write(int idx) throws IOException {
+public void write(int idx) {
 //to /dev/null
 }
 
 /** @see java.io.Writer#write(char[]) */
-public void write(char[] chr) throws IOException {
+public void write(char[] chr) {
 //to /dev/null
 }
 
 /** @see java.io.Writer#write(char[], int, int) */
-public void write(char[] chr, int st, int end) throws IOException {
+public void write(char[] chr, int st, int end) {
 //to /dev/null
 }
 
 /** @see java.io.Writer#write(String) */
-public void write(String str) throws IOException {
+public void write(String str) {
 //to /dev/null
 }
 
 /** @see java.io.Writer#write(String, int, int) */
-public void write(String str, int st, int end) throws IOException {
+public void write(String str, int st, int end) {
 //to /dev/null
 }
 
 /** @see java.io.Writer#flush() */
-public void flush() throws IOException {
+public void flush() {
 //to /dev/null
 }
 
 /** @see java.io.Writer#close() */
-public void close() throws IOException {
+public void close() {
 //to /dev/null
 }
 

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/NullWriterTest.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/NullWriterTest.java?view=diffrev=462832r1=462831r2=462832
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/NullWriterTest.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/NullWriterTest.java
 Wed Oct 11 08:48:09 2006
@@ -16,26 +16,21 @@
  */
 package org.apache.commons.io.output;
 
-
-import java.io.IOException;
-
 import junit.framework.TestCase;
 
-
 /**
  * Really not a lot to do here, but checking that no 
  * Exceptions are thrown. 
  *
  * @version $Revision$
  */
-
 public class NullWriterTest extends TestCase {
 
 public NullWriterTest(String name) {
 super(name);
 }
 
-public void testNull() throws IOException {
+public void testNull() {
 char[] chars = new char[] {'A', 'B', 'C'};
 NullWriter writer = new NullWriter();
 writer.write(1);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462833 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/test/org/apache/commons/io/output/PackageTestSuite.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 08:49:33 2006
New Revision: 462833

URL: http://svn.apache.org/viewvc?view=revrev=462833
Log:
IO-95 - Add NullWriter

Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/PackageTestSuite.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=462833r1=462832r2=462833
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Wed Oct 11 08:49:33 2006
@@ -136,6 +136,9 @@
   - new sizeRangeFileFilter(long minimumSize, long maximumSize) method which 
 creates a filter that accepts files within the specified size range.
 
+- NullWriter
+  - New writer that acts as a sink for all data, as per /dev/null
+
 
 Feedback
 

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/PackageTestSuite.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/PackageTestSuite.java?view=diffrev=462833r1=462832r2=462833
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/PackageTestSuite.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/output/PackageTestSuite.java
 Wed Oct 11 08:49:33 2006
@@ -38,6 +38,7 @@
 suite.addTest(new TestSuite(DeferredFileOutputStreamTest.class));
 suite.addTest(new TestSuite(LockableFileWriterTest.class));
 suite.addTest(new TestSuite(NullOutputStreamTest.class));
+suite.addTest(new TestSuite(NullWriterTest.class));
 suite.addTest(new TestSuite(TeeOutputStreamTest.class));
 return suite;
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Resolved: (IO-95) New NullWriter implementation

2006-10-11 Thread Stephen Colebourne (JIRA)
 [ http://issues.apache.org/jira/browse/IO-95?page=all ]

Stephen Colebourne resolved IO-95.
--

Resolution: Fixed

I removed the unecessary throws IOException,and added the test to the package 
suite

 New NullWriter implementation
 -

 Key: IO-95
 URL: http://issues.apache.org/jira/browse/IO-95
 Project: Commons IO
  Issue Type: New Feature
  Components: Streams/Writers
Reporter: Niall Pemberton
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.3


 Add a new NullWriter class - Writer equivalent of NullOutputStream

-- 
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: (IO-96) Test case misuses read(byte[]) and read(char[])

2006-10-11 Thread Stephen Colebourne (JIRA)
Test case misuses read(byte[]) and read(char[])
---

 Key: IO-96
 URL: http://issues.apache.org/jira/browse/IO-96
 Project: Commons IO
  Issue Type: Bug
  Components: Filters, Streams/Writers, Utilities
Affects Versions: 1.2
 Environment: GNU classpath
Reporter: Stephen Colebourne
 Assigned To: Stephen Colebourne
Priority: Minor
 Fix For: 1.3


Message to mailing list from Anthony Green
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg82127.html

-
This support routine from the commons-io project test code assumed that
FileReader.read(byte[]) would always read the entire file.  There's no
such guarantee, and some tests were failing on GNU Classpath based VMs
because of this.

Thanks,

AG



--- src/test/org/apache/commons/io/testtools/FileBasedTestCase.java~
2006-07-13 23:44:13.0 -0700
+++ src/test/org/apache/commons/io/testtools/FileBasedTestCase.java 
2006-07-13 23:44:20.0 -0700
@@ -167,18 +171,22 @@
 throws IOException
 {
 Reader ir = new java.io.FileReader( file );
-try {
-char[] c1 = new char[ c0.length ];
-int numRead = ir.read( c1 );
-assertTrue( Different number of bytes, numRead == c0.length );
-for( int i = 0;
- i  numRead;
- assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + 
c1[ i ] + ), 
-c0[ i ] == c1[ i ] ), i++
-);
-} finally {
-ir.close();
-}
+   int count = 0, numRead = 0;
+   char[] c1 = new char[ c0.length ];
+   try {
+ while (count  c0.length)
+   {
+ numRead = ir.read( c1, count, c0.length);
+ for( int i = count;
+  i  count+numRead;
+  assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + 
c1[ i ] + ), 
+  c0[ i ] == c1[ i ] ), i++
+  );
+ count += numRead;
+   }
+   } finally {
+ ir.close();
+   }
 }
 
 protected void checkWrite(OutputStream output) throws Exception {

-- 
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: r462842 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/test/org/apache/commons/io/testtools/FileBasedTestCase.java

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 09:30:24 2006
New Revision: 462842

URL: http://svn.apache.org/viewvc?view=revrev=462842
Log:
IO-96 - FileBasedTestCase - Fixed bug in compare content methods identified by 
GNU classpath
based on patch from Anthony Green

Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/testtools/FileBasedTestCase.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=462842r1=462841r2=462842
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Wed Oct 11 09:30:24 2006
@@ -68,6 +68,9 @@
   - new long based methods getByteCount()/resetByteCount() added
   - existing methods changed to throw an exception if the count is greater 
than an int
 
+- FileBasedTestCase
+  - Fixed bug in compare content methods identified by GNU classpath
+
 
 Enhancements from 1.2
 -

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/testtools/FileBasedTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/testtools/FileBasedTestCase.java?view=diffrev=462842r1=462841r2=462842
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/testtools/FileBasedTestCase.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/testtools/FileBasedTestCase.java
 Wed Oct 11 09:30:24 2006
@@ -165,38 +165,38 @@
 }
 
 /** Assert that the content of a file is equal to that in a byte[]. */
-protected void assertEqualContent( byte[] b0, File file )
-throws IOException
-{
-InputStream is = new java.io.FileInputStream( file );
+protected void assertEqualContent(byte[] b0, File file) throws IOException 
{
+InputStream is = new java.io.FileInputStream(file);
+int count = 0, numRead = 0;
+byte[] b1 = new byte[b0.length];
 try {
-byte[] b1 = new byte[ b0.length ];
-int numRead = is.read( b1 );
-assertTrue( Different number of bytes, numRead == b0.length  
is.available() == 0 );
-for( int i = 0;
- i  numRead;
- assertTrue( Byte  + i +  differs ( + b0[ i ] +  !=  + 
b1[ i ] + ), 
-b0[ i ] == b1[ i ] ), i++
-);
+while (count  b0.length  numRead = 0) {
+numRead = is.read(b1, count, b0.length);
+count += numRead;
+}
+assertEquals(Different number of bytes: , b0.length, count);
+for (int i = 0; i  count; i++) {
+assertEquals(byte  + i +  differs, b0[i], b1[i]);
+}
 } finally {
 is.close();
 }
 }
 
 /** Assert that the content of a file is equal to that in a char[]. */
-protected void assertEqualContent( char[] c0, File file )
-throws IOException
-{
-Reader ir = new java.io.FileReader( file );
+protected void assertEqualContent(char[] c0, File file) throws IOException 
{
+Reader ir = new java.io.FileReader(file);
+int count = 0, numRead = 0;
+char[] c1 = new char[c0.length];
 try {
-char[] c1 = new char[ c0.length ];
-int numRead = ir.read( c1 );
-assertTrue( Different number of bytes, numRead == c0.length );
-for( int i = 0;
- i  numRead;
- assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + 
c1[ i ] + ), 
-c0[ i ] == c1[ i ] ), i++
-);
+while (count  c0.length  numRead = 0) {
+numRead = ir.read(c1, count, c0.length);
+count += numRead;
+}
+assertEquals(Different number of chars: , c0.length, count);
+for (int i = 0; i  count; i++) {
+assertEquals(char  + i +  differs, c0[i], c1[i]);
+}
 } finally {
 ir.close();
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Resolved: (IO-96) Test case misuses read(byte[]) and read(char[])

2006-10-11 Thread Stephen Colebourne (JIRA)
 [ http://issues.apache.org/jira/browse/IO-96?page=all ]

Stephen Colebourne resolved IO-96.
--

Resolution: Fixed

 Test case misuses read(byte[]) and read(char[])
 ---

 Key: IO-96
 URL: http://issues.apache.org/jira/browse/IO-96
 Project: Commons IO
  Issue Type: Bug
  Components: Filters, Streams/Writers, Utilities
Affects Versions: 1.2
 Environment: GNU classpath
Reporter: Stephen Colebourne
 Assigned To: Stephen Colebourne
Priority: Minor
 Fix For: 1.3


 Message to mailing list from Anthony Green
 http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg82127.html
 -
 This support routine from the commons-io project test code assumed that
 FileReader.read(byte[]) would always read the entire file.  There's no
 such guarantee, and some tests were failing on GNU Classpath based VMs
 because of this.
 Thanks,
 AG
 --- src/test/org/apache/commons/io/testtools/FileBasedTestCase.java~  
 2006-07-13 23:44:13.0 -0700
 +++ src/test/org/apache/commons/io/testtools/FileBasedTestCase.java   
 2006-07-13 23:44:20.0 -0700
 @@ -167,18 +171,22 @@
  throws IOException
  {
  Reader ir = new java.io.FileReader( file );
 -try {
 -char[] c1 = new char[ c0.length ];
 -int numRead = ir.read( c1 );
 -assertTrue( Different number of bytes, numRead == c0.length );
 -for( int i = 0;
 - i  numRead;
 - assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + 
 c1[ i ] + ), 
 -c0[ i ] == c1[ i ] ), i++
 -);
 -} finally {
 -ir.close();
 -}
 + int count = 0, numRead = 0;
 + char[] c1 = new char[ c0.length ];
 + try {
 +   while (count  c0.length)
 + {
 +   numRead = ir.read( c1, count, c0.length);
 +   for( int i = count;
 +i  count+numRead;
 +assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + 
 c1[ i ] + ), 
 +c0[ i ] == c1[ i ] ), i++
 +);
 +   count += numRead;
 + }
 + } finally {
 +   ir.close();
 + }
  }
  
  protected void checkWrite(OutputStream output) throws Exception {

-- 
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: r462847 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/input/ test/org/apache/commons/io/input/

2006-10-11 Thread scolebourne
Author: scolebourne
Date: Wed Oct 11 09:44:06 2006
New Revision: 462847

URL: http://svn.apache.org/viewvc?view=revrev=462847
Log:
IO-94 - MockInputStream/MockReader

Modified:

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockInputStream.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockReader.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/MockInputStreamTestCase.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/MockReaderTestCase.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/PackageTestSuite.java

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockInputStream.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockInputStream.java?view=diffrev=462847r1=462846r2=462847
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockInputStream.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockInputStream.java
 Wed Oct 11 09:44:06 2006
@@ -38,7 +38,6 @@
  * codeprocessBytes()/code methods can be implemented to generate
  * test data.
  *
- *
  * @since Commons IO 1.3
  * @version $Revision$
  */
@@ -53,7 +52,8 @@
 private boolean markSupported;
 
 /**
- * Create a mock [EMAIL PROTECTED] InputStream} of the specified size.
+ * Create a mock [EMAIL PROTECTED] InputStream} of the specified size
+ * which supports marking and does not throw EOFException.
  *
  * @param size The size of the mock input stream.
  */
@@ -113,7 +113,7 @@
 }
 
 /**
- * Close this inputstream - resets the internal state to
+ * Close this input stream - resets the internal state to
  * the initial values.
  *
  * @throws IOException If an error occurs.
@@ -268,12 +268,12 @@
 /**
  * Return a byte value for the  coderead()/code method.
  * p
- * strongN.B./strong This implementation returns
- * zero.
+ * This implementation returns zero.
  *
  * @return This implementation always returns zero.
  */
 protected int processByte() {
+// do nothing - overridable by subclass
 return 0;
 }
 
@@ -281,14 +281,14 @@
  * Process the bytes for the coderead(byte[], offset, length)/code
  * method.
  * p
- * strongN.B./strong This implementation leaves the byte
- * array unchanged.
+ * This implementation leaves the byte array unchanged.
  *
  * @param bytes The byte array
  * @param offset The offset to start at.
  * @param length The number of bytes.
  */
 protected void processBytes(byte[] bytes, int offset, int length) {
+// do nothing - overridable by subclass
 }
 
 /**
@@ -306,4 +306,5 @@
 }
 return -1;
 }
+
 }

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockReader.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockReader.java?view=diffrev=462847r1=462846r2=462847
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockReader.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/MockReader.java
 Wed Oct 11 09:44:06 2006
@@ -38,7 +38,6 @@
  * codeprocessChars()/code methods can be implemented to generate
  * test data.
  *
- *
  * @since Commons IO 1.3
  * @version $Revision$
  */
@@ -53,7 +52,8 @@
 private boolean markSupported;
 
 /**
- * Create a mock [EMAIL PROTECTED] Reader} of the specified size.
+ * Create a mock [EMAIL PROTECTED] Reader} of the specified size
+ * which supports marking and does not throw EOFException.
  *
  * @param size The size of the mock Reader.
  */
@@ -252,12 +252,12 @@
 /**
  * Return a character value for the  coderead()/code method.
  * p
- * strongN.B./strong This implementation returns
- * zero.
+ * This implementation returns zero.
  *
  * @return This implementation always returns zero.
  */
 protected int processChar() {
+// do nothing - overridable by subclass
 return 0;
 }
 
@@ -265,14 +265,14 @@
  * Process the characters for the coderead(char[], offset, length)/code
  * method.
  * p
- * strongN.B./strong This implementation leaves the character
- * array unchanged.
+ * This implementation leaves the character array unchanged.
  *
  * @param chars The character array
  * @param offset The offset to start at.
  * @param length The number of characters.
  */
 protected void processChars(char[] chars, int offset, int length) {
+// do nothing - 

[jira] Commented: (IO-94) New Mock InputStream Writer implementations

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441493 
] 

Stephen Colebourne commented on IO-94:
--

This feels almost out of scope for [io], which I've always felt was for runtime 
io work.

Is there a use case that isn't as a mock object? Is so, then we can rename it, 
but adding a 'mock' class to a non-mock jar feels wrong.

If it stays, it needs to go in the release notes.

 New Mock InputStream  Writer implementations
 -

 Key: IO-94
 URL: http://issues.apache.org/jira/browse/IO-94
 Project: Commons IO
  Issue Type: New Feature
  Components: Streams/Writers
Reporter: Niall Pemberton
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.3

 Attachments: MockInputStream.java, MockInputStreamTestCase.java


 I have created a MockInputStream which can be plugged in for testing parts of 
 systems where the data doesn't matter - the main use I've had for it was 
 testing large files - without actually having the InputStream process large 
 amounts of bytes.

-- 
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: (IO-82) Test takes a long time to run in Mustang

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441496 
] 

Stephen Colebourne commented on IO-82:
--

This looks a mite dodgy:

while (FileCleaner.getTrackCount() != 0) {
System.gc();
}

JDK1.6 could have altered System.gc to not do anything, thus it takes longer.

Try adding this

int total = 0;
while (FileCleaner.getTrackCount() != 0) {
byte[] b = new byte[1024 * 1024];
b[0] = (byte) System.currentTimeMillis();
total = total + b[0];
System.gc();
}

to waste some memory and kick the gc (I know its just as bad...)


 Test takes a long time to run in Mustang
 

 Key: IO-82
 URL: http://issues.apache.org/jira/browse/IO-82
 Project: Commons IO
  Issue Type: Bug
 Environment: Mustang RC b90 on Linux (x86)
 http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin
Reporter: Henri Yandell
 Fix For: 1.3


 [junit] Running org.apache.commons.io.FileCleanerTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec
 On 1.4.2 on the same machine/checkout, it takes only 1.x seconds.

-- 
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-46) [io] Find file in classpath

2006-10-11 Thread Stephen Colebourne (JIRA)
 [ http://issues.apache.org/jira/browse/IO-46?page=all ]

Stephen Colebourne updated IO-46:
-

  Bugzilla Id:   (was: 38523)
Fix Version/s: 1.4
   (was: 1.3)

Moving to 1.4 as there are issues with different classloaders. Also URL formats 
can get weird in app servers. This needs quite a bit of thought.

 [io] Find file in classpath
 ---

 Key: IO-46
 URL: http://issues.apache.org/jira/browse/IO-46
 Project: Commons IO
  Issue Type: Improvement
  Components: Utilities
Affects Versions: 1.1
 Environment: Operating System: other
 Platform: Other
Reporter: David Leal
Priority: Minor
 Fix For: 1.4


 Just to suggest adding a method like this: 
  public File findFileInClasspath(String fileName) throws 
 FileNotFoundException 
 {
 URL url = getClass().getClassLoader().getResource(fileName);
 if (url == null){
 throw new FileNotFoundException(fileName);
 }
 return new File(url.getFile());
 }

-- 
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: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12441499 
] 

Stephen Colebourne commented on IO-89:
--

Where are we with this? Have you got a finalised proposal? Certainly bug 
squashing and javadoc fixes  are good.

 Inconsistency in SizeFileFilter and AgeFileFilter implementations
 -

 Key: IO-89
 URL: http://issues.apache.org/jira/browse/IO-89
 Project: Commons IO
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
 Fix For: 1.3


 Theres an inconsistency (bug?) in the implementation of SizeFileFilter and 
 AgeFileFilter.
 In SizeFileFilter, using an acceptLarger parameter of true actually accepts 
 files with a size equal to and larger, whereas
 specifying an acceptLarger parameter of false only accepts smaller files.
 The same is true for AgeFileFilter, using an acceptOlder parameter of true 
 actually accepts files either the same age or older, whereas
 specifying an acceptOlder parameter of false only accepts newer files.
 A big benefit of resolving these inconsistencies would mean that creating 
 filters for any condition (i.e. , , =, = or =) becomes
 alot easier. For example if the AgeFileFilter did only do either newer or 
 older, then creating a filters for the same age or older
 or the same age or younger could be done in the following way:
 IOFileFilter equalOlder   = new NotFileFilter(new AgeFileFilter(cutoff, 
 false));
 IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff, 
 true));
 For SizeFileFilter I propose changing the logic to the following:
 if (acceptLarger) {
 return file.length() = size;
 } else {
 return file.length() = size;
 }
 (This would mean that new SizeFileFilter(cutoff) would operate the same way)
 I have added isOlderFile() methods to FileUtils and propose that 
 AgeFileFilter is changed to the following:
 if (acceptOlder) {
 return FileUtils.isFileOlder(file, cutoff);
 } else {
 return FileUtils.isFileNewer(file, cutoff);
 }

-- 
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: [Patch] Fix commons-io test code

2006-10-11 Thread Stephen Colebourne

Raised and fixed as http://issues.apache.org/jira/browse/IO-96 (eventually!)
thanks
Stephen

Anthony Green wrote:

This support routine from the commons-io project test code assumed that
FileReader.read(byte[]) would always read the entire file.  There's no
such guarantee, and some tests were failing on GNU Classpath based VMs
because of this.

Thanks,

AG



--- src/test/org/apache/commons/io/testtools/FileBasedTestCase.java~
2006-07-13 23:44:13.0 -0700
+++ src/test/org/apache/commons/io/testtools/FileBasedTestCase.java 
2006-07-13 23:44:20.0 -0700
@@ -167,18 +171,22 @@
 throws IOException
 {
 Reader ir = new java.io.FileReader( file );
-try {
-char[] c1 = new char[ c0.length ];
-int numRead = ir.read( c1 );
-assertTrue( Different number of bytes, numRead == c0.length );
-for( int i = 0;
- i  numRead;
- assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + c1[ i ] + ), 
-c0[ i ] == c1[ i ] ), i++

-);
-} finally {
-ir.close();
-}
+   int count = 0, numRead = 0;
+   char[] c1 = new char[ c0.length ];
+   try {
+ while (count  c0.length)
+   {
+ numRead = ir.read( c1, count, c0.length);
+ for( int i = count;
+  i  count+numRead;
+		   assertTrue( Byte  + i +  differs ( + c0[ i ] +  !=  + c1[ i ] + ), 
+			   c0[ i ] == c1[ i ] ), i++

+  );
+ count += numRead;
+   }
+   } finally {
+ ir.close();
+   }
 }
 
 protected void checkWrite(OutputStream output) throws Exception {




-
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: svn commit: r462772 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java

2006-10-11 Thread Stephen Colebourne
Maybe we (maven?) runs an older checkstyle, or maybe checkstyle is 
wrong. I'm not fussed about reversion, just noting.


Stephen

Niall Pemberton wrote:

On 10/11/06, Stephen Colebourne [EMAIL PROTECTED] wrote:


[EMAIL PROTECTED] wrote:
 Remove unused import of UnsupportedEncodingException and modify javadoc
references to that class to use fully qualified name.

I wouldn't exactly describe it as unused, as it was used by the javadoc.
I guess our IDEs must differ because this wasn't showing as a problem
for me.



It was flagged on the checkstyle report - I guess a false positive - I
can revert if you prefer.

Niall



Stephen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations

2006-10-11 Thread Niall Pemberton (JIRA)
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12441503 
] 

Niall Pemberton commented on IO-89:
---

My final proposal is actually what I originally proposed, but you pointed out 
earlier the key thing is backward compatibilty. IMO we should fix it because 
I think the inconsistency is a bug. From my point of view theres three options 
here:

1) Fix It - modify as per my original proposal
2) Punt the issue to 1.4 until theres consensus (so it doesn't hold up 1.3)
3) Close it as WONT FIX

 Inconsistency in SizeFileFilter and AgeFileFilter implementations
 -

 Key: IO-89
 URL: http://issues.apache.org/jira/browse/IO-89
 Project: Commons IO
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
 Fix For: 1.3


 Theres an inconsistency (bug?) in the implementation of SizeFileFilter and 
 AgeFileFilter.
 In SizeFileFilter, using an acceptLarger parameter of true actually accepts 
 files with a size equal to and larger, whereas
 specifying an acceptLarger parameter of false only accepts smaller files.
 The same is true for AgeFileFilter, using an acceptOlder parameter of true 
 actually accepts files either the same age or older, whereas
 specifying an acceptOlder parameter of false only accepts newer files.
 A big benefit of resolving these inconsistencies would mean that creating 
 filters for any condition (i.e. , , =, = or =) becomes
 alot easier. For example if the AgeFileFilter did only do either newer or 
 older, then creating a filters for the same age or older
 or the same age or younger could be done in the following way:
 IOFileFilter equalOlder   = new NotFileFilter(new AgeFileFilter(cutoff, 
 false));
 IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff, 
 true));
 For SizeFileFilter I propose changing the logic to the following:
 if (acceptLarger) {
 return file.length() = size;
 } else {
 return file.length() = size;
 }
 (This would mean that new SizeFileFilter(cutoff) would operate the same way)
 I have added isOlderFile() methods to FileUtils and propose that 
 AgeFileFilter is changed to the following:
 if (acceptOlder) {
 return FileUtils.isFileOlder(file, cutoff);
 } else {
 return FileUtils.isFileNewer(file, cutoff);
 }

-- 
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: (IO-94) New Mock InputStream Writer implementations

2006-10-11 Thread Niall Pemberton (JIRA)
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441505 
] 

Niall Pemberton commented on IO-94:
---

I can't think of a use case that isn't as a mock test object. If you do remove 
it then could move it into the test suite?  - I have tests for the IO-84 2GB 
bug that use it.

 New Mock InputStream  Writer implementations
 -

 Key: IO-94
 URL: http://issues.apache.org/jira/browse/IO-94
 Project: Commons IO
  Issue Type: New Feature
  Components: Streams/Writers
Reporter: Niall Pemberton
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.3

 Attachments: MockInputStream.java, MockInputStreamTestCase.java


 I have created a MockInputStream which can be plugged in for testing parts of 
 systems where the data doesn't matter - the main use I've had for it was 
 testing large files - without actually having the InputStream process large 
 amounts of bytes.

-- 
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-86) Add DirectoryWalker based on FileFinder

2006-10-11 Thread Niall Pemberton (JIRA)
 [ http://issues.apache.org/jira/browse/IO-86?page=all ]

Niall Pemberton updated IO-86:
--

Attachment: io-DirectoryWalker-cancellation-3.patch

OK I don't buy the jar size argument :) - but the second point about ignoring 
cancellation requests is valid, which is why I proposed removing those checks 
and the isCancelled() method. You're right though it doesn't leave much - 
except a bit of plumbing that makes it slightly easier for people to implement.

What CancellationException gives you is 1) The ability to trap that behaviour 
and 2) extend the behaviour to pass additional info to the handleCancelled() 
method. I also think that using an exception improves the 
readability/simplicity of the class and gives people the option to choose where 
in the DirectoryWalker structure to implement cancellation decision logic.

Following your comments about exceptions I now think we sould add IOException 
to every method and have the cancel exception extend IOException.

Attaching a patch with what I'd like to see it look like - haven't updated the 
class javadocs or tests, will do if this gets agreement.

 Add DirectoryWalker based on FileFinder
 ---

 Key: IO-86
 URL: http://issues.apache.org/jira/browse/IO-86
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 1.2
Reporter: Niall Pemberton
 Fix For: 1.3

 Attachments: FileFinder.java, FileFinderTestCase.java, 
 io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch


 I'd like to propose adding a FileFinder back into Commons IO. This is a 
 simplified version of what was recently moved out of Commons IO into the 
 finder component currently in the sandbox.
 I believe this is a simpler, more generic implementation than the finder 
 component and therefore would be considered suitable for inclusion in Commons 
 IO. Although simpler it could be used as the basis for achieving the finder 
 component's aims - namely to emulate the unix find command.

-- 
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-86) Add DirectoryWalker based on FileFinder

2006-10-11 Thread Niall Pemberton (JIRA)
 [ http://issues.apache.org/jira/browse/IO-86?page=all ]

Niall Pemberton updated IO-86:
--

Attachment: (was: io-DirectoryWalker-cancellation-2.patch)

 Add DirectoryWalker based on FileFinder
 ---

 Key: IO-86
 URL: http://issues.apache.org/jira/browse/IO-86
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 1.2
Reporter: Niall Pemberton
 Fix For: 1.3

 Attachments: FileFinder.java, FileFinderTestCase.java, 
 io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch


 I'd like to propose adding a FileFinder back into Commons IO. This is a 
 simplified version of what was recently moved out of Commons IO into the 
 finder component currently in the sandbox.
 I believe this is a simpler, more generic implementation than the finder 
 component and therefore would be considered suitable for inclusion in Commons 
 IO. Although simpler it could be used as the basis for achieving the finder 
 component's aims - namely to emulate the unix find command.

-- 
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: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams

2006-10-11 Thread Niall Pemberton (JIRA)
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12441512 
] 

Niall Pemberton commented on IO-84:
---

I'm happy with throwing the exception.

How about the same behaviour in IOUtils - add 2 new copyLarge() methods and 
throw an ArithmeticException in the original copy() methods if they exceed 2GB?

I tried to attach a patch for this but got an error  saying:

Exception trying to establish attachment directory. Check that the application 
server and JIRA have permissions to write to it: 
com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment 
directory. Check that the application server and JIRA have permissions to write 
to: /usr/local/tomcat/tomcat-jira/attachments/IO/IO-84

Something along the following lines though:

public static int copy(InputStream input, OutputStream output)
throws IOException {
long count = copyLarge(input, output);
if (count  (long)Integer.MAX_VALUE) {
throw new ArithmeticException(The byte count  + count +  is too 
large to be converted to an int);
}
return (int)count;
}

public static long copyLarge(InputStream input, OutputStream output)
throws IOException {
byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
long count = 0;
int n = 0;
while (-1 != (n = input.read(buffer))) {
output.write(buffer, 0, n);
count += n;
}
return count;
}


 Many classes are limited to length of stream  2 GB, and behave incorrectly 
 on larger streams
 -

 Key: IO-84
 URL: http://issues.apache.org/jira/browse/IO-84
 Project: Commons IO
  Issue Type: Bug
  Components: Utilities
Affects Versions: 1.2
 Environment: All
Reporter: Evgenii Philippov
 Fix For: 1.3

 Attachments: io-84-files-larger-than-2gb.patch


 java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will 
 behave incorrectly.
 For example, see 
 http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup
 Method: int copy(InputStream input, OutputStream output).
 The correct method would be: long copy(InputStream input, OutputStream 
 output).
 This issue may affect many classes and routines.

-- 
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: (POOL-87) Commons-Pool does not always calling activateObject on newly created Objects

2006-10-11 Thread Bernie McGourty (JIRA)
Commons-Pool does not always calling activateObject on newly created Objects


 Key: POOL-87
 URL: http://issues.apache.org/jira/browse/POOL-87
 Project: Commons Pool
  Issue Type: Bug
 Environment: Windows 2003 Java HotSpot(TM) Client VM (build 
1.5.0_08-b03, mixed mode, sharing)
Reporter: Bernie McGourty


I'm using the GenericObjectPool and a PoolableObjectFactory.

The GenericObjectPool works as expected and documented in that my 
implementation of the PoolableObjectFactory is called according to the 
life-cycle:

1. makeObject is called whenever a new instance is needed. 
2. activateObject is invoked on every instance before it is returned from the 
pool. 
3. passivateObject is invoked on every instance when it is returned to the 
pool. 
4. destroyObject is invoked on every instance when it is being dropped from 
the pool (whether due to the response from validateObject, or for reasons 
specific to the pool implementation.) 5. validateObject is invoked in an 
implementation-specific fashion to determine if an instance is still valid to 
be returned by the pool. It will only be invoked on an activated instance. 

I've set the minimum idle instances to 5 and when the pool goes below 5 
instances, new objects are created to reach the minimum. 

The problem is that the life-cycle is not followed in that makeObject is called 
on the PoolFactory and then validateObject - activateObject is never called. 

The interface doc for validateObject stipulates that it will only be invoked on 
activated objects.

I looked at the GenericObjectPool class and it appears that ensureMinIdle() 
creates the new objects required by calling addObject() but when it calls 
addObjectToPool() the newly created object is never activated before it is 
validated.

I'm using the following pool config:

poolConfig.maxWait= 5000;
poolConfig.maxActive  = 100;
poolConfig.minIdle= 5;
poolConfig.maxIdle= 50;
poolConfig.testOnBorrow   = true;
poolConfig.testOnReturn   = true;
poolConfig.testWhileIdle  = true;
poolConfig.timeBetweenEvictionRunsMillis  = 15000; 
poolConfig.whenExhaustedAction = GenericObjectPool.WHEN_EXHAUSTED_GROW;


-- 
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: r462902 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml: NotificationRegistry.java SCInstance.java SCXMLExecutor.java

2006-10-11 Thread rahul
Author: rahul
Date: Wed Oct 11 12:05:57 2006
New Revision: 462902

URL: http://svn.apache.org/viewvc?view=revrev=462902
Log:
Improving thread-safety for executor instances. Was marked LATER in version 
0.5, where external synchronization is recommended, if needed. Required for 
usecases such as:
 * Delayed send events
 * Certain web applications, AJAX request scenarios
SCXML-2

Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/NotificationRegistry.java

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCInstance.java

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/NotificationRegistry.java?view=diffrev=462902r1=462901r2=462902
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
 Wed Oct 11 12:05:57 2006
@@ -56,7 +56,7 @@
  * @param source The observable this listener wants to listen to
  * @param lst The listener
  */
-void addListener(final Object source,
+synchronized void addListener(final Object source,
 final SCXMLListener lst) {
 Set entries = (Set) regs.get(source);
 if (entries == null) {
@@ -72,7 +72,7 @@
  * @param source The observable this listener wants to stop listening to
  * @param lst The listener
  */
-void removeListener(final Object source,
+synchronized void removeListener(final Object source,
 final SCXMLListener lst) {
 Set entries = (Set) regs.get(source);
 if (entries != null) {
@@ -116,7 +116,7 @@
  * @param source The Observable
  * @param state The TransitionTarget that was entered
  */
-private void fireOnEntry(final Object source,
+private synchronized void fireOnEntry(final Object source,
 final TransitionTarget state) {
 Set entries = (Set) regs.get(source);
 if (entries != null) {
@@ -160,7 +160,7 @@
  * @param source The Observable
  * @param state The TransitionTarget that was exited
  */
-private void fireOnExit(final Object source,
+private synchronized void fireOnExit(final Object source,
 final TransitionTarget state) {
 Set entries = (Set) regs.get(source);
 if (entries != null) {
@@ -209,7 +209,7 @@
  * @param to The destination TransitionTarget
  * @param transition The Transition that was taken
  */
-private void fireOnTransition(final Object source,
+private synchronized void fireOnTransition(final Object source,
 final TransitionTarget from, final TransitionTarget to,
 final Transition transition) {
 Set entries = (Set) regs.get(source);

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCInstance.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCInstance.java?view=diffrev=462902r1=462901r2=462902
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCInstance.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCInstance.java
 Wed Oct 11 12:05:57 2006
@@ -17,6 +17,7 @@
 package org.apache.commons.scxml;
 
 import java.io.Serializable;
+import java.util.Collections;
 import java.util.HashMap;
 import java.util.HashSet;
 import java.util.Map;
@@ -86,10 +87,10 @@
  */
 SCInstance(final SCXMLExecutor executor) {
 this.notificationRegistry = new NotificationRegistry();
-this.contexts = new HashMap();
-this.histories = new HashMap();
-this.invokerClasses = new HashMap();
-this.invokers = new HashMap();
+this.contexts = Collections.synchronizedMap(new HashMap());
+this.histories = Collections.synchronizedMap(new HashMap());
+this.invokerClasses = Collections.synchronizedMap(new HashMap());
+this.invokers = Collections.synchronizedMap(new HashMap());
 this.evaluator = null;
 this.rootContext = null;
 this.executor = executor;

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java?view=diffrev=462902r1=462901r2=462902
==
--- 

svn commit: r462903 - /jakarta/commons/proper/commons-parent/

2006-10-11 Thread jochen
Author: jochen
Date: Wed Oct 11 12:11:29 2006
New Revision: 462903

URL: http://svn.apache.org/viewvc?view=revrev=462903
Log:
Created the commons-parent directory, which ought to hold the Maven 2 POM and 
related resources.

Added:
jakarta/commons/proper/commons-parent/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462904 - /jakarta/commons/proper/commons-parent/trunk/

2006-10-11 Thread jochen
Author: jochen
Date: Wed Oct 11 12:12:26 2006
New Revision: 462904

URL: http://svn.apache.org/viewvc?view=revrev=462904
Log: (empty)

Added:
jakarta/commons/proper/commons-parent/trunk/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462905 - in /jakarta/commons: proper/commons-parent/trunk/pom.xml trunks-proper/pom.xml

2006-10-11 Thread jochen
Author: jochen
Date: Wed Oct 11 12:14:15 2006
New Revision: 462905

URL: http://svn.apache.org/viewvc?view=revrev=462905
Log:
Moving the commons proper POM to the commons-parent directory.

Added:
jakarta/commons/proper/commons-parent/trunk/pom.xml
  - copied unchanged from r462904, jakarta/commons/trunks-proper/pom.xml
Removed:
jakarta/commons/trunks-proper/pom.xml


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r462906 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

2006-10-11 Thread jochen
Author: jochen
Date: Wed Oct 11 12:17:56 2006
New Revision: 462906

URL: http://svn.apache.org/viewvc?view=revrev=462906
Log:
Changed the artifactId to commons-parent.

Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml

Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=462906r1=462905r2=462906
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Wed Oct 11 12:17:56 2006
@@ -7,7 +7,7 @@
  version3/version
   /parent
   groupIdorg.apache.commons/groupId
-  artifactIdcommons/artifactId
+  artifactIdcommons-parent/artifactId
   packagingpom/packaging
   !-- TODO: dummy version. In Maven 2.1, this will be auto-versioned being a 
generic parent --
   version1-SNAPSHOT/version



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [feedparser] Security patch

2006-10-11 Thread Martin van den Bemt

I will apply the patch when no one beats me to it..

Mvgr,
Martin

Nick Lothian wrote:


 I'm aware that FeedParser is a dormant project, but the attached patch
 will fix the same problem in the Apache-Commons project version.

FeedParser def isn't dormant

http://code.tailrank.com/feedparser

I just haven't officially announced that I'm moving it out of Apache.  
Just

been to busy with official work to be a good maintainer :-/



Sorry - I didn't mean to imply that you aren't working on it - I know
you've made the Tailrank stream available.

All I meant was that FeedParser is listed in
http://jakarta.apache.org/commons/dormant/index.html, which I believe
means that no one is actively maintaining the Apache version.

Nick

-
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: r462909 - /jakarta/commons/proper/commons-parent/trunk/

2006-10-11 Thread jochen
Author: jochen
Date: Wed Oct 11 12:30:00 2006
New Revision: 462909

URL: http://svn.apache.org/viewvc?view=revrev=462909
Log:
Added .project to svn:ignore, so that the project can be committed from
within Eclipse without adding Eclipse specific files.

Modified:
jakarta/commons/proper/commons-parent/trunk/   (props changed)

Propchange: jakarta/commons/proper/commons-parent/trunk/
--
--- svn:ignore (added)
+++ svn:ignore Wed Oct 11 12:30:00 2006
@@ -0,0 +1 @@
+.project



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Logging: SimpleLog not thread-safe

2006-10-11 Thread Kenneth Xu
Hi,

I think a thread local formatter will give us better performance than
creating one new in every log invocation.

Just my 2 cents,

Thanks,
Ken

-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 11, 2006 5:05 AM
To: Jakarta Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe

Hi Martin,

Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue. 

SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect would usually just
result in a malformed date string which may not be noticed anyway.

But it should be fixed; I'll try to do that this weekend.

Regards,

Simon

On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
 Hi,
  
 I'm not sure if anyone else uses the SimpleLog class - anyway I've
 noticed that SimpleLog.log is not thread-safe. The following code
 (starting on line 282):
  
 if(showDateTime) {
 buf.append(dateFormatter.format(new Date()));
 buf.append( );
 }
  
 makes an unsynchronized call to dateFormatter.format. As dateFormatter
 is an instance variable, and DateFormat.format is not thread-safe, this
 will cause problems if more than one thread tried to log at the same
 time.
  
 Solution: remove the dateFormatter instance variable and instantiate a
 new DateFormat each time in the log method, e.g.
  
 DateFormat dateFormatter = null;
 try {
 dateFormatter = new
 SimpleDateFormat(dateTimeFormat);
 }
 catch(IllegalArgumentException e) {
 dateFormatter = new
 SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
 }  
  
 Is anyone available who could make this change?
  
 Thanks, 
 Martin

 ___
 
 Martin Wilson
 [EMAIL PROTECTED]
 
 Bright Interactive: successfully delivering interactive websites and
 business applications
  http://www.bright-interactive.com/ http://www.bright-interactive.com
 0870 240 6520
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12441574 
] 

Stephen Colebourne commented on IO-89:
--

I can see a javadoc fix as being valid here, but I don't believe we can change 
= to . I also wonder how often the full variety of operators is needed.

I'm happy if you want to propose out a complete and more advanced solution with 
all the operators, but for now, I think we should just javadoc this (including 
the method params if possible).


 Inconsistency in SizeFileFilter and AgeFileFilter implementations
 -

 Key: IO-89
 URL: http://issues.apache.org/jira/browse/IO-89
 Project: Commons IO
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
 Fix For: 1.3


 Theres an inconsistency (bug?) in the implementation of SizeFileFilter and 
 AgeFileFilter.
 In SizeFileFilter, using an acceptLarger parameter of true actually accepts 
 files with a size equal to and larger, whereas
 specifying an acceptLarger parameter of false only accepts smaller files.
 The same is true for AgeFileFilter, using an acceptOlder parameter of true 
 actually accepts files either the same age or older, whereas
 specifying an acceptOlder parameter of false only accepts newer files.
 A big benefit of resolving these inconsistencies would mean that creating 
 filters for any condition (i.e. , , =, = or =) becomes
 alot easier. For example if the AgeFileFilter did only do either newer or 
 older, then creating a filters for the same age or older
 or the same age or younger could be done in the following way:
 IOFileFilter equalOlder   = new NotFileFilter(new AgeFileFilter(cutoff, 
 false));
 IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff, 
 true));
 For SizeFileFilter I propose changing the logic to the following:
 if (acceptLarger) {
 return file.length() = size;
 } else {
 return file.length() = size;
 }
 (This would mean that new SizeFileFilter(cutoff) would operate the same way)
 I have added isOlderFile() methods to FileUtils and propose that 
 AgeFileFilter is changed to the following:
 if (acceptOlder) {
 return FileUtils.isFileOlder(file, cutoff);
 } else {
 return FileUtils.isFileNewer(file, cutoff);
 }

-- 
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: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12441575 
] 

Stephen Colebourne commented on IO-84:
--

I'm happy with these IOUtils additions, so feel free to commit if you get a 
chance.

 Many classes are limited to length of stream  2 GB, and behave incorrectly 
 on larger streams
 -

 Key: IO-84
 URL: http://issues.apache.org/jira/browse/IO-84
 Project: Commons IO
  Issue Type: Bug
  Components: Utilities
Affects Versions: 1.2
 Environment: All
Reporter: Evgenii Philippov
 Fix For: 1.3

 Attachments: io-84-files-larger-than-2gb.patch


 java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will 
 behave incorrectly.
 For example, see 
 http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup
 Method: int copy(InputStream input, OutputStream output).
 The correct method would be: long copy(InputStream input, OutputStream 
 output).
 This issue may affect many classes and routines.

-- 
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: (IO-86) Add DirectoryWalker based on FileFinder

2006-10-11 Thread Stephen Colebourne (JIRA)
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441581 
] 

Stephen Colebourne commented on IO-86:
--

This is beginning to feel like a can of worms.

With the exception/handleCancelled combination, why do we need handleCancelled? 
We are asking the user to write all the logic to determmine cancellation and 
handle it by throwing the exception, so why not handle the cancellation fully 
at that point? Is there enough benefit to justify the combination?

Also, I think that there may be a hidden danger/issue. A user writing a public 
cancel method to be called in another thread may just throw 
CancellationException and expect the operation to end, which of course it 
won't. Instead, they have to write all the boolean handling logic to trap in 
the directory and file levels of the looping. My point here is that while an 
exception is probably the right design choice in a single-threaded world for 
this problem, it doesn't strike me as such in a muti-threaded world.

Perhaps this can be javadoced so users only throw CancellationException from 
the right thread, but it surely makes the class riskier.

You are correct though in saying that it would allow more data to be 
transferred to handleCancelled(). This can be worked around using instance 
variables in the subclass, or handling at the point of identifying the problem. 
At this point, we hit a problem of not having real-life users yet.

So, my preferred solution is to add the boolean cancelled field to 
DirectoryWalker together with a setCancelled(boolean) method. This means a full 
cancel solution is provided (which is a nice value add for the class), and 
documented, but doesn't prevent a subclass using an exception to achieve the 
same effect if it desires.

 Add DirectoryWalker based on FileFinder
 ---

 Key: IO-86
 URL: http://issues.apache.org/jira/browse/IO-86
 Project: Commons IO
  Issue Type: New Feature
  Components: Utilities
Affects Versions: 1.2
Reporter: Niall Pemberton
 Fix For: 1.3

 Attachments: FileFinder.java, FileFinderTestCase.java, 
 io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch


 I'd like to propose adding a FileFinder back into Commons IO. This is a 
 simplified version of what was recently moved out of Commons IO into the 
 finder component currently in the sandbox.
 I believe this is a simpler, more generic implementation than the finder 
 component and therefore would be considered suitable for inclusion in Commons 
 IO. Although simpler it could be used as the basis for achieving the finder 
 component's aims - namely to emulate the unix find command.

-- 
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]