Re: [vfs][all] move vfs to maven 2 to setup a vfs-sandbox
Hi Torsten! ...so the real question is is it ok to have a proper component use maven2 ...right? hehe didn't I ask this? Yes, thats the real question! As a compromise I can maintain the maven 1 build for the core only (using the maven 2 directory layout), and a maven 2 build for the core/sandbox stuff. That also allows me to e.g. build the site with maven 1 as long as Commons haven't moved to maven 2 at all. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging: SimpleLog not thread-safe
HI, On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote: Yes, it'll be GC'ed when thread is. And initialized when first use in a new thread. Here is the test code: But if an application has long-running threads then the object won't be recycled until the thread dies. So an app with 100 threads has 100 SimpleDateFormat objects long-term. And as James noted, when using frameworks like Application Servers, threads could be pooled in unexpected ways. I also suspect that in order to fetch data from a ThreadLocal, the JVM effectively performs a get on a synchronised map, ie that ThreadLocal is not much more efficient than having a synchronised static DateFormat on SimpleLog (nb: I have no proof of this, just a hunch). I think the easiest most reliable solution is to simply create a SimpleDateFormat object in the method that needs it. Note that this is only done after it has been determined that a message *will* be output, which in most cases means that there will be disk io that will have far more impact on the system than creating a simple object. Optimising the path in commons-logging that determines *if* a message is to be logged is important; optimising the actual logging operation is much less critical. Of course I'm open to persuasion on this (eg performance stats).. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
You could just take a private copy of FastDateFormat from commons-lang which is thread-safe. Might bloat your jar-file size though. Stephen Simon Kitching wrote: HI, On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote: Yes, it'll be GC'ed when thread is. And initialized when first use in a new thread. Here is the test code: But if an application has long-running threads then the object won't be recycled until the thread dies. So an app with 100 threads has 100 SimpleDateFormat objects long-term. And as James noted, when using frameworks like Application Servers, threads could be pooled in unexpected ways. I also suspect that in order to fetch data from a ThreadLocal, the JVM effectively performs a get on a synchronised map, ie that ThreadLocal is not much more efficient than having a synchronised static DateFormat on SimpleLog (nb: I have no proof of this, just a hunch). I think the easiest most reliable solution is to simply create a SimpleDateFormat object in the method that needs it. Note that this is only done after it has been determined that a message *will* be output, which in most cases means that there will be disk io that will have far more impact on the system than creating a simple object. Optimising the path in commons-logging that determines *if* a message is to be logged is important; optimising the actual logging operation is much less critical. Of course I'm open to persuasion on this (eg performance stats).. Cheers, Simon - 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: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=comments#action_12442273 ] Stephen Colebourne commented on LANG-285: - Sounds interesting. Does the uniode handling in Java provide this info? Perhaps on the Character class. Wish : method unaccent -- Key: LANG-285 URL: http://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor I would like to add a method that replace accented caracter by unaccented one. For example, with the input String L'été où j'ai dû aller à l'île d'Anticosti commenca tôt, the method would return L'ete ou j'ai du aller à l'ile d'Anticosti commenca tot. I suggest to call that method unaccent and to add it in StringUtils. If we cannot covert all case, the first version could only covert iso-8859-1. If you are willing to go forward with that idea, I am willing to contribute a patch. -- 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: commons-finder status?
This became the class DirectoryWalker in commons-io SVN (unreleased). DirectoryWalker is still being worked on, but the class is functional as-is. Stephen Joshua ChaitinPollak wrote: Hello, I am interested in using Commons Finder or something similar. Is someone using this code or is it rather stagnant? Specifically, I am using the Oct-12 nightly build (combined with the commons-io 1.2 release) and I am having trouble executing my code because of NoClassDefFoundErrors. It seems the FileFinder class refers to a few common-io classes (WildcardFileFilter, EmptyFileFinder, HiddenFileFilter, etc) which do not exist, do not exist in the 1.1 io release, and do not exist in the current SVN (according to the Javadocs) I'm wondering if anyone has any idea where these extra classes went, and if there is an alternative to commons-finder that works well? Specifically I need to recursively search through directories looking for files based on age. Thanks, -Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-14102006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 39 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14102006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.536 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.592 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.975 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.611 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.549 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.591 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.597 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.745 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.764 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.726 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.508 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.541 sec [junit] Running org.apache.commons.id.uuid.NodeManagerImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.803 sec [junit] Running org.apache.commons.id.uuid.UUIDTest [junit] Tests run: 17, Failures: 0, Errors:
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-14102006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 39 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14102006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.536 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.592 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.975 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.611 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.549 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.591 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.597 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.745 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.764 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.726 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.508 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.541 sec [junit] Running org.apache.commons.id.uuid.NodeManagerImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.803 sec [junit] Running org.apache.commons.id.uuid.UUIDTest [junit] Tests run: 17, Failures: 0, Errors:
svn commit: r463909 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Author: scolebourne
Date: Sat Oct 14 03:20:27 2006
New Revision: 463909
URL: http://svn.apache.org/viewvc?view=revrev=463909
Log:
Add serial version id and unify javadoc
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java?view=diffrev=463909r1=463908r2=463909
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Sat Oct 14 03:20:27 2006
@@ -415,7 +415,7 @@
*
* @param startDirectory the directory to start from
* @param results the collection of result objects, may be updated
- * @param cancel The exception throw to cancel further processing
+ * @param cancel the exception throw to cancel further processing
* containing details at the point of cancellation.
* @throws IOException if an I/O Error occurs
*/
@@ -431,15 +431,20 @@
*/
public static class CancelException extends IOException {
+/** Serialization id. */
+private static final long serialVersionUID = 1347339620135041008L;
+
+/** The file being processed when the exception was thrown. */
private File file;
+/** The file depth when the exception was thrown. */
private int depth = -1;
/**
* Constructs a codeCancelException/code with
* the file and depth when cancellation occurred.
*
- * @param file The file when the operation was cancelled
- * @param depth The depth when the operation was cancelled
+ * @param file the file when the operation was cancelled, may be null
+ * @param depth the depth when the operation was cancelled, may be
null
*/
public CancelException(File file, int depth) {
this(Operation Cancelled, file, depth);
@@ -450,9 +455,9 @@
* an appropriate message and the file and depth when
* cancellation occurred.
*
- * @param message The detail message.
- * @param file The file when the operation was cancelled
- * @param depth The depth when the operation was cancelled
+ * @param message the detail message
+ * @param file the file when the operation was cancelled
+ * @param depth the depth when the operation was cancelled
*/
public CancelException(String message, File file, int depth) {
super(message);
@@ -463,7 +468,7 @@
/**
* Return the file when the operation was cancelled.
*
- * @return The file when the operation was cancelled
+ * @return the file when the operation was cancelled
*/
public File getFile() {
return file;
@@ -472,7 +477,7 @@
/**
* Return the depth when the operation was cancelled.
*
- * @return The depth when the operation was cancelled
+ * @return the depth when the operation was cancelled
*/
public int getDepth() {
return depth;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-94) New NullnputStream NullReader implementations
[ http://issues.apache.org/jira/browse/IO-94?page=all ] Stephen Colebourne closed IO-94. Resolution: Fixed New NullnputStream NullReader 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]
svn commit: r463913 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Author: scolebourne
Date: Sat Oct 14 04:08:13 2006
New Revision: 463913
URL: http://svn.apache.org/viewvc?view=revrev=463913
Log:
Spelling, javadoc, variable names
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java?view=diffrev=463913r1=463912r2=463913
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Sat Oct 14 04:08:13 2006
@@ -141,7 +141,7 @@
* scenarios.
*
* a name=external/a
- * h43.1 External / Mult-threaded/h4
+ * h43.1 External / Multi-threaded/h4
*
* This example provides a codecancel()/code method for external processes
to
* indcate that processing must stop. Calling this method sets a
@@ -289,15 +289,16 @@
handleDirectoryStart(directory, depth, results);
int childDepth = depth + 1;
if (depthLimit 0 || childDepth = depthLimit) {
-File[] files = (filter == null ? directory.listFiles() :
directory.listFiles(filter));
-if (files == null) {
+File[] childFiles = (filter == null ? directory.listFiles() :
directory.listFiles(filter));
+if (childFiles == null) {
handleRestricted(directory, childDepth, results);
} else {
-for (int i = 0; i files.length; i++) {
-if (files[i].isDirectory()) {
-walk(files[i], childDepth, results);
+for (int i = 0; i childFiles.length; i++) {
+File childFile = childFiles[i];
+if (childFile.isDirectory()) {
+walk(childFile, childDepth, results);
} else {
-handleFile(files[i], childDepth, results);
+handleFile(childFile, childDepth, results);
}
}
}
@@ -410,6 +411,8 @@
/**
* Overridable callback method invoked when the operation is cancelled.
+ * The file being processed when the cancellation occurred can be
+ * obtained from the exception.
* p
* This implementation just re-throws the [EMAIL PROTECTED]
CancelException}.
*
@@ -425,6 +428,7 @@
throw cancel;
}
+//---
/**
* CancelException is thrown in DirectoryWalker to cancel the current
* processing.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 45 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-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14102006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-14102006.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
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 45 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-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14102006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14102006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14102006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-14102006.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: Logging: SimpleLog not thread-safe
Tomcat had this same issue a while back. It was trying to use a single SimpleDateFormat object to parse/format date-valued HTTP headers. I submitted the patch for it and I think we decided to just instantiate as needed. Local variables are garbage collected much more reliably from what I understand. And, as Simon pointed out, the probable disk i/o would be the big bottleneck, not the object instantiation. You could just take a private copy of FastDateFormat from commons-lang which is thread-safe. Might bloat your jar-file size though. Stephen Simon Kitching wrote: HI, On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote: Yes, it'll be GC'ed when thread is. And initialized when first use in a new thread. Here is the test code: But if an application has long-running threads then the object won't be recycled until the thread dies. So an app with 100 threads has 100 SimpleDateFormat objects long-term. And as James noted, when using frameworks like Application Servers, threads could be pooled in unexpected ways. I also suspect that in order to fetch data from a ThreadLocal, the JVM effectively performs a get on a synchronised map, ie that ThreadLocal is not much more efficient than having a synchronised static DateFormat on SimpleLog (nb: I have no proof of this, just a hunch). I think the easiest most reliable solution is to simply create a SimpleDateFormat object in the method that needs it. Note that this is only done after it has been determined that a message *will* be output, which in most cases means that there will be disk io that will have far more impact on the system than creating a simple object. Optimising the path in commons-logging that determines *if* a message is to be logged is important; optimising the actual logging operation is much less critical. Of course I'm open to persuasion on this (eg performance stats).. Cheers, Simon - 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] James Carman, President Carman Consulting, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-39) [VFS] read/write XML support
[ http://issues.apache.org/jira/browse/VFS-39?page=all ]
Benoit Callebaut updated VFS-39:
Attachment: vfs.patch
This patch against the head SVN is not tested.
Previous was tested so I don't expect any problem.
Implementation notes:
Added a new FileType bacause an XML node can have mixed content (XML tags +
text). The new FileType is a File and a Folder at the same type (can contain
files and datas)
Slighly changed methods declarations to stick to to the
doGetAttributes/doSetAttributes of AbstractFileObject.
[VFS] read/write XML support
Key: VFS-39
URL: http://issues.apache.org/jira/browse/VFS-39
Project: Commons VFS
Issue Type: Improvement
Affects Versions: Nightly Builds
Environment: Operating System: other
Platform: Other
Reporter: Benoit Callebaut
Priority: Minor
Attachments: package.html, patchfile, test.xml, vfs.patch,
VFSXmlFileObject.java, VFSXmlFileProvider.java, VFSXmlFileSystem.java
Here is the patch and necessary files for adding XML support for VFS.
I don't know how to include new files in a patch, so I will put them on the
mailing list.
I am not a test writer specialist, so there is no specific test case for this
provider but I tested it and it works.
Index: vfs/src/test/org/apache/commons/vfs/RunTest.java
===
--- vfs/src/test/org/apache/commons/vfs/RunTest.java(revision 404758)
+++ vfs/src/test/org/apache/commons/vfs/RunTest.java(working copy)
@@ -26,6 +26,7 @@
import org.apache.commons.vfs.provider.url.test.UrlProviderHttpTestCase;
import org.apache.commons.vfs.provider.test.VirtualProviderTestCase;
import org.apache.commons.vfs.provider.test.GenericFileNameTestCase;
+import org.apache.commons.vfs.provider.xml.test.XmlProviderTestCase;
import java.util.Properties;
@@ -67,6 +68,7 @@
// WebdavProviderTestCase.suite(),
SftpProviderTestCase.suite(),
+ XmlProviderTestCase.suite(),
// JarProviderTestCase.suite(),
// NestedJarTestCase.suite(),
Index: vfs/src/java/org/apache/commons/vfs/impl/providers.xml
===
--- vfs/src/java/org/apache/commons/vfs/impl/providers.xml (revision
404758)
+++ vfs/src/java/org/apache/commons/vfs/impl/providers.xml (working copy)
@@ -51,6 +51,9 @@
provider
class-name=org.apache.commons.vfs.provider.res.ResourceFileProvider
scheme name=res/
/provider
+provider
class-name=org.apache.commons.vfs.provider.xml.VFSXmlFileProvider
+scheme name=xml/
+/provider
!--
provider
class-name=org.apache.commons.vfs.provider.tar.TgzFileProvider
scheme name=tgz/
@@ -78,8 +81,10 @@
scheme name=ram/
/provider
+extension-map extension=xml scheme=xml/
extension-map extension=zip scheme=zip/
extension-map extension=tar scheme=tar/
+mime-type-map mime-type=application/xml scheme=xml/
mime-type-map mime-type=application/zip scheme=zip/
mime-type-map mime-type=application/x-tar scheme=tar/
mime-type-map mime-type=application/x-gzip scheme=gz/
Index: vfs/src/java/org/apache/commons/vfs/FileType.java
===
--- vfs/src/java/org/apache/commons/vfs/FileType.java (revision 404758)
+++ vfs/src/java/org/apache/commons/vfs/FileType.java (working copy)
@@ -46,7 +46,7 @@
private final boolean hasContent;
private final boolean hasAttrs;
-private FileType(final String name,
+public FileType(final String name,
final boolean hasChildren,
final boolean hasContent,
final boolean hasAttrs)
@@ -96,4 +96,14 @@
{
return hasAttrs;
}
+
+public boolean equals(Object obj){
+if (!(obj instanceof FileType)) return false;
+FileType ob = (FileType)obj;
+if (this.hasContent() ob.hasContent()) return true;
+if (this.hasChildren() ob.hasChildren()) return true;
+if (this.hasAttributes() ob.hasAttributes()) return true;
+
+return false;
+}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Old comment sent by email ... entries
Anyone know what these are about? TIA, -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r463940 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/filefilter/FileFilterUtils.java src/test/org/apache/commons/io/filefilter/FileFilterTestCase
Author: scolebourne
Date: Sat Oct 14 07:20:25 2006
New Revision: 463940
URL: http://svn.apache.org/viewvc?view=revrev=463940
Log:
FileFilterUtils.makeDirectoryOnly/makeFileOnly
- two new methods that decorate a file filter to make it apply to directories
only or files only
Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.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=463940r1=463939r2=463940
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Sat Oct 14 07:20:25 2006
@@ -139,9 +139,13 @@
(whereas if everything uses INSTANCE, then they just clash)
- The old INSTANCE constants are still present and have not been deprecated
-- FileFilterUtils
+- FileFilterUtils.sizeRangeFileFilter
- new sizeRangeFileFilter(long minimumSize, long maximumSize) method which
creates a filter that accepts files within the specified size range.
+
+- FileFilterUtils.makeDirectoryOnly/makeFileOnly
+ - two new methods that decorate a file filter to make it apply to
+directories only or files only
- NullWriter
- New writer that acts as a sink for all data, as per /dev/null
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java?view=diffrev=463940r1=463939r2=463940
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
Sat Oct 14 07:20:25 2006
@@ -218,7 +218,6 @@
}
//---
-
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
@@ -330,6 +329,35 @@
IOFileFilter minimumFilter = new SizeFileFilter(minSizeInclusive,
true);
IOFileFilter maximumFilter = new SizeFileFilter(maxSizeInclusive + 1L,
false);
return new AndFileFilter(minimumFilter, maximumFilter);
+}
+
+//---
+/**
+ * Decorates a filter so that it only applies to directories and not to
files.
+ *
+ * @param filter the filter to decorate, null means an unrestricted filter
+ * @return the decorated filter, never null
+ * @since 1.3
+ */
+public static IOFileFilter makeDirectoryOnly(IOFileFilter filter) {
+if (filter == null) {
+return DirectoryFileFilter.DIRECTORY;
+}
+return new AndFileFilter(DirectoryFileFilter.DIRECTORY, filter);
+}
+
+/**
+ * Decorates a filter so that it only applies to files and not to
directories.
+ *
+ * @param filter the filter to decorate, null means an unrestricted filter
+ * @return the decorated filter, never null
+ * @since 1.3
+ */
+public static IOFileFilter makeFileOnly(IOFileFilter filter) {
+if (filter == null) {
+return FileFileFilter.FILE;
+}
+return new AndFileFilter(FileFileFilter.FILE, filter);
}
}
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?view=diffrev=463940r1=463939r2=463940
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Sat Oct 14 07:20:25 2006
@@ -736,5 +736,62 @@
FileUtils.forceDelete(emptyDir);
}
+//---
+public void testMakeDirectoryOnly() throws Exception {
+assertSame(DirectoryFileFilter.DIRECTORY,
FileFilterUtils.makeDirectoryOnly(null));
+
+IOFileFilter filter = FileFilterUtils.makeDirectoryOnly(
+FileFilterUtils.nameFileFilter(B));
+
+File fileA = new File(getTestDirectory(), A);
+File fileB = new File(getTestDirectory(), B);
+
+fileA.mkdirs();
+fileB.mkdirs();
+
+assertFiltering(filter,
svn commit: r463941 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
Author: scolebourne
Date: Sat Oct 14 07:24:29 2006
New Revision: 463941
URL: http://svn.apache.org/viewvc?view=revrev=463941
Log:
Javadoc and Group filter decoration methods together in the source file
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java?view=diffrev=463941r1=463940r2=463941
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
Sat Oct 14 07:24:29 2006
@@ -168,56 +168,6 @@
}
//---
-
-/* Constructed on demand and then cached */
-private static IOFileFilter cvsFilter;
-
-/* Constructed on demand and then cached */
-private static IOFileFilter svnFilter;
-
-/**
- * Returns an IOFileFilter that ignores CVS directories. You may optionally
- * pass in an existing IOFileFilter in which case it is extended to exclude
- * CVS directories.
- * @param filter IOFileFilter to wrap, null if a new IOFileFilter
- * should be created
- * @return the requested (combined) filter
- * @since 1.1 (method existed but had bug in 1.0)
- */
-public static IOFileFilter makeCVSAware(IOFileFilter filter) {
-if (cvsFilter == null) {
-cvsFilter = notFileFilter(
-andFileFilter(directoryFileFilter(), nameFileFilter(CVS)));
-}
-if (filter == null) {
-return cvsFilter;
-} else {
-return andFileFilter(filter, cvsFilter);
-}
-}
-
-/**
- * Returns an IOFileFilter that ignores SVN directories. You may optionally
- * pass in an existing IOFileFilter in which case it is extended to exclude
- * SVN directories.
- * @param filter IOFileFilter to wrap, null if a new IOFileFilter
- * should be created
- * @return the requested (combined) filter
- * @since 1.1
- */
-public static IOFileFilter makeSVNAware(IOFileFilter filter) {
-if (svnFilter == null) {
-svnFilter = notFileFilter(
-andFileFilter(directoryFileFilter(), nameFileFilter(.svn)));
-}
-if (filter == null) {
-return svnFilter;
-} else {
-return andFileFilter(filter, svnFilter);
-}
-}
-
-//---
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
@@ -329,6 +279,55 @@
IOFileFilter minimumFilter = new SizeFileFilter(minSizeInclusive,
true);
IOFileFilter maximumFilter = new SizeFileFilter(maxSizeInclusive + 1L,
false);
return new AndFileFilter(minimumFilter, maximumFilter);
+}
+
+//---
+/* Constructed on demand and then cached */
+private static IOFileFilter cvsFilter;
+
+/* Constructed on demand and then cached */
+private static IOFileFilter svnFilter;
+
+/**
+ * Decorates a filter to make it ignore CVS directories.
+ * Passing in codenull/code will return a filter that accepts
everything
+ * except CVS directories.
+ *
+ * @param filter the filter to decorate, null means an unrestricted filter
+ * @return the decorated filter, never null
+ * @since 1.1 (method existed but had bug in 1.0)
+ */
+public static IOFileFilter makeCVSAware(IOFileFilter filter) {
+if (cvsFilter == null) {
+cvsFilter = notFileFilter(
+andFileFilter(directoryFileFilter(), nameFileFilter(CVS)));
+}
+if (filter == null) {
+return cvsFilter;
+} else {
+return andFileFilter(filter, cvsFilter);
+}
+}
+
+/**
+ * Decorates a filter to make it ignore SVN directories.
+ * Passing in codenull/code will return a filter that accepts
everything
+ * except SVN directories.
+ *
+ * @param filter the filter to decorate, null means an unrestricted filter
+ * @return the decorated filter, never null
+ * @since 1.1
+ */
+public static IOFileFilter makeSVNAware(IOFileFilter filter) {
+if (svnFilter == null) {
+svnFilter = notFileFilter(
+andFileFilter(directoryFileFilter(), nameFileFilter(.svn)));
+}
+if (filter == null) {
+return svnFilter;
+} else {
+return andFileFilter(filter, svnFilter);
+}
}
svn commit: r463942 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/DirectoryWalker.java test/org/apache/commons/io/DirectoryWalkerTestCase.java
Author: scolebourne
Date: Sat Oct 14 07:26:28 2006
New Revision: 463942
URL: http://svn.apache.org/viewvc?view=revrev=463942
Log:
Add constructor to take directory and file filters separately
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/DirectoryWalkerTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java?view=diffrev=463942r1=463941r2=463942
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Sat Oct 14 07:26:28 2006
@@ -21,6 +21,10 @@
import java.io.IOException;
import java.util.Collection;
+import org.apache.commons.io.filefilter.FileFilterUtils;
+import org.apache.commons.io.filefilter.IOFileFilter;
+import org.apache.commons.io.filefilter.TrueFileFilter;
+
/**
* Abstract class that walks through a directory hierarchy and provides
* subclasses with convenient hooks to add specific behaviour.
@@ -80,14 +84,28 @@
* a name=filter/a
* h32. Filter Example/h3
*
- * If you wanted all directories which are not hidden
- * and files which end in .txt - you could build a composite filter
- * using the filter implementations in the Commons IO
- * a href=filefilter/package-summary.htmlfilefilter/a package
- * in the following way:
- *
+ * Choosing which directories and files to process can be a key aspect
+ * of using this class. This information can be setup in three ways,
+ * via three different constructors.
+ * p
+ * The first option is to visit all directories and files.
+ * This is achieved via the no-args constructor.
+ * p
+ * The second constructor option is to supply a single [EMAIL PROTECTED]
FileFilter}
+ * that describes the files and directories to visit. Care must be taken
+ * with this option as the same filter is used for both directories
+ * and files.
+ * p
+ * For example, if you wanted all directories which are not hidden
+ * and files which end in .txt:
* pre
- *
+ * public class FooDirectoryWalker extends DirectoryWalker {
+ *public FooDirectoryWalker(FileFilter filter) {
+ * super(filter, -1);
+ *}
+ * }
+ *
+ * // Build up the filters and create the walker
*// Create a filter for Non-hidden directories
*IOFileFilter fooDirFilter =
*FileFilterUtils.andFileFilter(FileFilterUtils.directoryFileFilter,
@@ -103,9 +121,32 @@
*FileFilterUtils.orFileFilter(fooDirFilter, fooFileFilter);
*
*// Use the filter to construct a DirectoryWalker implementation
- *FooDirectoryWalker walker = new FooDirectoryWalker(fooFilter, -1);
- *
+ *FooDirectoryWalker walker = new FooDirectoryWalker(fooFilter);
* /pre
+ * p
+ * The third constructor option is to specify separate filters, one for
+ * directories and one for files. These are combined internally to form
+ * the correct codeFileFilter/code, something which is very easy to
+ * get wrong when attempted manually, particularly when trying to
+ * express constructs like 'any file in directories named docs'.
+ * p
+ * For example, if you wanted all directories which are not hidden
+ * and files which end in .txt:
+ * pre
+ * public class FooDirectoryWalker extends DirectoryWalker {
+ *public FooDirectoryWalker(IOFileFilter dirFilter, IOFileFilter
fileFilter) {
+ * super(dirFilter, fileFilter, -1);
+ *}
+ * }
+ *
+ * // Use the filters to construct the walker
+ * FooDirectoryWalker walker = new FooDirectoryWalker(
+ *HiddenFileFilter.VISIBLE,
+ *FileFilterUtils.suffixFileFilter(.txt),
+ * );
+ * pre
+ * This is much simpler than the previous example, and is why it is the
preferred
+ * option for filtering.
*
* a name=cancel/a
* h33. Cancellation/h3
@@ -145,8 +186,8 @@
*
* This example provides a codecancel()/code method for external processes
to
* indcate that processing must stop. Calling this method sets a
- * a
href=http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#36930;
- * volatile/a flag to (hopefully) ensure it will work properly in
+ * a
href=http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#36930;volatile/a
+ * flag to (hopefully) ensure it will work properly in
* a multi-threaded environment. In this implementation the flag is checked in
two
* of the lifecycle methods using a convenience
codecheckIfCancelled()/code method
* which throws a [EMAIL PROTECTED] CancelException} if cancellation has been
requested.
@@ -237,13 +278,45 @@
/**
* Construct an instance with a filter and limit the idepth/i
navigated to.
+ * p
+ * The filter controls which
[jira] Commented: (CONFIGURATION-231) documentation: Get string returns null?
[ http://issues.apache.org/jira/browse/CONFIGURATION-231?page=comments#action_12442298 ] Oliver Heger commented on CONFIGURATION-231: You are right, the information you mention is not easily to find. WDYT, would @see tags in the javadoc be appropriate that point to related methods like setThrowExceptionOnMissing() or setListDelimiter()? Or where would be the best way to place this information? documentation: Get string returns null? --- Key: CONFIGURATION-231 URL: http://issues.apache.org/jira/browse/CONFIGURATION-231 Project: Commons Configuration Issue Type: Improvement Reporter: Thomas Wabner Some open documentation issues: In the current documentation (1.3) there is for the Configuration#getString() method not documented, of this method returns a null string, if no value for the key was found. It should also be documented, if the given key can be null or not. For example if I can give a null key, null will be returned would be enough in this case. Configuration#getStringArray point not to a documentation (or gives no hint), that there is a way to configure the seperator for keys. Would be nice to have this in this place with a link to the seperator stuff. -- 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: (CONFIGURATION-230) XPathExpressionEngine nodeKey method create a wrong key for attribute node
[
http://issues.apache.org/jira/browse/CONFIGURATION-230?page=comments#action_12442299
]
Oliver Heger commented on CONFIGURATION-230:
Do you have a code snippet (or even better a unit test) that demonstrates the
problem? We need to expose the bug first, so that we can verify that it is
resolved by the fix.
Thanks.
XPathExpressionEngine nodeKey method create a wrong key for attribute node
--
Key: CONFIGURATION-230
URL: http://issues.apache.org/jira/browse/CONFIGURATION-230
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Any
Reporter: Andy Yeung
In org.apache.commons.configuration.tree.xpath.XPathExpressionEngine line 178
if (node.isAttribute())
{
buf.append(ATTR_DELIMITER);
}
should be changed to
if (node.isAttribute()) {
buf.append(NODE_PATH_DELIMITERS);
}
Using ATTR_DELIMITER will create key like [EMAIL PROTECTED] rather than
element/@attribute and make config reload fail.
--
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
[ http://issues.apache.org/jira/browse/LANG-284?page=all ] David Leal updated LANG-284: Attachment: TestTextTable.out Sample output 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: TestTextTable.out, 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]
[jira] Updated: (LANG-284) TextTable for printing a fixedlength columns format text tables
[ http://issues.apache.org/jira/browse/LANG-284?page=all ] David Leal updated LANG-284: Attachment: TestTextTable.java Junit test. 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: TestTextTable.java, TestTextTable.out, 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]
Re: [jira] Commented: (NET-114) [net] Unix parser not handling filenames beginning with whitespace
David Kocher (JIRA) wrote: [ http://issues.apache.org/jira/browse/NET-114?page=comments#action_12442207 ] David Kocher commented on NET-114: -- [[ Old comment, sent by email on Sun, 27 Aug 2006 16:53:31 +0200 (CEST) ]] (This is an automated response you will receive only once.) I am currently travelling and emails are replied to with a considerable time lag only. If you are having trouble with Cyberduck, please have a look at the help pages [1] and discuss your problem on the forum [2]. If you discovered a bug or would like to request a feature, please open a ticket [3] for it, so I don't forget about. If you are curious about my journey, have a look at my blog [4] which might reveal some tidbits ;) Thanks for your patience! ~David Kocher [1] http://help.cyberduck.ch/ [2] http://forum.cyberduck.ch/ [3] http://trac.cyberduck.ch/newticket/ [4] http://sudo.ch/~dkocher/ [net] Unix parser not handling filenames beginning with whitespace -- Key: NET-114 URL: http://issues.apache.org/jira/browse/NET-114 Project: Commons Net Issue Type: Bug Environment: Operating System: Mac OS X 10.3 Platform: All Reporter: David Kocher Priority: Minor Filenames beginning with whitespace (such as filename) are not parsed correctly. Currently any whitespace between the date and filename is ignored. However one can probably assume there is only one whitespace character between the date and the filename and any additional whitespace is part of the filename. (This is an assumption made from my experience with different ftp server implementations) === --- UnixFTPEntryParser.java (revision 208907) +++ UnixFTPEntryParser.java (working copy) @@ -101,9 +101,9 @@ year (for non-recent standard format) or time (for numeric or recent standard format */ - + (\\d+(?::\\d+)?)\\s+ + + (\\d+(?::\\d+)?)\\s - + (\\S*)(\\s*.*); + + (\\s*\\S*)(\\s*.*); /** I can see your point, and yet part of me insists on asking what possible justification is there for naming a file with one or more spaces at the beginning? This seems to me as remote, if not more remote, than the possibility that somewhere, some FTP server is coded so as to allow the use of more than one space between the different pieces of information in an FTP listing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Old comment sent by email ... entries
On 10/14/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Anyone know what these are about? There was a mail sent to JIRA admins about this ... guess it might have needed wider distribution. For a fairly long period of time, replies to JIRA's mails were getting lost in the weeds. The filtering on these has apparently been fixed ... but the decision was made to deal with the backlog of unacknowledged messages by flowing them through just so they would not get lost. TIA, -Rahul Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote: Tomcat had this same issue a while back. It was trying to use a single SimpleDateFormat object to parse/format date-valued HTTP headers. I submitted the patch for it and I think we decided to just instantiate as needed. Local variables are garbage collected much more reliably from what I understand. And, as Simon pointed out, the probable disk i/o would be the big bottleneck, not the object instantiation. Ok, so next issue: this member is declared protected: static protected DateFormat dateFormatter = null; (and initialised via a static block on the class). This means that removing it is a binary-incompatible change; any subclasses will be broken. Sigh. Once again we learn the lesson that protected members should be avoided just like public ones, as the binary-compatibility issue they cause are exactly the same. I'd be willing to bet money that no-one in the world has ever subclassed SimpleLog, but the issue is there. And of course binary compatibility is a very big issue for such a core lib as logging. Options: (1) leave this member here, but don't use it. (2) remove it, and release as 1.1.1 (3) remove it, and increment logging version to 1.2 This option does mean that code will continue to run, but if anyone *had* subclassed SimpleLog then they would get output in the default format, not their customised format. As they presumably had a good reason for customising the output, their app may misbehave due to a bugfix-level change. Option 2 could potentially cause an existing application to throw an exception when the SimpleLog subclass tries to access member dateFormatter. Option 3 is the theoretically correct one, but is rather overkill for such a small change. I'm tempted to choose (1), though none of the options are terribly appealing. Comments anyone? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r464108 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
Author: skitching
Date: Sat Oct 14 20:11:19 2006
New Revision: 464108
URL: http://svn.apache.org/viewvc?view=revrev=464108
Log:
Fix thread-safety bug (SimpleDateFormat.format is not thread-safe).
Thanks to Martin Wilson of bright-interactive for the bug report.
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java?view=diffrev=464108r1=464107r2=464108
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
Sat Oct 14 20:11:19 2006
@@ -100,7 +100,15 @@
static protected boolean showDateTime = false;
/** The date and time format to use in the log message */
static protected String dateTimeFormat = DEFAULT_DATE_TIME_FORMAT;
-/** Used to format times */
+
+/**
+ * Used to format times.
+ * p
+ * Any code that accesses this object should first obtain a lock on it,
+ * ie use synchronized(dateFormatter); this requirement was introduced
+ * in 1.1.1 to fix an existing thread safety bug (SimpleDateFormat.format
+ * is not thread-safe).
+ */
static protected DateFormat dateFormatter = null;
// Log Level Constants
@@ -179,7 +187,6 @@
}
}
-
// - Attributes
/** The name of this simple log instance */
@@ -281,7 +288,12 @@
// Append date-time if so configured
if(showDateTime) {
-buf.append(dateFormatter.format(new Date()));
+Date now = new Date();
+String dateText;
+synchronized(dateFormatter) {
+dateText = dateFormatter.format(now);
+}
+buf.append(dateText);
buf.append( );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
After some thought, I've changed my mind about the solution.
I think the best choice is instead to use a synchronized block:
// Append date-time if so configured
if(showDateTime) {
Date now = new Date();
String dateText;
synchronized(dateFormatter) {
dateText = dateFormatter.format(now);
}
buf.append(dateText);
buf.append( );
}
This:
(a) Avoids any binary-compatibility issues, as the member is still
present and still used. There is a potential race condition in that
subclasses of SimpleLog theoretically need to synchronize on the object
if they access it, which is a new requirement. However as there is
*currently* a thread race condition I don't feel we've made anything
worse in that area.
(b) works correctly if a subclass replaces the dateFormatter with some
other object; creating the SimpleDateFormat object in the log method
would break that.
(c) Avoids creating the SimpleDateFormat object. In cases where the
format string is complicated, this construction might actually take some
significant time. Performing synchronization should actually be faster.
I've committed R464108 which implements the synchronized fix.
All comments welcome.
Regards,
Simon
On Sun, 2006-10-15 at 15:50 +1300, Simon Kitching wrote:
On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
Tomcat had this same issue a while back. It was trying to use a single
SimpleDateFormat object to parse/format date-valued HTTP headers. I
submitted the patch for it and I think we decided to just instantiate as
needed. Local variables are garbage collected much more reliably from
what I understand. And, as Simon pointed out, the probable disk i/o would
be the big bottleneck, not the object instantiation.
Ok, so next issue: this member is declared protected:
static protected DateFormat dateFormatter = null;
(and initialised via a static block on the class).
This means that removing it is a binary-incompatible change; any
subclasses will be broken. Sigh. Once again we learn the lesson that
protected members should be avoided just like public ones, as the
binary-compatibility issue they cause are exactly the same.
I'd be willing to bet money that no-one in the world has ever subclassed
SimpleLog, but the issue is there. And of course binary compatibility is
a very big issue for such a core lib as logging.
Options:
(1) leave this member here, but don't use it.
(2) remove it, and release as 1.1.1
(3) remove it, and increment logging version to 1.2
This option does mean that code will continue to run, but if anyone
*had* subclassed SimpleLog then they would get output in the default
format, not their customised format. As they presumably had a good
reason for customising the output, their app may misbehave due to a
bugfix-level change.
Option 2 could potentially cause an existing application to throw an
exception when the SimpleLog subclass tries to access member
dateFormatter.
Option 3 is the theoretically correct one, but is rather overkill for
such a small change.
I'm tempted to choose (1), though none of the options are terribly
appealing.
Comments anyone?
Cheers,
Simon
-
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]
