Re: [io] release plans?
On Mon, 29 Dec 2003, Jeremias Maerki wrote: On 29.12.2003 07:26:47 Henri Yandell wrote: On 1), it seems that Jeremias is driving this one. What's the status Jeremias? I was just waiting for someone to comment on that, but I guess noone objects so we can just delete these methods. I can do that tomorrow if nobody does it first. Leaving for you to kill. BTW, IOUtils still has some deprecated methods that we can now remove. All seemed to be due to the move of code into CopyUtils. I've removed the deprecated values, pointed IOUtils to CopyUtils for the places it uses copy methods and changed the IOUtilsTestCase to point to CopyUtils. Some of these tests will want to either be deleted or moved to CopyUtilsTestCase if not already there. Other than that, the use of 'final' in method parameters is not normally our communities coding style and we might want to dump that. All finals should be gone from the code now. At least the bad ones. I've left final on classes for the moment, and final on a static variable is a good thing. What else? FileUtils is already pretty clean. But now that we've split off FilenameUtils, that's where the whole mess is right now. Some of these methods only work on unix systems. I've started rewriting code for that class but have stopped again as this need some discussion. I can probably write that up tomorrow. FilenameUtils has some deactivated test cases that if activated fail. There some major work left there. I've changed the todo to match this. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml
bayard 2003/12/29 23:09:53 Modified:io/xdocs tasks.xml Log: updated todos Revision ChangesPath 1.10 +4 -2 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/tasks.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- tasks.xml 29 Dec 2003 06:18:25 - 1.9 +++ tasks.xml 30 Dec 2003 07:09:53 - 1.10 @@ -8,9 +8,10 @@ /p ul liIOUtils: Remove the toByteArray() variants with the bufferSize -parameter. Reasoning can be found at +parameter. [Jeremias] Reasoning can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html/li -liFileUtils: This class is a big mess ATM. We need to clean it up./li +liFilenameUtils: This class is a big mess ATM. We need to clean it up./li +liIOUtilsTestCase: Move copy tests over to CopyUtilsTestCase or kill them. [Hen]/li liWrite TestCases for: ul liEndianUtils - InputStream/OutputStream methods/li @@ -18,6 +19,7 @@ liClassLoaderObjectInputStream/li liSwappedDataInputStream/li /ul +though they may not affect an initial beta release. /li liMore Javadocs!!!/li liImprove site!!!/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/uid/xdocs index.xml
psteitz 2003/12/29 23:10:25 Modified:uid/xdocs index.xml Log: Added some basic usage notes. Revision ChangesPath 1.2 +35 -3 jakarta-commons-sandbox/uid/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons-sandbox/uid/xdocs/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 24 Dec 2003 08:59:45 - 1.1 +++ index.xml 30 Dec 2003 07:10:25 - 1.2 @@ -4,7 +4,7 @@ properties titleOverview/title - author email=[EMAIL PROTECTED]Commons Documentation Team/author + author email=[EMAIL PROTECTED]Commons Documentation team/author revision$Id$/revision /properties @@ -12,7 +12,39 @@ section name=The Uid Component -pCommons Uid is a component used to generate unique identifiers./p +p + Commons Uid is a component used to generate unique identifiers. + Several identifier-generation algorithms are supported by Generators included + with the package. The framework is extensible to support additional implementations. +/p +p + A utility class, codeIdentifierUtils,/code provides access to singleton generators and + methods to generate identifiers without explicitly creating a Generator. +/p +p + For example, to generate a sequence of Alphanumeric identifiers, starting with + 001 and increasing sequentially, you can just repeatedly call + source + IdentifierUtils.nextStringAlphanumericIdentifier(); + /source + The underlying Generator used in this case is a static field of the + codeIdentifierUtils/code class, exposed publicly as + codeIdentifierUtils.STRING_ALPHANUMERIC_IDENTIFIER_GENERATOR./code + The Generator implementation (like all others in this package) is synchronized. +/p +p + You can also create Generators explicitly using the codeIdentifierGeneratorFactory/code + abstract factory class. To get an Identifier Generator instance, first get a concrete + factory and then use the appropriate instance creation method: + source +IdentifierGeneratorFactory factory = IdentifierGeneratorFactory.newInstance(); +StringIdentifierGenerator generator = factory.alphanumericGenerator(); + /source + Then you can use the Generator to generate identifiers: + source +String id = generator.nextStringIdentifier(); + /source +/p br/br/ /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/uuid UuidClock.java
psteitz 2003/12/29 23:11:58 Modified:uid/src/java/org/apache/commons/uid/uuid UuidClock.java Log: Added IETF copyright notice, formatting changes. Revision ChangesPath 1.2 +250 -224 jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/uuid/UuidClock.java Index: UuidClock.java === RCS file: /home/cvs/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/uuid/UuidClock.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- UuidClock.java24 Dec 2003 08:59:45 - 1.1 +++ UuidClock.java30 Dec 2003 07:11:58 - 1.2 @@ -1,224 +1,250 @@ -/* - * $Header$ - * - * - * The Apache Software License, Version 1.1 - * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights - * reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in - *the documentation and/or other materials provided with the - *distribution. - * - * 3. The end-user documentation included with the redistribution, if - *any, must include the following acknowledgement: - * This product includes software developed by the - *Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgement may appear in the software itself, - *if and wherever such third-party acknowledgements normally appear. - * - * 4. The names The Jakarta Project, Commons, and Apache Software - *Foundation must not be used to endorse or promote products derived - *from this software without prior written permission. For written - *permission, please contact [EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache - *nor may Apache appear in their names without prior written - *permission of the Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, - * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT - * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many - * individuals on behalf of the Apache Software Foundation. For more - * information on the Apache Software Foundation, please see - * http://www.apache.org/. - * - */ - -package org.apache.commons.uid.uuid; - -/** - * UuidClock.java provides a timing mechanism for returning the current time in - * 100-nano second intervals since 00:00:00.00, 15 October 1582 - * - * As described below this is useful for generating Version 1 UUIDs - * - * For more information regarding the IETF Draft Uuid specification - * see http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt - * - * Selected segements of Draft pertaining to this class: - * - * - * Timestamp - * The timestamp is a 60 bit value. For Uuid version 1, this is - * represented by Coordinated Universal Time (UTC) as a count of 100- - * nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of - * Gregorian reform to the Christian calendar). - * - * Clock Adjustment - * UUIDs may be created at a rate greater than the system clock resolution. - * Therefore, the system must also maintain an adjustment value to be added to - * the lower-order bits of the time. Logically, each time the system clock - * ticks, the adjustment value is cleared. Every time a UUID is generated, - * the current adjustment value is read and incremented atomically, then added - * to the UTC time field of the UUID. - * - * Clock Overrun - * The 100 nanosecond granularity of time should prove
cvs commit: jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/uuid UuidClockTest.java
psteitz 2003/12/29 23:13:59
Modified:uid/src/test/org/apache/commons/uid/uuid UuidClockTest.java
Log:
Removed @author tag.
Revision ChangesPath
1.2 +5 -4
jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/uuid/UuidClockTest.java
Index: UuidClockTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/uuid/UuidClockTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UuidClockTest.java24 Dec 2003 08:59:45 - 1.1
+++ UuidClockTest.java30 Dec 2003 07:13:59 - 1.2
@@ -1,7 +1,8 @@
-/*
+/*
+ *===
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -66,7 +67,7 @@
* Unit tests for [EMAIL PROTECTED] UuidClock}.
*
* @version $Revision$ $Date$
- * @author Phil Steitz
+ * @author Commons-Uid team
*/
public class UuidClockTest extends TestCase {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] UuidClock patch1
Tim Reilly wrote: I missed the IETF license clause that requires quoting from IETF documents to carry the full IETF copyright notice paragraph. This patch applies the (c) disclaimer paragraph as specified by the IETF copy license. Also removed the @author tag. Thanks, Tim. Good catch. I have added the notice. I think that the quote is appropriate (i.e., it's better not to rip it out or paraphrase), since it does describe (part of) exactly what you are trying to implement. (I guess it pays to read the spec all the way to the end ;) Pls have a look at the test that I added for UuidClock. I don't think that I have the accuracy part right and I am seeing sporadic (say, every 10th time on a *fast* linux box) failures in the uniqueness test. Also, please make sure that you can build the whole project let us know what you think about the setup. As long as whatever we end up with in uuid can implement the StringIdentifierGenerator interface, things should work fine. I added a maven-generated ant build.xml, which should work if you don't like/use maven. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid]llang] Adding refactored [lang] identifiers to [uid]
I just committed the new stuff, including most of the suggested name changes. I left the abstract factory (and dependency on [discovery] and [logging]) in so we could see the code pile and usage examples. The abstract factory could be removed easily if that is what we want to do. I also left the IdentifierUtils convenience class in, partly because I have not completed the test framework and the IdentifierUtilsTest class from [lang] has some nice tests to exercise the [lang] generators. Ok, now there is some code to look at. Suggestions / patches / ideas welcome! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] UuidClock patch1
Hi Phil, I've sent my WIP (Work in Progress) directly / off-list. Not sure if that's bad protocol, but just wanted to send an update and get initial thoughts. I've got lots to do still... re-integrating tests, new tests, I need to verify something's about the implementations and the spec, etc, etc. Refactoring... Haven't even though about the C code yet, hopefully APR has the MAC address code. Pls have a look at the test that I added for UuidClock. I don't think that I have the accuracy part right and I am seeing sporadic (say, every 10th time on a *fast* linux box) failures in the uniqueness test. I do need to catch up on the changes / new things since I got back. My initial thought on the failed test is...ut-oh. I'll definitely check. I wanted to get some of the code I started the other week closer, so I haven't looked yet. Also, please make sure that you can build the whole project let us know what you think about the setup. As long as whatever we end up with in uuid can implement the StringIdentifierGenerator interface, things should work fine. Sounds reasonable. I would like to have the option to get the Uuid object as well as the String representation. I'm starting to think about how to get something like SQLServer uniqueidentfier data type working with our DB2 database(s) but I may or may not use a SQL_BINARY I added a maven-generated ant build.xml, which should work if you don't like/use maven. Ahh, Maven I've been wanting to start using it. I'm using Eclipse so Ant is easier AFIAK at the moment, but I've been wanting to try out Mavenide. I appreciate the build script. -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25818] New: - BinaryHeap.remove(Object) seems to break heap order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818
BinaryHeap.remove(Object) seems to break heap order
Summary: BinaryHeap.remove(Object) seems to break heap order
Product: Commons
Version: Nightly Builds
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Collections
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am currently attempting to migrate from my own implementation of a BinaryHeap
to the implementation in org.apache.commons.collections.BinaryHeap.
I have some existing unit tests for my implementation which fail when I run them
on the commons BinaryHeap. Below is source-code for the JUnit test which fails.
The test 'testRandom' is the test that fails. This test creates heaps
initialised with 100 randomly generated Integers and proceeds to add and remove
random elements from these heaps and then checks the heap order. Some of the
elements that are removed may not exist in the heap. Heap order is checked by
disassembling the heap using BinaryHeap.pop() and ensuring that subsequent
elements are = earlier elements.
The problem appears to be related to the BinaryHeap.remove(Object) method-- if
this is commented out the test succeeds. It may be the case that the problem
occurs when non-existant elements are removed, but I have not attempted to
verify this.
-
BinaryHeapTest.java
-
/*
* JASA Java Auction Simulator API
* Copyright (C) 2001-2003 Steve Phelps
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details.
*/
package test.uk.ac.liv.util;
import test.uk.ac.liv.PRNGTestSeeds;
import junit.framework.*;
//import uk.ac.liv.util.*;
import org.apache.commons.collections.BinaryHeap;
import java.util.Random;
import java.util.Iterator;
import java.util.LinkedList;
public class BinaryHeapTest extends TestCase {
BinaryHeap h1;
public BinaryHeapTest( String name ) {
super(name);
}
public void setUp() {
h1 = new BinaryHeap();
h1.insert(new Integer(1));
h1.insert(new Integer(3));
h1.insert(new Integer(9));
h1.insert(new Integer(3));
h1.insert(new Integer(5));
h1.insert(new Integer(7));
}
public void test() {
System.out.println(h1 = + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(5)) );
assertTrue( !h1.contains(new Integer(10)) );
assertTrue( !h1.contains(new Integer(-1)) );
Object x = h1.pop();
System.out.println(h1 after removing first = + h1);
checkOrder(h1);
assertTrue( ((Integer) x).equals(new Integer(1)));
assertTrue( !h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(5)) );
h1.remove(new Integer(9));
System.out.println(h1 after removing 9 = + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( !h1.contains(new Integer(9)) );
assertTrue( h1.remove( new Integer(3) ) );
System.out.println(h1 after removing 3 = + h1);
// assertTrue( ! h1.contains(new Integer(3)) );
x = h1.pop();
System.out.println(h1 after removing first = + h1);
h1.pop();
System.out.println(h1 after removing first = + h1);
assertTrue( h1.remove( new Integer(7) ) );
System.out.println(h1 after removing 7 = + h1);
assertTrue( h1.isEmpty() );
assertTrue( ! h1.remove( new Integer(7) ) );
h1.add( new Integer(666) );
h1.add( new Integer(667) );
assertTrue( h1.remove(new Integer(667)) );
assertTrue( h1.size() == 1 );
assertTrue( ! h1.contains(new Integer(667)) );
assertTrue( h1.remove(new Integer(666)) );
}
public void checkOrder( BinaryHeap h ) {
System.out.println(Checking order of + h);
Integer lastNum = null;
LinkedList l = new LinkedList();
while ( !h.isEmpty() ) {
Integer num = (Integer) h.pop();
System.out.println(num);
if ( lastNum != null num.intValue() lastNum.intValue() ) {
System.out.println(!!??*** + num + smaller than + lastNum);
}
assertTrue( lastNum ==
Re: [uid] UuidClock patch1
Tim Reilly wrote: Hi Phil, I've sent my WIP (Work in Progress) directly / off-list. Not sure if that's bad protocol, but just wanted to send an update and get initial thoughts. I've got lots to do still... re-integrating tests, new tests, I need to verify something's about the implementations and the spec, etc, etc. Refactoring... Haven't even though about the C code yet, hopefully APR has the MAC address code. It's better to keep discussions about the code on the list. That way we get the benefit of others' opinions (and patches :) and we all have the same ideas and information to work with. You can always attach sources to Bugzilla tickets if you want to get code out for folks to look at. Sounds reasonable. I would like to have the option to get the Uuid object as well as the String representation. I'm starting to think about how to get something like SQLServer uniqueidentfier data type working with our DB2 database(s) but I may or may not use a SQL_BINARY Yes. It would probably be better to return the Uuid object as well as a string representation. The frameowork will support this. I added a maven-generated ant build.xml, which should work if you don't like/use maven. Ahh, Maven I've been wanting to start using it. I'm using Eclipse so Ant is easier AFIAK at the moment, but I've been wanting to try out Mavenide. I appreciate the build script. It does not take long to setup and learn to use maven ;-) Phil -TR - 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: cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output ByteArrayOutputStream.java DemuxOutputStream.java LockableFileWriter.java
Henri, why did you remove the finals from some constants? IMO that's not
the same as removing the finals from method parameters, especially when
the constants in question are public. I'd rather we leave the finals
there.
On 30.12.2003 07:55:59 bayard wrote:
public class DirectoryFileFilter extends AbstractFileFilter {
/** Singleton instance of directory filter */
-public static final IOFileFilter INSTANCE = new DirectoryFileFilter();
+public static IOFileFilter INSTANCE = new DirectoryFileFilter();
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPClient.getSystemName()
I agree with you about the capitalization and have, in later code I've written, begun to use the convention you use. I believe it's something of a standard, in fact. I wish I had used it when I first created these classes, but it's probably not worth breaking client code at this point to make this improvement. On Monday 29 December 2003 11:28 pm, Gary Gregory wrote: Hi, Looking at this table I cannot help but mention a naming convention we use in our product code, which is to use the WordCapitalization rule for acronyms in class names, which IMO, makes class names actually readable. For example: UnixFTPEntryParser - UnixFtpEntryParser NTFTPEntryParser - NtFtpEntryParser OS2FTPEntryParser- Os2FtpEntryParser EnterpriseUnixFTPEntryParser - EnterpriseUnixFtpEntryParser VMSFTPEntryParser- VmsFtpEntryParser The funny thing (to me ;-) is that in the table below Unix is not UNIX which is not, technically an acronym, I guess since it came from MULTICS (an acronym ;-P Gary -Original Message- From: steve cohen [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 19:18 To: [EMAIL PROTECTED] Subject: [net] FTPClient.getSystemName() I am beginning to work on trying to map the output of this method to the different FTPEntryParser types we have in commons-net. I know that a default unix FTP server will return UNIX. But can anyone help me fill in this table? Commons-Net Parser Type thatReturn Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser? VMSFTPEntryParser ? - 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]
[configuration] .properties header
This is a patch to add a custom header to .properties files and match
the features of the ExtendedProperties class so that it can be
deprecated. I preferred using a get/setHeader instead of a header
parameter on the save method, this will spare the hassle of carrying the
header every time the configuration has to be saved.
Emmanuel Bourg
Index: src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java
===
RCS file:
/home/cvspublic/jakarta-commons/configuration/src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 BasePropertiesConfiguration.java
--- src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java 23 Dec
2003 15:09:05 - 1.1.1.1
+++ src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java 30 Dec
2003 12:15:38 -
@@ -54,6 +54,7 @@
* http://www.apache.org/.
*/
+import java.io.BufferedReader;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
@@ -61,6 +62,7 @@
import java.io.InputStreamReader;
import java.io.LineNumberReader;
import java.io.Reader;
+import java.io.StringReader;
import java.io.UnsupportedEncodingException;
import java.util.Date;
@@ -164,6 +166,9 @@
/** Allow file inclusion or not */
private boolean includesAllowed = false;
+/** Comment header of the .properties file */
+private String header;
+
/**
* This is the name of the property that can point to other
* properties file for including other properties files.
@@ -276,6 +281,17 @@
File file = new File(filename);
PropertiesWriter out = new PropertiesWriter(file);
+if (header != null)
+{
+BufferedReader reader = new BufferedReader(new StringReader(header));
+String line;
+while ((line = reader.readLine()) != null)
+{
+out.writeComment(line);
+}
+out.write(\n);
+}
+
out.writeComment(written by PropertiesConfiguration);
out.writeComment(new Date().toString());
@@ -331,6 +347,21 @@
public boolean getIncludesAllowed()
{
return this.includesAllowed;
+}
+
+
+/**
+ * Return the comment header.
+ */
+public String getHeader() {
+return header;
+}
+
+/**
+ * Set the comment header.
+ */
+public void setHeader(String header) {
+this.header = header;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[BeanUtils] WrapDynaBean Enhacement Request
I submitted a bugzilla a while ago to enhace WrapDynaBean/WrapDynaClass: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23690 The changes were 1) Implement a getInstance() method in WrapDynaBean so that the original wrapped bean can be retrieved. 2) Implement a newInstance() method in WrapDynaClass to generate new wrapped beans. 3) Change the get(name) and set(name, value) methods to make them more efficient and provide more usefull exception messages. Is there any chance on getting some feedback and/or indication whether there is any interest in applying it? Thanks Niall
[net] SYST/FTPClient.getSystemName()
[originally posted in a slightly different form on commons-dev, now cross-posting to commons-user] I am beginning the work of tying the selection of a specific FTPFileEntryParser in commons-net to the output of the SYST command on that system. (getSystemName() is a wrapper around SYST). The goal of this is to enable clients of this code (such as Ant) to be able to select specific parsers without tying themselves too closely to the internals of commons-net, i.e., knowing the package names and class names of each of the parsers. To that end, I would like to compile a list of SYST/getSystemName() outputs on each of the different system types, so we can code a mapping for this. Eventually, it may even lead to an auto-detect functionality. I know that a default unix FTP server will return UNIX. Will those who use this code on other systems be so kind as to help me fill in this table? Commons-Net Parser Type thatReturn Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser? VMSFTPEntryParser ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] FilenameUtils needs work
As announced I'd like to outline how I currently see FilenameUtils. Current problems are: - Some test cases are disable because they fail. - The test cases are incomplete. Some work only on Unix because they use slashes and the Windows path separator is a backslash. Another example: removeExtension looks for the last occurence of a dot which doesn't work as soon as you forget to remove the path before the filename first. - Some methods (like normalize) only work on Unix. They use hardcoded slashes. - Some methods are duplicates and still have to be removed. I've started to work on that last week but have stopped as I realized that we may need to discuss the approach first. FilenameUtils will be expected to be written once and run everywhere. :-) So it has to work on Unix and Windows (at least). Sun with their java.io.File framework have special implementations of the not quite public java.io.FileSystem class that seems to handle some of the platform dependencies. Other things are handled within java.io.File where backslashes get converted to slashes internally. I think we should do that, too. But as in java.io.File there are a few nasty things to consider (like UNC and drive-relative paths). I wonder if we can handle all that properly without too much effort. I doubt so. Another question is what to do with Windows-style filenames on Unix and vice-versa. What should happen when a UNC path is processed on Unix? How to write the test cases? A separate set for Windows and Unix? Should FilenameUtil methods return Windows-style paths on a Unix machine if a Windows-style path is used as input? If a mix is found (a mix of slashes and backslashes) shall FilenameUtils return the platform-specific style? As I stated before I'm not really a fan of working with String filenames so I actually have a rather small motivation to work on this after I found out about all the difficulties. I realize I'd rather skip FilenameUtils for the initial release. If someone working on Unix is really willing to help me (I'm working on Windows) work on FilenameUtils then I'm in. But I'm sure it'll take some time until everything is stable. If we target a release real soon now, I think we have to skip FilenameUtils. In this area we've had a related thread before (for those who want to read that up): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=380749 That thread and the ideas there make this even more complicated. But we don't have to do everything now I guess. Thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] Bill Barker - Commons Proper Committer
Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPClient.getSystemName()
Isn't the Sun convention to actually use all caps for acroynms? I think I just read about that, Url = URL or something like that. On Tue, 30 Dec 2003 05:58:57 -0600, steve cohen [EMAIL PROTECTED] said: I agree with you about the capitalization and have, in later code I've written, begun to use the convention you use. I believe it's something of a standard, in fact. I wish I had used it when I first created these classes, but it's probably not worth breaking client code at this point to make this improvement. On Monday 29 December 2003 11:28 pm, Gary Gregory wrote: Hi, Looking at this table I cannot help but mention a naming convention we use in our product code, which is to use the WordCapitalization rule for acronyms in class names, which IMO, makes class names actually readable. For example: UnixFTPEntryParser - UnixFtpEntryParser NTFTPEntryParser - NtFtpEntryParser OS2FTPEntryParser - Os2FtpEntryParser EnterpriseUnixFTPEntryParser - EnterpriseUnixFtpEntryParser VMSFTPEntryParser - VmsFtpEntryParser The funny thing (to me ;-) is that in the table below Unix is not UNIX which is not, technically an acronym, I guess since it came from MULTICS (an acronym ;-P Gary -Original Message- From: steve cohen [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 19:18 To: [EMAIL PROTECTED] Subject: [net] FTPClient.getSystemName() I am beginning to work on trying to map the output of this method to the different FTPEntryParser types we have in commons-net. I know that a default unix FTP server will return UNIX. But can anyone help me fill in this table? Commons-Net Parser Type that Return Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser ? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? VMSFTPEntryParser ? - 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] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Bill Barker - Commons Proper Committer
+1 On Tue, 30 Dec 2003, Shapira, Yoav wrote: I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output ByteArrayOutputStream.java DemuxOutputStream.java LockableFileWriter.java
Ah, re-read your mail stating:
All finals should be gone from the code now. At least the bad ones. I've
left final on classes for the moment, and final on a static variable is a
good thing.
...so I guess this was an oversight. I'll revert as necessary.
On 30.12.2003 11:26:35 Jeremias Maerki wrote:
Henri, why did you remove the finals from some constants? IMO that's not
the same as removing the finals from method parameters, especially when
the constants in question are public. I'd rather we leave the finals
there.
On 30.12.2003 07:55:59 bayard wrote:
public class DirectoryFileFilter extends AbstractFileFilter {
/** Singleton instance of directory filter */
-public static final IOFileFilter INSTANCE = new DirectoryFileFilter();
+public static IOFileFilter INSTANCE = new DirectoryFileFilter();
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FilenameUtils needs work
I agree that it seems like a lot of work. I work primarily on Unix and can definitely lend a hand, but you may be correct about skipping it for the 1st release. Jeremias Maerki wrote: As announced I'd like to outline how I currently see FilenameUtils. Current problems are: - Some test cases are disable because they fail. - The test cases are incomplete. Some work only on Unix because they use slashes and the Windows path separator is a backslash. Another example: removeExtension looks for the last occurence of a dot which doesn't work as soon as you forget to remove the path before the filename first. - Some methods (like normalize) only work on Unix. They use hardcoded slashes. - Some methods are duplicates and still have to be removed. I've started to work on that last week but have stopped as I realized that we may need to discuss the approach first. FilenameUtils will be expected to be written once and run everywhere. :-) So it has to work on Unix and Windows (at least). Sun with their java.io.File framework have special implementations of the not quite public java.io.FileSystem class that seems to handle some of the platform dependencies. Other things are handled within java.io.File where backslashes get converted to slashes internally. I think we should do that, too. But as in java.io.File there are a few nasty things to consider (like UNC and drive-relative paths). I wonder if we can handle all that properly without too much effort. I doubt so. Another question is what to do with Windows-style filenames on Unix and vice-versa. What should happen when a UNC path is processed on Unix? How to write the test cases? A separate set for Windows and Unix? Should FilenameUtil methods return Windows-style paths on a Unix machine if a Windows-style path is used as input? If a mix is found (a mix of slashes and backslashes) shall FilenameUtils return the platform-specific style? As I stated before I'm not really a fan of working with String filenames so I actually have a rather small motivation to work on this after I found out about all the difficulties. I realize I'd rather skip FilenameUtils for the initial release. If someone working on Unix is really willing to help me (I'm working on Windows) work on FilenameUtils then I'm in. But I'm sure it'll take some time until everything is stable. If we target a release real soon now, I think we have to skip FilenameUtils. In this area we've had a related thread before (for those who want to read that up): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=380749 That thread and the ideas there make this even more complicated. But we don't have to do everything now I guess. Thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] SYST/FTPClient.getSystemName()
For OS2 we check if the string OS/2 is present. For NT we check if the string Windows is present. For VMS we check if the string VMS is present. This way we don't have to mess with version numbers and stuff. The actual returns that I can verify are: AIX v5.1L: UNIX Type: L8 Version: BSD-44 Linux (Redhat/wu): UNIX Type: L8 OpenVMS: VMS OpenVMS V7.1 on node XX. Windows NT/2000: Windows_NT version 4.0 Windows_NT Windows_NT version 5.0 The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered also reports: UNIX Type: L8 and does not have a normal unix listing. That is why we needed to write a special parser for that one. We no longer have OS/2 servers available. On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen [EMAIL PROTECTED] said: [originally posted in a slightly different form on commons-dev, now cross-posting to commons-user] I am beginning the work of tying the selection of a specific FTPFileEntryParser in commons-net to the output of the SYST command on that system. (getSystemName() is a wrapper around SYST). The goal of this is to enable clients of this code (such as Ant) to be able to select specific parsers without tying themselves too closely to the internals of commons-net, i.e., knowing the package names and class names of each of the parsers. To that end, I would like to compile a list of SYST/getSystemName() outputs on each of the different system types, so we can code a mapping for this. Eventually, it may even lead to an auto-detect functionality. I know that a default unix FTP server will return UNIX. Will those who use this code on other systems be so kind as to help me fill in this table? Commons-Net Parser Type that Return Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser ? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? VMSFTPEntryParser ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter FalseFileFilter.java TrueFileFilter.java DirectoryFileFilter.java
jeremias2003/12/30 07:17:59
Modified:io/src/java/org/apache/commons/io/filefilter
FalseFileFilter.java TrueFileFilter.java
DirectoryFileFilter.java
Log:
Reapply final modifier for static constants.
Revision ChangesPath
1.6 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/FalseFileFilter.java
Index: FalseFileFilter.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/FalseFileFilter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FalseFileFilter.java 30 Dec 2003 06:55:58 - 1.5
+++ FalseFileFilter.java 30 Dec 2003 15:17:59 - 1.6
@@ -67,7 +67,7 @@
public class FalseFileFilter implements IOFileFilter {
/** Singleton instance of false filter */
-public static IOFileFilter INSTANCE = new FalseFileFilter();
+public static final IOFileFilter INSTANCE = new FalseFileFilter();
/**
* Restrictive consructor.
1.6 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/TrueFileFilter.java
Index: TrueFileFilter.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/TrueFileFilter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TrueFileFilter.java 30 Dec 2003 06:55:58 - 1.5
+++ TrueFileFilter.java 30 Dec 2003 15:17:59 - 1.6
@@ -67,7 +67,7 @@
public class TrueFileFilter implements IOFileFilter {
/** Singleton instance of true filter */
-public static IOFileFilter INSTANCE = new TrueFileFilter();
+public static final IOFileFilter INSTANCE = new TrueFileFilter();
/**
* Restrictive consructor.
1.6 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/DirectoryFileFilter.java
Index: DirectoryFileFilter.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/filefilter/DirectoryFileFilter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DirectoryFileFilter.java 30 Dec 2003 06:55:58 - 1.5
+++ DirectoryFileFilter.java 30 Dec 2003 15:17:59 - 1.6
@@ -79,7 +79,7 @@
public class DirectoryFileFilter extends AbstractFileFilter {
/** Singleton instance of directory filter */
-public static IOFileFilter INSTANCE = new DirectoryFileFilter();
+public static final IOFileFilter INSTANCE = new DirectoryFileFilter();
/**
* Restrictive consructor.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] However, this brings up the larger question, of what the target platform for commons-net is. I dimly remember that it being java 1.1. This is why I went through the annoying exercise of creating the FTPFileList and FTPFileIterator classes based on java-1.1-compatible containers like Vector. If we are now using HashMaps, though, we will have violated this contract, if, in fact, such a contract exists. Can someone clarify this question? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/input CountingInputStream.java
jeremias2003/12/30 07:19:00 Modified:io/src/java/org/apache/commons/io/input CountingInputStream.java Log: Removed unused import. Revision ChangesPath 1.6 +1 -2 jakarta-commons-sandbox/io/src/java/org/apache/commons/io/input/CountingInputStream.java Index: CountingInputStream.java === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/input/CountingInputStream.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- CountingInputStream.java 23 Nov 2003 09:20:20 - 1.5 +++ CountingInputStream.java 30 Dec 2003 15:19:00 - 1.6 @@ -55,7 +55,6 @@ import java.io.IOException; import java.io.InputStream; -import java.io.FilterInputStream; /** * Used in debugging, it counts the number of bytes that pass - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output ByteArrayOutputStream.java
jeremias2003/12/30 07:19:45
Modified:io/src/java/org/apache/commons/io/output
ByteArrayOutputStream.java
Log:
Removed System.out calls.
Revision ChangesPath
1.5 +6 -17
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java
Index: ByteArrayOutputStream.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ByteArrayOutputStream.java30 Dec 2003 06:55:59 - 1.4
+++ ByteArrayOutputStream.java30 Dec 2003 15:19:45 - 1.5
@@ -91,8 +91,6 @@
*/
public class ByteArrayOutputStream extends OutputStream {
-private static boolean DEBUG = false;
-
private List buffers = new java.util.ArrayList();
private int currentBufferIndex;
private int filledBufferSum;
@@ -132,17 +130,14 @@
}*/
private void needNewBuffer(int newcount) {
-if (DEBUG) System.out.println(Need new buffer: newcount= + newcount
-+ curBufIdx= + currentBufferIndex
-+ buffers= + buffers.size());
if (currentBufferIndex buffers.size() - 1) {
+//Recycling old buffer
filledBufferSum += currentBuffer.length;
currentBufferIndex++;
currentBuffer = getBuffer(currentBufferIndex);
-if (DEBUG) System.out.println(--Recycling old buffer: size=
-+ currentBuffer.length);
} else {
+//Creating new buffer
int newBufferSize;
if (currentBuffer == null) {
newBufferSize = newcount;
@@ -154,7 +149,6 @@
filledBufferSum += currentBuffer.length;
}
-if (DEBUG) System.out.println(--Adding new buffer: size= +
newBufferSize);
currentBufferIndex++;
currentBuffer = new byte[newBufferSize];
buffers.add(currentBuffer);
@@ -174,16 +168,11 @@
} else if (len == 0) {
return;
}
-if (DEBUG) System.out.println(--write(+len+ bytes));
int newcount = count + len;
int remaining = len;
int inBufferPos = count - filledBufferSum;
while (remaining 0) {
int part = Math.min(remaining, currentBuffer.length - inBufferPos);
-if (DEBUG) System.out.println(Writing + part
-+ bytes at pos + inBufferPos + of buffer
-+ currentBuffer + len= + currentBuffer.length
-+ idx= + currentBufferIndex);
System.arraycopy(b, off + len - remaining, currentBuffer, inBufferPos,
part);
remaining -= part;
if (remaining 0) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output LockableFileWriter.java
jeremias2003/12/30 07:19:59
Modified:io/src/java/org/apache/commons/io/output
LockableFileWriter.java
Log:
Reapply final modifier for static constants.
Revision ChangesPath
1.6 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/LockableFileWriter.java
Index: LockableFileWriter.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/LockableFileWriter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- LockableFileWriter.java 30 Dec 2003 06:55:59 - 1.5
+++ LockableFileWriter.java 30 Dec 2003 15:19:59 - 1.6
@@ -73,7 +73,7 @@
*/
public class LockableFileWriter extends Writer {
-private static String LCK = .lck;
+private static final String LCK = .lck;
private File lockFile = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io FilenameUtils.java
jeremias2003/12/30 07:23:23
Modified:io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Avoid javadoc warnings in Eclipse.
Revision ChangesPath
1.5 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FilenameUtils.java
Index: FilenameUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FilenameUtils.java30 Dec 2003 06:50:16 - 1.4
+++ FilenameUtils.java30 Dec 2003 15:23:23 - 1.5
@@ -491,7 +491,7 @@
public static void copyFileToDirectory(
String source,
String destinationDirectory)
-throws IOException {
+throws IOException, FileNotFoundException {
FileUtils.copyFileToDirectory(new File(source), new
File(destinationDirectory));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io FileUtils.java
jeremias2003/12/30 07:24:01 Modified:io/src/java/org/apache/commons/io FileUtils.java Log: Javadocs: Missing parameter description Revision ChangesPath 1.24 +2 -1 jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FileUtils.java Index: FileUtils.java === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FileUtils.java,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- FileUtils.java30 Dec 2003 06:50:16 - 1.23 +++ FileUtils.java30 Dec 2003 15:24:01 - 1.24 @@ -611,6 +611,7 @@ * * @param file the file to write. * @param data The content to write to the file. + * @param encoding encoding to use * @throws IOException in case of an I/O error * @throws UnsupportedEncodingException if the encoding is not supported * by the VM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io IOUtils.java
jeremias2003/12/30 07:24:23 Modified:io/src/java/org/apache/commons/io IOUtils.java Log: Removed unused imports. Revision ChangesPath 1.11 +1 -5 jakarta-commons-sandbox/io/src/java/org/apache/commons/io/IOUtils.java Index: IOUtils.java === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/IOUtils.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- IOUtils.java 30 Dec 2003 07:06:46 - 1.10 +++ IOUtils.java 30 Dec 2003 15:24:23 - 1.11 @@ -54,14 +54,10 @@ package org.apache.commons.io; import java.io.BufferedInputStream; -import java.io.ByteArrayInputStream; import java.io.IOException; import java.io.InputStream; -import java.io.InputStreamReader; import java.io.OutputStream; -import java.io.OutputStreamWriter; import java.io.Reader; -import java.io.StringReader; import java.io.StringWriter; import java.io.Writer; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input CountingInputStreamTest.java
jeremias2003/12/30 07:25:06 Modified:io/src/test/org/apache/commons/io/input CountingInputStreamTest.java Log: Removed unused imports. Revision ChangesPath 1.3 +3 -5 jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/CountingInputStreamTest.java Index: CountingInputStreamTest.java === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/CountingInputStreamTest.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CountingInputStreamTest.java 30 Dec 2003 07:00:04 - 1.2 +++ CountingInputStreamTest.java 30 Dec 2003 15:25:06 - 1.3 @@ -61,8 +61,6 @@ package org.apache.commons.io.input; -import java.io.IOException; -import java.io.InputStream; import java.io.ByteArrayInputStream; import junit.framework.TestCase; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/output ByteArrayOutputStreamTestCase.java
jeremias2003/12/30 07:25:22
Modified:io/src/test/org/apache/commons/io/output
ByteArrayOutputStreamTestCase.java
Log:
Reapply final modifier for static constants.
Revision ChangesPath
1.5 +4 -4
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/output/ByteArrayOutputStreamTestCase.java
Index: ByteArrayOutputStreamTestCase.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/output/ByteArrayOutputStreamTestCase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ByteArrayOutputStreamTestCase.java30 Dec 2003 07:00:04 - 1.4
+++ ByteArrayOutputStreamTestCase.java30 Dec 2003 15:25:22 - 1.5
@@ -72,7 +72,7 @@
*/
public class ByteArrayOutputStreamTestCase extends TestCase {
-private static byte[] DATA;
+private static final byte[] DATA;
static {
DATA = new byte[64];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io FileUtilsListFilesTestCase.java
jeremias2003/12/30 07:26:16 Modified:io/src/test/org/apache/commons/io FileUtilsListFilesTestCase.java Log: Added missing license header. Revision ChangesPath 1.4 +59 -0 jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FileUtilsListFilesTestCase.java Index: FileUtilsListFilesTestCase.java === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FileUtilsListFilesTestCase.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- FileUtilsListFilesTestCase.java 30 Dec 2003 07:00:03 - 1.3 +++ FileUtilsListFilesTestCase.java 30 Dec 2003 15:26:16 - 1.4 @@ -1,3 +1,62 @@ +/* + * $Header$ + * $Revision$ + * $Date$ + * + * + * + * The Apache Software License, Version 1.1 + * + * Copyright (c) 2003 The Apache Software Foundation. All rights + * reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. The end-user documentation included with the redistribution, if + *any, must include the following acknowledgement: + * This product includes software developed by the + *Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowledgement may appear in the software itself, + *if and wherever such third-party acknowledgements normally appear. + * + * 4. The names The Jakarta Project, Commons, and Apache Software + *Foundation must not be used to endorse or promote products derived + *from this software without prior written permission. For written + *permission, please contact [EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their names without prior written + *permission of the Apache Software Foundation. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * + * This software consists of voluntary contributions made by many + * individuals on behalf of the Apache Software Foundation. For more + * information on the Apache Software Foundation, please see + * http://www.apache.org/. + */ package org.apache.commons.io; import java.io.File; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io FilenameUtilsTestCase.java FileUtilsTestCase.java EndianUtilsTest.java DemuxTestCase.java CopyUtilsTest.java IOUtilsTestCase.java FileUtilsFileNewerTestCase.java
jeremias2003/12/30 07:26:59
Modified:io/src/test/org/apache/commons/io FilenameUtilsTestCase.java
FileUtilsTestCase.java EndianUtilsTest.java
DemuxTestCase.java CopyUtilsTest.java
IOUtilsTestCase.java
FileUtilsFileNewerTestCase.java
Log:
Reapply final modifier for static constants.
Removed unused imports.
Revision ChangesPath
1.4 +4 -13
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java
Index: FilenameUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FilenameUtilsTestCase.java30 Dec 2003 07:00:03 - 1.3
+++ FilenameUtilsTestCase.java30 Dec 2003 15:26:59 - 1.4
@@ -60,9 +60,7 @@
package org.apache.commons.io;
import java.io.File;
-import java.io.FileInputStream;
import java.io.IOException;
-import java.net.URL;
import org.apache.commons.io.testtools.FileBasedTestCase;
@@ -79,13 +77,6 @@
* @see FilenameUtils
*/
public class FilenameUtilsTestCase extends FileBasedTestCase {
-
-// Test data
-
-/**
- * Size of test directory.
- */
-private static int TEST_DIRECTORY_SIZE = 0;
private File testFile1;
private File testFile2;
1.10 +5 -5
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FileUtilsTestCase.java
Index: FileUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/FileUtilsTestCase.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- FileUtilsTestCase.java30 Dec 2003 07:00:03 - 1.9
+++ FileUtilsTestCase.java30 Dec 2003 15:26:59 - 1.10
@@ -85,7 +85,7 @@
/**
* Size of test directory.
*/
-private static int TEST_DIRECTORY_SIZE = 0;
+private static final int TEST_DIRECTORY_SIZE = 0;
private File testFile1;
private File testFile2;
1.7 +5 -12
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java
Index: EndianUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- EndianUtilsTest.java 27 Nov 2003 06:30:26 - 1.6
+++ EndianUtilsTest.java 30 Dec 2003 15:26:59 - 1.7
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2002 The Apache Software Foundation. All rights
+ * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -58,21 +58,14 @@
* http://www.apache.org/.
*
*/
-
-
package org.apache.commons.io;
-
-import java.io.IOException;
-
import junit.framework.TestCase;
-
/**
* @author Henri Yandell (bayard at apache dot org)
* @version $Revision$ $Date$
*/
-
public class EndianUtilsTest extends TestCase {
public EndianUtilsTest(String name) {
1.9 +11 -11
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/DemuxTestCase.java
Index: DemuxTestCase.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/DemuxTestCase.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- DemuxTestCase.java30 Dec 2003 07:00:03 - 1.8
+++ DemuxTestCase.java30 Dec 2003 15:26:59 - 1.9
@@ -82,15 +82,15 @@
public class DemuxTestCase
extends TestCase
{
-private static String T1 = Thread1;
-private static String T2 = Thread2;
-private static String T3 = Thread3;
-private static String T4 = Thread4;
+private static final String T1 = Thread1;
+private static final String T2 = Thread2;
+private static final String T3 = Thread3;
+private static final String T4 = Thread4;
-private static String DATA1 = Data for thread1;
-private static String DATA2 = Data for thread2;
-private static String DATA3 = Data for thread3;
-private static String DATA4 = Data for thread4;
+private static final String DATA1 = Data for thread1;
+private static final String DATA2 = Data for thread2;
+private static final String DATA3 = Data for thread3;
+private
RE: [Vote] Bill Barker - Commons Proper Committer
+1 -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 30. prosinac 2003 14:54 To: [EMAIL PROTECTED] Subject: [Vote] Bill Barker - Commons Proper Committer Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] SYST/FTPClient.getSystemName()
Here's another: SUN OS 5.8: UNIX Type: L8 Version: SUNOS On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen [EMAIL PROTECTED] said: [originally posted in a slightly different form on commons-dev, now cross-posting to commons-user] I am beginning the work of tying the selection of a specific FTPFileEntryParser in commons-net to the output of the SYST command on that system. (getSystemName() is a wrapper around SYST). The goal of this is to enable clients of this code (such as Ant) to be able to select specific parsers without tying themselves too closely to the internals of commons-net, i.e., knowing the package names and class names of each of the parsers. To that end, I would like to compile a list of SYST/getSystemName() outputs on each of the different system types, so we can code a mapping for this. Eventually, it may even lead to an auto-detect functionality. I know that a default unix FTP server will return UNIX. Will those who use this code on other systems be so kind as to help me fill in this table? Commons-Net Parser Type that Return Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser ? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? VMSFTPEntryParser ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FilenameUtils needs work
Agreed. If no one has the itch, we should shelve it. I would just list it as: Not going for 1.0 and we wouldn't include it in the 1.0 tag. It can stay in its current place in CVS I think. We got away with this a lot in Lang, having packages that didn't deploy even though they were in HEAD etc. Are there any methods in there that are worth pushing? Or just skip the whole thing for 1.0 and when someone turns up with the itch we can hit them with all the difficulties and as a group solve them? Hen On Tue, 30 Dec 2003, __matthewHawthorne wrote: I agree that it seems like a lot of work. I work primarily on Unix and can definitely lend a hand, but you may be correct about skipping it for the 1st release. Jeremias Maerki wrote: As announced I'd like to outline how I currently see FilenameUtils. Current problems are: - Some test cases are disable because they fail. - The test cases are incomplete. Some work only on Unix because they use slashes and the Windows path separator is a backslash. Another example: removeExtension looks for the last occurence of a dot which doesn't work as soon as you forget to remove the path before the filename first. - Some methods (like normalize) only work on Unix. They use hardcoded slashes. - Some methods are duplicates and still have to be removed. I've started to work on that last week but have stopped as I realized that we may need to discuss the approach first. FilenameUtils will be expected to be written once and run everywhere. :-) So it has to work on Unix and Windows (at least). Sun with their java.io.File framework have special implementations of the not quite public java.io.FileSystem class that seems to handle some of the platform dependencies. Other things are handled within java.io.File where backslashes get converted to slashes internally. I think we should do that, too. But as in java.io.File there are a few nasty things to consider (like UNC and drive-relative paths). I wonder if we can handle all that properly without too much effort. I doubt so. Another question is what to do with Windows-style filenames on Unix and vice-versa. What should happen when a UNC path is processed on Unix? How to write the test cases? A separate set for Windows and Unix? Should FilenameUtil methods return Windows-style paths on a Unix machine if a Windows-style path is used as input? If a mix is found (a mix of slashes and backslashes) shall FilenameUtils return the platform-specific style? As I stated before I'm not really a fan of working with String filenames so I actually have a rather small motivation to work on this after I found out about all the difficulties. I realize I'd rather skip FilenameUtils for the initial release. If someone working on Unix is really willing to help me (I'm working on Windows) work on FilenameUtils then I'm in. But I'm sure it'll take some time until everything is stable. If we target a release real soon now, I think we have to skip FilenameUtils. In this area we've had a related thread before (for those who want to read that up): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=380749 That thread and the ideas there make this even more complicated. But we don't have to do everything now I guess. Thoughts? Jeremias Maerki - 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: [Vote] Bill Barker - Commons Proper Committer
+1 Costin -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 30. prosinac 2003 14:54 To: [EMAIL PROTECTED] Subject: [Vote] Bill Barker - Commons Proper Committer Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FilenameUtils needs work
On 30.12.2003 17:01:24 Henri Yandell wrote: Agreed. If no one has the itch, we should shelve it. I would just list it as: Not going for 1.0 and we wouldn't include it in the 1.0 tag. It can stay in its current place in CVS I think. We got away with this a lot in Lang, having packages that didn't deploy even though they were in HEAD etc. I like putting new stuff into a sandbox directory until it is ready. Leaving it where it is means that the person applying the CVS tag must be pretty careful. Just an observation, not a proposal. Are there any methods in there that are worth pushing? Or just skip the whole thing for 1.0 and when someone turns up with the itch we can hit them with all the difficulties and as a group solve them? IMO we can skip the whole thing. But checking FilenameUtils and FileUtils I realize we don't have any methods in FileUtils that do extension handling (getExtension, removeExtension). The only problem I see is people who might use methods from FilenameUtils today. But that should motivate them to step in. :-) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io FileUtils.java
jeremias2003/12/30 08:27:42
Modified:io/src/java/org/apache/commons/io FileUtils.java
Log:
Made convertFileCollectionToFileArray static.
Revision ChangesPath
1.25 +2 -2
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FileUtils.java
Index: FileUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/FileUtils.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- FileUtils.java30 Dec 2003 15:24:01 - 1.24
+++ FileUtils.java30 Dec 2003 16:27:42 - 1.25
@@ -192,7 +192,7 @@
* @param files a Collection containing java.io.File instances
* @return an array of java.io.File
*/
-public File[] convertFileCollectionToFileArray(Collection files) {
+public static File[] convertFileCollectionToFileArray(Collection files) {
return (File[])files.toArray(new File[files.size()]);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote] Bill Barker - Commons Proper Committer
[X] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io CopyUtils.java IOUtils.java
jeremias2003/12/30 08:35:11
Modified:io/src/java/org/apache/commons/io CopyUtils.java
IOUtils.java
Log:
Removed methods that take a bufferSize parameter.
Discussion:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=572862
Revision ChangesPath
1.4 +15 -158
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/CopyUtils.java
Index: CopyUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/CopyUtils.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CopyUtils.java30 Dec 2003 06:52:49 - 1.3
+++ CopyUtils.java30 Dec 2003 16:35:11 - 1.4
@@ -94,23 +94,7 @@
* @throws IOException In case of an I/O problem
*/
public static void copy(byte[] input, OutputStream output)
-throws IOException {
-copy(input, output, DEFAULT_BUFFER_SIZE);
-}
-
-/**
- * Copy bytes from a codebyte[]/code to an codeOutputStream/code.
- * @param input the byte array to read from
- * @param output the codeOutputStream/code to write to
- * @param bufferSize Size of internal buffer to use.
- * @throws IOException In case of an I/O problem
- */
-public static void copy(
-byte[] input,
-OutputStream output,
-int bufferSize)
-throws IOException {
-// TODO Is bufferSize param needed?
+throws IOException {
output.write(input);
}
@@ -127,28 +111,12 @@
* @throws IOException In case of an I/O problem
*/
public static void copy(byte[] input, Writer output)
-throws IOException {
-copy(input, output, DEFAULT_BUFFER_SIZE);
-}
-
-/**
- * Copy and convert bytes from a codebyte[]/code to chars on a
- * codeWriter/code.
- * The platform's default encoding is used for the byte-to-char conversion.
- * @param input the byte array to read from
- * @param output the codeWriter/code to write to
- * @param bufferSize Size of internal buffer to use.
- * @throws IOException In case of an I/O problem
- */
-public static void copy(
-byte[] input,
-Writer output,
-int bufferSize)
-throws IOException {
+throws IOException {
ByteArrayInputStream in = new ByteArrayInputStream(input);
-copy(in, output, bufferSize);
+copy(in, output);
}
+
/**
* Copy and convert bytes from a codebyte[]/code to chars on a
* codeWriter/code, using the specified encoding.
@@ -168,26 +136,6 @@
copy(in, output, encoding);
}
-/**
- * Copy and convert bytes from a codebyte[]/code to chars on a
- * codeWriter/code, using the specified encoding.
- * @param input the byte array to read from
- * @param output the codeWriter/code to write to
- * @param encoding The name of a supported character encoding. See the
- *a href=http://www.iana.org/assignments/character-sets;IANA
- *Charset Registry/a for a list of valid encoding types.
- * @param bufferSize Size of internal buffer to use.
- * @throws IOException In case of an I/O problem
- */
-public static void copy(
-byte[] input,
-Writer output,
-String encoding,
-int bufferSize)
-throws IOException {
-ByteArrayInputStream in = new ByteArrayInputStream(input);
-copy(in, output, encoding, bufferSize);
-}
//
// Core copy methods
@@ -200,25 +148,11 @@
* @return the number of bytes copied
* @throws IOException In case of an I/O problem
*/
-public static int copy(InputStream input, OutputStream output)
-throws IOException {
-return copy(input, output, DEFAULT_BUFFER_SIZE);
-}
-
-/**
- * Copy bytes from an codeInputStream/code to an codeOutputStream/code.
- * @param input the codeInputStream/code to read from
- * @param output the codeOutputStream/code to write to
- * @param bufferSize Size of internal buffer to use.
- * @return the number of bytes copied
- * @throws IOException In case of an I/O problem
- */
public static int copy(
InputStream input,
-OutputStream output,
-int bufferSize)
+OutputStream output)
throws IOException {
-byte[] buffer = new byte[bufferSize];
+byte[] buffer = new
Re: Broken link to jdk 1.4 API docs
http://java.sun.com/j2se/1.4/docs/api/ works, too. Gets redirected to 1.4.2. On 29.12.2003 07:13:20 Phil Steitz wrote: The link http://java.sun.com/products/jdk/1.4/docs/api used as the value of the maven.javadoc.links for several commons projects (viz. [pool], [primitives], [launcher], [functor], [events], [scaffold], [jux], [workflow], [comnpress], [cache]) no longer works. This should be replaced by either http://java.sun.com/j2se/1.4.2/docs/api/ or http://java.sun.com/j2se/1.4.1/docs/api/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jexl] String concatination
On Dec 29, 2003, at 7:52 PM, Robert wrote:
Geir Magnusson Jr wrote:
On Dec 20, 2003, at 10:22 PM, Robert wrote:
I actually thought this was in the spec, my fault! I was trying to
do string building, which of course didn't work, which lead me to
look at the JavaDoc this class says either integer addition or
string concatenation and the CVS entry says something about string
concatenation not working anymore, so I did this quick patch.
I even tried string literal addition and it doesn't work either. It
would be nice so one does have to do ${hello.concat(' world')} to
build strings, but I'll understand if it isn't added.
What doesn't work? I don't understand.
I'll double check but 'hello' + 'world' wouldn't work either. Perhaps
I should just write a junit test!!
I added a unit test when I did the patch
Robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Author tags redux
On Dec 28, 2003, at 10:39 PM, Phil Steitz wrote: The subject of @author tags has been discussed on and off here and elsewhere with no apparent consensus. In a recent post to general@, Ted Husted pointed to this post http://tinyurl.com/yrlhu by Greg Stein to community at apache.org, which raises some disturbing legal and community issues around the use of @author tags. I am convinced by his arguments that we should eliminate @author tags uniformly once we clean up the web site and get the process of updating and publishing contributor lists routinized (read: complete the mavenization of the j-c web site). I'm not sure I buy the legal argument, as our CVS logs are public also, and it's easy to figure out who did what in a piece of questionable code. So you haven't really don't anything by removing the author tag - the author is still easily discoverable. I think author tags are good as some/many/all people are proud to have their name on things that they work hard on and contribute. I'll be the first to admit the sense of pride that I felt when contributing something for the first time, and seeing my name on it. The valid point (IMO) I've heard in favor of removing them is that not having them can help the sense of group ownership and community. if I had to decide, as long as there is no additional liability in having the tag in the code, I'd be for letting people/components/etc choose to do what they feel is right. geir I assume that this needs to be decided for each of the components separately. With that in mind, I would like to start by removing/omitting @author tags from [uid] and I would like to propose that we pull them out of [collections] and [lang] as and when we complete mavenization of the websites for these components (or otherwise publish a full and up-to-date contributors list). Now would be a good time to act on [collections], since we are about to cut a release. So...what do we think about pulling out the @author tags from [collections] and pushing out the maven site with 3.0? If we want to hold off on the mavenization until we have worked out the larger j-c site issues, we can just add a contributors page to the existing site to acknowledge contributors. If others are in favor, I will volunteer to grep out the @authors and do this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving up to JVM 1.4+
This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FilenameUtils needs work
On Tue, 30 Dec 2003, Jeremias Maerki wrote: On 30.12.2003 17:01:24 Henri Yandell wrote: Agreed. If no one has the itch, we should shelve it. I would just list it as: Not going for 1.0 and we wouldn't include it in the 1.0 tag. It can stay in its current place in CVS I think. We got away with this a lot in Lang, having packages that didn't deploy even though they were in HEAD etc. I like putting new stuff into a sandbox directory until it is ready. Leaving it where it is means that the person applying the CVS tag must be pretty careful. Just an observation, not a proposal. When we migrate over to commons-proper cvs, we can keep this one alive for sandbox work. Lang did this too, though it does seem to cause confusion sometimes. The people checking the release have to be careful too :) Are there any methods in there that are worth pushing? Or just skip the whole thing for 1.0 and when someone turns up with the itch we can hit them with all the difficulties and as a group solve them? IMO we can skip the whole thing. But checking FilenameUtils and FileUtils I realize we don't have any methods in FileUtils that do extension handling (getExtension, removeExtension). The only problem I see is people who might use methods from FilenameUtils today. But that should motivate them to step in. :-) Yep :) Until 1.0 we don't support anything is my view. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml changes.xml
jeremias2003/12/30 09:30:53 Modified:io/xdocs tasks.xml changes.xml Log: Update Revision ChangesPath 1.12 +0 -3 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/tasks.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- tasks.xml 30 Dec 2003 07:13:03 - 1.11 +++ tasks.xml 30 Dec 2003 17:30:53 - 1.12 @@ -7,9 +7,6 @@ release of this component: /p ul -liIOUtils: Remove the toByteArray() variants with the bufferSize -parameter. [Jeremias] Reasoning can be found at -http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html/li liFilenameUtils: This class is a big mess ATM. We need to clean it up./li liIOUtilsTestCase: Move copy tests over to CopyUtilsTestCase or kill them. [Hen]/li liRe-enable test case for: IOUtilTestCase/li 1.2 +7 -2 jakarta-commons-sandbox/io/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/changes.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- changes.xml 23 Nov 2003 13:13:28 - 1.1 +++ changes.xml 30 Dec 2003 17:30:53 - 1.2 @@ -5,6 +5,11 @@ /properties body release version=1.0-dev date=in CVS + action dev=jeremias type=remove +IOUtils: Removed the copy() and toByteArray() variants with the bufferSize +parameter. Reasoning can be found at +http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html + /action action type=update Renamed all *Util.java to *Utils.java for consistency. /action @@ -38,12 +43,12 @@ due-to=Alban Peignier due-to-email=alban.peignier at free.fr New methods for FileUtils: isFileNewer() (3 variants) /action - actions dev=bayard type=add + action dev=bayard type=add due-to=Jeremias Maerki due-to-email=jeremias at apache.org Added an alternative ByteArrayOutputStream implementation which is faster than the original java.io.ByteArrayOutputStream by reusing buffers instead of reallocating them when the buffer needs to be resized. - /actions + /action /release /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Bill Barker - Commons Proper Committer
+1 Phil Shapira, Yoav wrote: Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Moving up to JVM 1.4+
Our current server (ActiveMath) is blocked entirely by JDK 1.4: it's a server with slightly too heavy memory requirements and the result is... OutOfMemoryError on most Unix-VMs if in JDK 1.4. (especially true on MacOSX, very frequent on Sun and Blackdown's on Linux). Hence the wish not to depend on this for libraries that we would take. However, I wouldn't object the build of a jakarta-commons component to require JDK 1.4. Paul On 30-Dec-03, at 18:06 Uhr, Noel J. Bergman wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - 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: Moving up to JVM 1.4+
Howdy, I'm neutral on requiring 1.4, but I'm curious about your server: the same code requires much more memory running on JDK 1.4 than it does on JDK 1.3 or earlier? Do you know why? Yoav Shapira Millennium ChemInformatics -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 30, 2003 12:45 PM To: Jakarta Commons Developers List Subject: Re: Moving up to JVM 1.4+ Our current server (ActiveMath) is blocked entirely by JDK 1.4: it's a server with slightly too heavy memory requirements and the result is... OutOfMemoryError on most Unix-VMs if in JDK 1.4. (especially true on MacOSX, very frequent on Sun and Blackdown's on Linux). Hence the wish not to depend on this for libraries that we would take. However, I wouldn't object the build of a jakarta-commons component to require JDK 1.4. Paul On 30-Dec-03, at 18:06 Uhr, Noel J. Bergman wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Gary Gregory wrote: Note that the current implementation already does some of this catch and set to null business WRT SecurityExpections. Ah, I didn't realize this. Perhaps it isn't a big deal then -- although I think that providing the constants in this way, although convenient, circumvents some exception mechanisms which provide more explicit error messages. My point is, if something goes wrong, you'll get a NullPointerException and have to look at System.err to see what happened. I don't prefer this, but perhaps others do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] SYST/FTPClient.getSystemName()
Well, it sounds like only OS2 and Enterprise Unix are problematical. I Googled OS2 FTP and I can't find a single publicly accessible FTP site that runs OS2. I did find this page: http://www.sentex.net/kwos2cug/os2-ftp.html which lists dozens of ftp sites RELATED to OS2. The majority of them are defunct and those that are still live are running on unix servers. But for now, it will be fine to use the OS/2 key. If anyone can provide more accurate information, please send it on and we'll be happy to include it. As for Enterprise Unix, since it doesn't seem to identify itself as anything different from regular Unix, we won't be able to provide auto-detection. What I am envisioning now is a factory method like this: public static FTPFileEntryParser createFileEntryParser(String key); where key could be either one of the known strings (UNIX, OS/2, Windows, or VMS) or else a fully qualified class name of a class that implements FTPFileEntryParser (to accomodate Enterprise Unix and any user-written parsers that may be out there). If there are other versions of these keys in existence, they, too can be allowed; we can have a many to one mapping between keys and parsers. This API would be exposed to outside clients such as Ant. The ant ftp task can be rewritten to have an additional attribute called, say, servertype that the user can supply and the code rewritten to instantiate this parser and use it. This method can also be the guts behind an autodetection scheme yet to be written. On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote: For OS2 we check if the string OS/2 is present. For NT we check if the string Windows is present. For VMS we check if the string VMS is present. This way we don't have to mess with version numbers and stuff. The actual returns that I can verify are: AIX v5.1L: UNIX Type: L8 Version: BSD-44 Linux (Redhat/wu): UNIX Type: L8 OpenVMS: VMS OpenVMS V7.1 on node XX. Windows NT/2000: Windows_NT version 4.0 Windows_NT Windows_NT version 5.0 The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered also reports: UNIX Type: L8 and does not have a normal unix listing. That is why we needed to write a special parser for that one. We no longer have OS/2 servers available. On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen [EMAIL PROTECTED] said: [originally posted in a slightly different form on commons-dev, now cross-posting to commons-user] I am beginning the work of tying the selection of a specific FTPFileEntryParser in commons-net to the output of the SYST command on that system. (getSystemName() is a wrapper around SYST). The goal of this is to enable clients of this code (such as Ant) to be able to select specific parsers without tying themselves too closely to the internals of commons-net, i.e., knowing the package names and class names of each of the parsers. To that end, I would like to compile a list of SYST/getSystemName() outputs on each of the different system types, so we can code a mapping for this. Eventually, it may even lead to an auto-detect functionality. I know that a default unix FTP server will return UNIX. Will those who use this code on other systems be so kind as to help me fill in this table? Commons-Net Parser Type that Return Value succesfully parses entries from getSystemName() UnixFTPEntryParser UNIX NTFTPEntryParser ? OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? VMSFTPEntryParser ? - 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]
DO NOT REPLY [Bug 25511] - allow for database clusters/clustering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25511. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25511 allow for database clusters/clustering --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 18:17 --- See Bug 25827 for how to configure a multiple datasources (=cluster??) out of struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. However, there might be room for discussion whether we want to leave 1.1 compatibility behind. Ant 1.6 now is compatible only with JDK 1.2 and above. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). On Tuesday 30 December 2003 09:01 am, Jeffrey D. Brekke wrote: On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] However, this brings up the larger question, of what the target platform for commons-net is. I dimly remember that it being java 1.1. This is why I went through the annoying exercise of creating the FTPFileList and FTPFileIterator classes based on java-1.1-compatible containers like Vector. If we are now using HashMaps, though, we will have violated this contract, if, in fact, such a contract exists. Can someone clarify this question? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
--- Noel J. Bergman [EMAIL PROTECTED] wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There will always be users that will complain when changing Java versions. The only semi-valid reason I've heard to not upgrade to 1.4 is that product X requires 1.3 and product X is expensive. IMO, if the component needs 1.4 then you should move to 1.4. The previous 1.3 compatible version of the component will still work after the change. Product X shouldn't stand in the way of innovation :-). David There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jexl jexl.ipr
proyal 2003/12/30 12:45:11 Removed: jexl jexl.ipr Log: Remove the IDEA project file from CVS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jexl .cvsignore
proyal 2003/12/30 12:46:45 Modified:jexl .cvsignore Log: Ignore IDEA project files Revision ChangesPath 1.3 +3 -0 jakarta-commons/jexl/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons/jexl/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- .cvsignore9 May 2003 12:22:29 - 1.2 +++ .cvsignore30 Dec 2003 20:46:45 - 1.3 @@ -8,3 +8,6 @@ tmp lib bin +*.ipr +*.iws +*.iml \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jexl/src/test/org/apache/commons/jexl JexlTest.java
proyal 2003/12/30 12:47:53
Modified:jexl/src/java/org/apache/commons/jexl/parser
ASTEmptyFunction.java
jexl/src/test/org/apache/commons/jexl JexlTest.java
Log:
Testcase and fix for bug where the empty() function didn't work on bean.subitem
Revision ChangesPath
1.4 +19 -27
jakarta-commons/jexl/src/java/org/apache/commons/jexl/parser/ASTEmptyFunction.java
Index: ASTEmptyFunction.java
===
RCS file:
/home/cvs/jakarta-commons/jexl/src/java/org/apache/commons/jexl/parser/ASTEmptyFunction.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ASTEmptyFunction.java 9 Oct 2003 21:28:55 - 1.3
+++ ASTEmptyFunction.java 30 Dec 2003 20:47:53 - 1.4
@@ -89,38 +89,30 @@
{
SimpleNode sn = (SimpleNode) jjtGetChild(0);
-if (sn instanceof ASTReference)
-{
-String s = ((ASTReference)sn).getRootString();
+/*
+ * I can't believe this
+ */
-/*
- * I can't believe this
- */
+Object o = sn.value(jc);
-Object o = jc.getVars().get(s);
+if (o == null)
+return Boolean.TRUE;
-if (o == null)
-return Boolean.TRUE;
+if (o instanceof String ((String)o).equals())
+return Boolean.TRUE;
-if (o instanceof String ((String)o).equals())
-return Boolean.TRUE;
+if (o.getClass().isArray() ((Object[])o).length == 0)
+return Boolean.TRUE;
-if (o.getClass().isArray() ((Object[])o).length == 0)
-return Boolean.TRUE;
+if (o instanceof Collection ((Collection)o).isEmpty())
+return Boolean.TRUE;
-if (o instanceof Collection ((Collection)o).isEmpty())
-return Boolean.TRUE;
+/*
+ * Map isn't a collection
+ */
+if (o instanceof Map ((Map)o).isEmpty())
+return Boolean.TRUE;
- /*
- * Map isn't a collection
- */
- if (o instanceof Map ((Map)o).isEmpty())
- return Boolean.TRUE;
-
-return Boolean.FALSE;
-}
-
-throw new Exception(programmer error : ASTEmptyFunction : invalid root
-+ sn);
+return Boolean.FALSE;
}
}
1.34 +12 -1
jakarta-commons/jexl/src/test/org/apache/commons/jexl/JexlTest.java
Index: JexlTest.java
===
RCS file:
/home/cvs/jakarta-commons/jexl/src/test/org/apache/commons/jexl/JexlTest.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JexlTest.java 18 Dec 2003 16:10:57 - 1.33
+++ JexlTest.java 30 Dec 2003 20:47:53 - 1.34
@@ -57,6 +57,7 @@
import java.util.HashMap;
import java.util.List;
import java.util.Map;
+import java.util.Collections;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -977,6 +978,16 @@
jc.getVars().put( this.is.a.test, );
assertExpression(jc, empty(this.is.a.test), Boolean.TRUE);
+}
+
+public void testEmptySubListOfMap() throws Exception
+{
+JexlContext jc = JexlHelper.createContext();
+Map m = Collections.singletonMap(aList, Collections.EMPTY_LIST);
+
+jc.getVars().put( aMap, m );
+
+assertExpression( jc, empty( aMap.aList ), Boolean.TRUE );
}
public void testCoercionWithComparisionOperators()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
On Dec 30, 2003, at 3:41 PM, David Graham wrote: --- Noel J. Bergman [EMAIL PROTECTED] wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There will always be users that will complain when changing Java versions. The only semi-valid reason I've heard to not upgrade to 1.4 is that product X requires 1.3 and product X is expensive. IMO, if the component needs 1.4 then you should move to 1.4. The previous 1.3 compatible version of the component will still work after the change. Product X shouldn't stand in the way of innovation :-). Don't forget that not all platforms have 1.4 or a mature 1.4 that people trust. it too a while for apple to get 1.4 out to OS X - I wouldn't use OS X in production of course, but it's my development platform... geir David There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU tils.JAVA_IO_TMPDIR]
I am +1 to adding new methods (not fields) for the following variables. java.home = C:\java\sun\1.4.2_03\jre java.io.tmpdir = C:\DOCUME~1\ggregory\LOCALS~1\Temp\ user.dir = C:\cvs-store\transidiom\deve user.home = C:\Documents and Settings\ggregory It is a sesnsible extension to a useful class. The current static fields are perfectly fine for their task, and null values is acceptable as early JDKs don't support some properties anyway. Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] (I presume that your 2 choices are user code choices.) My thinking in adding a method/field to SU which returns a File is about creating the proper object, the proper abstraction. System.getProperty() gives us a very thin layer over the JVM/OS to access properties but it is flexible. There is a known set of properties always returned as Strings in known formats. What I am saying is that in the case of Strings that represent directories, I want an object that says I am a directory (- java.io.File) not I am a String which I must convert myself. I can code new File myself of course. But it seems good to say: we know this system property is a directory, so here it is as a proper Object, a File you can work with. Currently SU is more like a macro, hiding System.getProperty calls. I am proposing of giving it a little more brains ;-) Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 30, 2003 11:52 To: Jakarta Commons Developers List Subject: Re: SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU tils.JAVA_IO_TMPDIR] I feel that all of the methods which deal with system properties aren't very useful. Here's the choice: 1) new File(SystemUtils.JAVA_IO_TMPDIR) - may throw a NullPointerException if a secret SecurityException occurs 2) new File(System.getProperty(java.io.tmpdir)) - may throw a SecurityException I just don't think that adding code to SystemUtils to accomplish this task is worth the effort. What's the problem with option 2 above? Gary Gregory wrote: I was not wild about the current impl when I saw it but the fix was backwards compatible, that part was nice. (1) So perhaps the question becomes: Should all of the fields be turned (deprecated?) into methods and the exceptions not caught? For example: SystemUtils.getJavaIoTmpDir(); SystemUtils.getJavaRuntimeName(); If the exceptions are not caught, it is possible that the class then becomes unusable in certain contexts. The CVS comment for that change from Stephen was: Reworked class to avoid security exceptions from Michael Becke. Is that really appropriate? It seems a bit nasty that the class is quietly initialized with nulls. (2) Should there be instead an isAvailable() kind of method instead? (3) Or what about a class that deals /specifically/ with all of this, a nice and focused job: SystemProperties, a singleton, or static SystemPropertiesUtils. SystemProperties.getInstance().getClassPath(); SystemPropertiesUtils.getClassPath(); SystemProperties would define only methods and object versions of the appropriate methods. For example File file = SystemProperties.getInstance().getJavaIoTmpDirFile(); String dirName = SystemProperties.getInstance().getJavaIoTmpDir(); ? Gary - 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: Moving up to JVM 1.4+
The block on 1.4 remains the big-iron webservers, like Websphere and Weblogic. 1.4 as a requirement is a long way off yet IMHO. Stephen - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - 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: Moving up to JVM 1.4+
David Graham wrote: There will always be users that will complain when changing Java versions. The only semi-valid reason I've heard to not upgrade to 1.4 is that product X requires 1.3 and product X is expensive. Where often Product X is a commerical J2EE container (see below) and what is expensive is both licensing and migrating to a later version or a different product. IMO, if the component needs 1.4 then you should move to 1.4. The previous 1.3 compatible version of the component will still work after the change. Product X shouldn't stand in the way of innovation :-). Agreed...sort of. We just need to keep in mind that *lots* of server-side developers will not be able to use components that require 1.4 for some time to come. Here is a recent TSS survey of J2EE containers that shows jdk levels supported by different containers: http://www.theserverside.com/reviews/matrix.jsp I know that IBM recently released WebSphere 5.1, including 1.4 support, but previous versions require 1.3. Phil David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
Unfortunately I don't remember if it was discussed or not. I'm for leaving 1.1 behind, even if we need to make a compatible version at this point, but then moving on. Seems like 1.3 is doable. I wouldn't want to leave users out in the cold. I still want to provide a release that works with a given jvm version, but I don't think I want to freeze all development at that version so long. So maybe new development proceeds with newer version of the jvm or something? On Tue, 30 Dec 2003 14:11:31 -0600, Steve Cohen [EMAIL PROTECTED] said: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. However, there might be room for discussion whether we want to leave 1.1 compatibility behind. Ant 1.6 now is compatible only with JDK 1.2 and above. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). On Tuesday 30 December 2003 09:01 am, Jeffrey D. Brekke wrote: On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] However, this brings up the larger question, of what the target platform for commons-net is. I dimly remember that it being java 1.1. This is why I went through the annoying exercise of creating the FTPFileList and FTPFileIterator classes based on java-1.1-compatible containers like Vector. If we are now using HashMaps, though, we will have violated this contract, if, in fact, such a contract exists. Can someone clarify this question? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap TestAbstractOrderedBidiMapDecorator.java TestAll.java TestTreeBidiMap.java
scolebourne2003/12/30 13:56:17
Modified:collections/src/test/org/apache/commons/collections/bidimap
TestAll.java TestTreeBidiMap.java
Added: collections/src/test/org/apache/commons/collections/bidimap
TestAbstractOrderedBidiMapDecorator.java
Log:
Improve BidiMap testing
Revision ChangesPath
1.4 +3 -2
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestAll.java 3 Dec 2003 14:03:35 - 1.3
+++ TestAll.java 30 Dec 2003 21:56:17 - 1.4
@@ -87,6 +87,7 @@
suite.addTest(TestDualTreeBidiMap.suite());
suite.addTest(TestTreeBidiMap.suite());
+suite.addTest(TestAbstractOrderedBidiMapDecorator.suite());
suite.addTest(TestUnmodifiableBidiMap.suite());
suite.addTest(TestUnmodifiableOrderedBidiMap.suite());
suite.addTest(TestUnmodifiableSortedBidiMap.suite());
1.4 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestTreeBidiMap.java
Index: TestTreeBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestTreeBidiMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestTreeBidiMap.java 1 Dec 2003 22:34:54 - 1.3
+++ TestTreeBidiMap.java 30 Dec 2003 21:56:17 - 1.4
@@ -73,7 +73,7 @@
*
* @author Stephen Colebourne
*/
-public class TestTreeBidiMap extends AbstractTestBidiMap {
+public class TestTreeBidiMap extends AbstractTestOrderedBidiMap {
public static void main(String[] args) {
TestRunner.run(suite());
1.1
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAbstractOrderedBidiMapDecorator.java
Index: TestAbstractOrderedBidiMapDecorator.java
===
/*
* $Header:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAbstractOrderedBidiMapDecorator.java,v
1.1 2003/12/30 21:56:17 scolebourne Exp $
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN
Re: [collections] AbstractTestBidiMap issue
This test should fail, as the interface specifies that the result is the
same.
See the TestAbstractOrderedBidiMapDecorator class (of yours ;-) I just
checked in amended. Note the special handling for inverse.
Stephen
- Original Message -
From: Michael Heuer [EMAIL PROTECTED]
In a situation where I have an unit test that extends AbstractTestBidiMap
for a class that extends AbstractBidiMapDecorator,
Testcase: testBidiInverse took 0.01 sec
FAILED
Inverse of inverse is not equal to original. expected same:{key1=value1,
key3=value3, key2=value2} was not:{key1=value1, key3=value3,
key2=value2}
junit.framework.AssertionFailedError: Inverse of inverse is not equal to
original. expected same:{key1=value1, key3=value3, key2=value2} was
not:{key1=value1, key3=value3, key2=value2}
...
This seems a bit odd, assertSame seems to not do the right thing here.
michael
-
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]
DO NOT REPLY [Bug 25811] - [collections] test failures for subclasses of AbstractBidiMapDecorator and friends
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25811. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25811 [collections] test failures for subclasses of AbstractBidiMapDecorator and friends [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 22:00 --- This test has been added to collections, with three fixes - enable setValue - special handling for inverse - setup confirmed collection as TreeMap - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
As others said, if this should not stand in a way of progress and competition. Your clients can still use the current releases of jars that are 1.3, right? They would still be available and source for them would be available. One day you can sell them on 1.4 upgrades. .V Gary Gregory wrote: Our app server product's requirement is 1.3.1. We cannot ask our customer to move to 1.4+. :-( Why? I'll try to be brief. (1) WebSphere is important to our customers and our stuff has to work in WS. The /majority/ of our installed based and prospects are still on the 1.3-based WS. (2) OS upgrades. For new JRE versions, on certain OS's, that means OS patches. For our OS/400 and S/390 customers this is a BIG deal. Gary -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 30, 2003 09:07 To: Jakarta Commons Developers List Subject: Moving up to JVM 1.4+ This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - 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]
DO NOT REPLY [Bug 25830] New: - Upload Progress Reporting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830 Upload Progress Reporting Summary: Upload Progress Reporting Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: File Upload AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Add support for Progress Reporting implementations built on top of commons-fileupload - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
I also work with a large company who is back in the 1.3 days, and they use WAS 4.0. It seems like two releases of suuport is pretty common rule of thumb on this. So, WAS 6.0 is starting public beta, once released, we are two releases from WAS 4.0. Same with JDK 1.3. 1.5 is on the horizon, so then 1.3 is fair game to deprecate at that time (?). For some reason, big companies like to be one release back, but two starts to get them motivated. On Tue, 30 Dec 2003 17:01:51 -0500 Vic Cekvenich [EMAIL PROTECTED] wrote: As others said, if this should not stand in a way of progress and competition. Your clients can still use the current releases of jars that are 1.3, right? They would still be available and source for them would be available. One day you can sell them on 1.4 upgrades. .V Gary Gregory wrote: Our app server product's requirement is 1.3.1. We cannot ask our customer to move to 1.4+. :-( Why? I'll try to be brief. (1) WebSphere is important to our customers and our stuff has to work in WS. The /majority/ of our installed based and prospects are still on the 1.3-based WS. (2) OS upgrades. For new JRE versions, on certain OS's, that means OS patches. For our OS/400 and S/390 customers this is a BIG deal. Gary -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 30, 2003 09:07 To: Jakarta Commons Developers List Subject: Moving up to JVM 1.4+ This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25830] - Upload Progress Reporting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830 Upload Progress Reporting --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 22:25 --- Created an attachment (id=9756) Diffs for supporting Progress Reporting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25830] - Upload Progress Reporting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830 Upload Progress Reporting --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 22:26 --- Created an attachment (id=9757) FileUploadProgressReporter Interface - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25830] - Upload Progress Reporting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830 Upload Progress Reporting --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 22:27 --- Created an attachment (id=9758) Default implementation of a FileUploadProgressReporter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid IdentifierUtils.java
psteitz 2003/12/30 14:36:04
Modified:uid/src/java/org/apache/commons/uid IdentifierUtils.java
Log:
Added initialization methods to avoid class initialization exceptions.
Revision ChangesPath
1.2 +100 -12
jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/IdentifierUtils.java
Index: IdentifierUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/IdentifierUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- IdentifierUtils.java 30 Dec 2003 07:29:17 - 1.1
+++ IdentifierUtils.java 30 Dec 2003 22:36:04 - 1.2
@@ -60,7 +60,13 @@
* identifiers using the identifier generators provided by commons-uid./p
*
* pThis class maintains a static instance of each generator and uses this
instance
- * to generate identifiers in response to its corresponding nextXxx() method./p
+ * to generate identifiers via its corresponding nextXxx() method./p
+ *
+ * pWhen this class is loaded, static instances are initialized using the
currently
+ * configured codeIdentifierGeneratorFactory./code If initialization fails,
+ * the static instances will be codenull/code and the static identifier
generation
+ * methods will throw null pointer exceptions. This will not happen unless a custom
+ * configuration is used and the specified factory class fails to load./p
*
* @author Commons-Uid team
* @version $Id$
@@ -70,8 +76,7 @@
/**
* Static [EMAIL PROTECTED] IdentifierGeneratorFactory} used to create
generator instances
*/
-private static IdentifierGeneratorFactory factory =
-IdentifierGeneratorFactory.newInstance();
+private static IdentifierGeneratorFactory factory = createFactory();
/**
* pSingleton instance of the
@@ -89,7 +94,8 @@
* /ul
*/
public static final LongIdentifierGenerator LONG_IDENTIFIER_GENERATOR =
-factory.longGenerator();
+createLongIdentifierGenerator();
+
/**
* pSingleton instance of the codeStringNumericIdentifierFactory/code.
* /p
@@ -105,9 +111,9 @@
* li.../li
* /ul
*/
-
public static final StringIdentifierGenerator
STRING_NUMERIC_IDENTIFIER_GENERATOR =
-factory.numericGenerator();
+createNumericIdentifierGenerator();
+
/**
* pSingleton instance of the
* codeStringAlphanumericIdentifierFactory/code./p
@@ -132,9 +138,9 @@
* li.../li
* /ul
*/
-
public static final StringIdentifierGenerator
STRING_ALPHANUMERIC_IDENTIFIER_GENERATOR =
-factory.alphanumericGenerator();
+createAlphanumericGenerator();
+
/**
* pSingleton instance of the
* codeStringSessionIdentifierFactory/code./p
@@ -144,9 +150,8 @@
*
* pThe objects returned are 10 or more base-36 digits./p
*/
-
public static final StringIdentifierGenerator
STRING_SESSION_IDENTIFIER_GENERATOR =
-factory.sessionIdGenerator();
+createSessionIdGenerator();
//-
@@ -217,4 +222,87 @@
return STRING_NUMERIC_IDENTIFIER_GENERATOR.nextStringIdentifier();
}
+/**
+ * pGets an IdentifierGeneratorFactory instance to use for
+ *initializing the static factory field./p
+ *
+ * pReturns null if factory creation fails./p
+ *
+ * @return a new IdentifierGeneratorFactory
+ */
+private static IdentifierGeneratorFactory createFactory() {
+try {
+return IdentifierGeneratorFactory.newInstance();
+} catch (Exception ex) {
+return null;
+}
+}
+
+/**
+ * pGets a LongIdentifierGenerator to initialize
+ * LONG_IDENTIFIER_GENERATOR with./p
+ *
+ * pReturns null if instance creation fails./p
+ *
+ * @return a new LongIdentifierGenerator
+ *
+ */
+private static LongIdentifierGenerator createLongIdentifierGenerator() {
+ try {
+ return factory.longGenerator(); // will toss NPE if factory is null
+ } catch (Exception ex) {
+ return null;
+ }
+}
+
+/**
+ * pGets a StringIdentifierGenerator to initialize
+ * STRING_NUMERIC_IDENTIFIER_GENERATOR with./p
+ *
+ * pReturns null if instance creation fails./p
+ *
+ * @return a new NumericGenerator
+ *
+ */
+private static StringIdentifierGenerator createNumericIdentifierGenerator() {
+ try {
+ return factory.numericGenerator(); // will toss NPE if factory is null
+ } catch (Exception ex) {
+ return
RE: [Fileupload] Progress Bar?
David and all, As requested I have added an enhancement request to Bugzilla together with 3 attachments :- 1. Diffs to, FileUploadBase, DiskFileUpload, and MultipartStream to support Progress reporting for disk based file uploads. 2. Source for New interface FileUploadProgressReporter 3. Source for DefaultFileUploadProgressReporter (Not Required). I believe that the requested changes are backward compatible. I should point out that these changes merely enable progress reporting implementations to be built upon the foundation of commons-fileupload. They do not purport to be a complete implementation. I have a working implementation based on this and using additional support in Turbine, but there would be other ways to go using simple servlets or another framework such as Struts. Regards, Peter On Tue, 2003-12-23 at 17:41, David Graham wrote: --- Peter Courcoux [EMAIL PROTECTED] wrote: Hi Yoav, I posted some code to commons-dev in June which provided support (not a complete solution, but sufficient to allow progress reporting to be implemented on top of fileupload) for an implementation I am using. This seems like the correct approach as fileupload has no way of knowing how the progress should be displayed. Providing hooks that the UI can use for display would be useful. To date, aside from promises to look at it, I have received no comment. I am currently working on the http request parsing in turbine and have been considering forking the file-upload code, which originally came from turbine into a fulcrum component to support the fulcrum request parsing. Perfect or not (and its not), I am already using a forked version of commons-fileupload-1.0, providing support for progress reporting in my turbine based applications. I would be delighted if someone would look at it. Have you opened a bugzilla enhancment ticket and attached cvs diff -u formatted patches? David Regards, Peter On Tue, 2003-12-23 at 14:44, Shapira, Yoav wrote: Howdy, Please do NOT submit a bug or even an enhancement request on a progress bar for FileUpload without discussing it here or on commons-user first. This is a significant, non-trivial, highly fraught with bugs area. I've never seen a perfect implementation of this feature yet, so I'd want it rigorously tested before adding it (if possible at all) to fileupload. Yoav Shapira Millennium ChemInformatics -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 9:43 AM To: Commons-Dev (E-mail) Subject: [Fileupload] Progress Bar? Someone posted a long time ago a progress bar for Fileupload. I checked the bug list[1] but didn't see it. Could they submit a bug? Eric Pugh [1] http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status =ASS I GNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1 =1e m ail2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=c hang e din=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonsco mpon e nt=File+Uploadshort_desc=short_desc_type=allwordssubstrlong_desc=lo ng_d e sc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrk eywo r ds=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0- 0=cmdtyp e=doitorder=%27Importance%27 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Courcoux [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Courcoux [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
cvs commit: jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid CustomIdentifierGeneratorFactory.java IdentifierGeneratorFactoryTest.java IdentifierUtilsTest.java
psteitz 2003/12/30 14:48:30
Modified:uid/src/test/org/apache/commons/uid IdentifierUtilsTest.java
Added: uid/src/test/org/apache/commons/uid
CustomIdentifierGeneratorFactory.java
IdentifierGeneratorFactoryTest.java
Log:
Added factory discovery tests.
Revision ChangesPath
1.2 +1 -2
jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/IdentifierUtilsTest.java
Index: IdentifierUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/IdentifierUtilsTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- IdentifierUtilsTest.java 30 Dec 2003 07:29:18 - 1.1
+++ IdentifierUtilsTest.java 30 Dec 2003 22:48:30 - 1.2
@@ -354,7 +354,6 @@
assertEquals(0, b.substring(9)); //Different from [lang], factory is
independent
assertEquals(1, c.substring(9)); //
}
-
//--
}
1.1
jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/CustomIdentifierGeneratorFactory.java
Index: CustomIdentifierGeneratorFactory.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/uid/src/test/org/apache/commons/uid/CustomIdentifierGeneratorFactory.java,v
1.1 2003/12/30 22:48:30 psteitz Exp $
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.uid;
import org.apache.commons.uid.serial.LongGenerator;
/**
* pA custom IdentifierGeneratorFactory used by [EMAIL PROTECTED]
IdentifierGeneratorFactoryTest}./p
*
* pExtends [EMAIL PROTECTED] DefaultIdentifierGeneratorFactory}, overriding the
default
* LongIdentifierGenerator method to return a generator that starts at 100 instead
of 1./p
*
* @author Commons-Uid team
* @version $id$
*/
public class CustomIdentifierGeneratorFactory extends
DefaultIdentifierGeneratorFactory {
/** Creates a new instance of CustomIdentifierGeneratorFactory */
public
cvs commit: jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/serial LongGenerator.java
psteitz 2003/12/30 14:51:01
Modified:uid/src/java/org/apache/commons/uid/serial
LongGenerator.java
Log:
Fixed error in minValue.
Revision ChangesPath
1.2 +3 -3
jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/serial/LongGenerator.java
Index: LongGenerator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/serial/LongGenerator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LongGenerator.java30 Dec 2003 07:29:18 - 1.1
+++ LongGenerator.java30 Dec 2003 22:51:01 - 1.2
@@ -104,7 +104,7 @@
* @return the minimum idendifier value
*/
public long minValue() {
-return Long.MIN_VALUE;
+return 0;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
Quoting Stephen Colebourne [EMAIL PROTECTED]: The block on 1.4 remains the big-iron webservers, like Websphere and Weblogic. 1.4 as a requirement is a long way off yet IMHO. FWIW, one of the major roadblocks for the app server vendors was that J2EE 1.4 (which in turn requires J2SE 1.4) wasn't final until the end of November. It is now, so you'll likely see the 1.4 versions of these app servers become available (in addition to the ones that already exist). Of course, that still doesn't mean people will upgrade in any particular hurry, but at least it will be possible. Stephen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] test
Please excuse, testing mail filters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] test
One more time. sorry. On Tuesday 30 December 2003 05:09 pm, steve cohen wrote: Please excuse, testing mail filters. - 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]
DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818 BinaryHeap.remove(Object) seems to break heap order --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 23:47 --- The problem lies with the remove 19. Unfortunately, I don't understand the meachanics of this class, so I could be stuck solving it :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Bill Barker - Commons Proper Committer
Quoting Shapira, Yoav [EMAIL PROTECTED]: Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because Yoav Shapira Millennium ChemInformatics Looks like enough +1s to me ... karma granted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fileupload] Progress bar
Hi all, I have an alternate implementation to bug 25830 submitted by Peter Courcoux (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830) -- adding progress/status to file uploads. Since I've never submitted code to Bugzilla before, can someone steer me in the right direction? Is it better to post here, or somehow attach it to Bugzilla directly, or both? Thank you in advance, Eric H. Jung Russell/Mellon Analytical Services 1-617-382-1373 Everett, MA, USA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fileupload] Progress bar
--- Jung, Eric (Contractor) [EMAIL PROTECTED] wrote: Hi all, I have an alternate implementation to bug 25830 submitted by Peter Courcoux (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830) -- adding progress/status to file uploads. Since I've never submitted code to Bugzilla before, can someone steer me in the right direction? Is it better to post here, or somehow attach it to Bugzilla directly, or both? Create a new bugzilla enhancement ticket then go back to your new ticket and attach the files to it. Patches sent to the mailing list have a high probability of getting lost. David Thank you in advance, Eric H. Jung Russell/Mellon Analytical Services 1-617-382-1373 Everett, MA, USA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon STATUS.html project.xml
billbarker2003/12/30 19:53:52 Modified:daemon STATUS.html project.xml Log: Adding myself to the project. Revision ChangesPath 1.2 +2 -1 jakarta-commons/daemon/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/daemon/STATUS.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- STATUS.html 4 Sep 2003 23:28:20 - 1.1 +++ STATUS.html 31 Dec 2003 03:53:52 - 1.2 @@ -66,6 +66,7 @@ liCostin Manolache/li liRemy Maucherat/li liYoav Shapira/li +liBill Barker/li /ul 1.5 +7 -0 jakarta-commons/daemon/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/daemon/project.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- project.xml 26 Sep 2003 14:45:13 - 1.4 +++ project.xml 31 Dec 2003 03:53:52 - 1.5 @@ -35,6 +35,13 @@ email[EMAIL PROTECTED]/email organizationApache/organization /developer + +developer + nameBill Barker/name + idbillbarker/id + email[EMAIL PROTECTED]/email + organizationApache/organization +/developer /developers /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Bill Barker - Commons Proper Committer
+1 On Tue, Dec 30, 2003 at 08:54:23AM -0500, Shapira, Yoav wrote: Howdy, I think everyone knows Bill Barker already ;) He's done a ton of work on tomcat and related jakarta projects, including some in the commons-sandbox. Now that commons-daemon is in the Commons Proper, I'd still like to have his help and I think he'd like to help as well, but we need a vote it seems. So here's my +1. [ X ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23310] - Procrun source files contain spurious ^M
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23310. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23310 Procrun source files contain spurious ^M [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-31 04:09 --- Long long ago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.c
billbarker2003/12/30 20:43:15
Modified:daemon/src/native/nt/procrun procrun.c
Log:
1) Allow the --Java to simply be where java is installed, instead of the full
path to the jvm.dll.
2) When running --Java=java, use the JVM specified in JAVA_HOME over the one
specified in the registry.
Fix for Bug #25789
Revision ChangesPath
1.11 +79 -25jakarta-commons/daemon/src/native/nt/procrun/procrun.c
Index: procrun.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- procrun.c 6 Dec 2003 18:10:53 - 1.10
+++ procrun.c 31 Dec 2003 04:43:15 - 1.11
@@ -787,37 +787,41 @@
char *cver;
unsigned long err, klen = MAX_PATH;
-strcpy(reg, JAVASOFT_REGKEY);
-cver = reg[sizeof(JAVASOFT_REGKEY)-1];
+if((cver = getenv(JAVA_HOME)) != NULL) {
+strcpy(jbin,cver);
+} else {
+strcpy(reg, JAVASOFT_REGKEY);
+cver = reg[sizeof(JAVASOFT_REGKEY)-1];
-if ((err = RegOpenKeyEx(HKEY_LOCAL_MACHINE, reg,
+if ((err = RegOpenKeyEx(HKEY_LOCAL_MACHINE, reg,
0, KEY_READ, hkjs)) != ERROR_SUCCESS) {
- DBPRINTF0(procrun_guess_jvm() failed to open Registry key\n);
- return NULL;
-}
-if ((err = RegQueryValueEx(hkjs, CurrentVersion, NULL, NULL,
+ DBPRINTF0(procrun_guess_jvm() failed to open Registry key\n);
+ return NULL;
+}
+if ((err = RegQueryValueEx(hkjs, CurrentVersion, NULL, NULL,
(unsigned char *)cver,
klen)) != ERROR_SUCCESS) {
-DBPRINTF0(procrun_guess_jvm() failed obtaining Current Java Version\n);
+DBPRINTF0(procrun_guess_jvm() failed obtaining Current Java
Version\n);
+RegCloseKey(hkjs);
+return NULL;
+}
RegCloseKey(hkjs);
-return NULL;
-}
-RegCloseKey(hkjs);
-if ((err = RegOpenKeyEx(HKEY_LOCAL_MACHINE, reg,
+if ((err = RegOpenKeyEx(HKEY_LOCAL_MACHINE, reg,
0, KEY_READ, hkjs) ) != ERROR_SUCCESS) {
-DBPRINTF1(procrun_guess_jvm() failed to open Registry key %s\n, reg);
-return NULL;
-}
-klen = MAX_PATH;
-if ((err = RegQueryValueEx(hkjs, JavaHome, NULL, NULL,
+DBPRINTF1(procrun_guess_jvm() failed to open Registry key %s\n, reg);
+return NULL;
+}
+klen = MAX_PATH;
+if ((err = RegQueryValueEx(hkjs, JavaHome, NULL, NULL,
(unsigned char *)jbin,
klen)) != ERROR_SUCCESS) {
-DBPRINTF0(procrun_guess_jvm() failed obtaining Java path\n);
+DBPRINTF0(procrun_guess_jvm() failed obtaining Java path\n);
+RegCloseKey(hkjs);
+return NULL;
+}
RegCloseKey(hkjs);
-return NULL;
}
-RegCloseKey(hkjs);
strcat(jbin, \\bin\\);
strcat(jbin, image);
strcat(jbin, .exe);
@@ -1950,7 +1954,35 @@
RegCloseKey(key);
return (err != ERROR_SUCCESS);
}
-
+static const char *location_jvm_default[] = {
+\\jre\\bin\\classic\\jvm.dll, /* Sun JDK 1.3 */
+\\bin\\classic\\jvm.dll,/* Sun JRE 1.3 */
+\\jre\\bin\\client\\jvm.dll,/* Sun JDK 1.4 */
+\\bin\\client\\jvm.dll, /* Sun JRE 1.4 */
+NULL,
+};
+
+/*
+ * Attempt to locate the jvm from the installation.
+ */
+static char *procrun_find_java(process_t *proc, char *jhome)
+{
+ char path[MAX_PATH+1];
+ int x = 0;
+ HMODULE hm;
+ for(x=0; location_jvm_default[x] != NULL; x++) {
+ strcpy(path,jhome);
+ strcat(path,location_jvm_default[x]);
+ hm = LoadLibraryEx(path, NULL, 0);
+ if(hm != NULL) {
+ DBPRINTF1(Found library at %s\n,path);
+ FreeLibrary(hm);
+ return pool_strdup(proc-pool, path);
+ }
+ }
+ return NULL;
+}
+
/*
* Process the arguments and fill the process_t stuct.
*/
@@ -2027,9 +2059,19 @@
break;
}
}
-if (*java !strnicmp(*java, java, 4))
+if (*java !strnicmp(*java, java, 4)) {
arglen = strlen(*java) + 1;
-else if (proc-service.name)
+} else if(*java) {
+int jlen = strlen(*java) +1;
+if(stricmp(*java+(jlen-5),.dll)) {
+/* Assume it is the java installation */
+char *njava = procrun_find_java(proc, *java);
+DBPRINTF1(Attempting to locate jvm from %s\n,*java);
+if(njava != NULL) {
+ *java = njava;
+}
cvs commit: jakarta-commons/daemon/xdocs procrun.xml
billbarker2003/12/30 20:45:18 Modified:daemon/xdocs procrun.xml Log: Document changes. Revision ChangesPath 1.6 +3 -1 jakarta-commons/daemon/xdocs/procrun.xml Index: procrun.xml === RCS file: /home/cvs/jakarta-commons/daemon/xdocs/procrun.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- procrun.xml 28 Sep 2003 12:12:44 - 1.5 +++ procrun.xml 31 Dec 2003 04:45:18 - 1.6 @@ -82,7 +82,9 @@ located and executed with -Djava.class.path=ImagePath/li liIf neither java or auto are specified then this -parameter is treated as full path to the jvm.dll/li +parameter is treated as either the full path to the +codejvm.dll/code, or as the path to the Java +installation./li /ul/td/tr trth--JavaOptions/th td This is the list of options to be passed to the JVM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25789] - [PATCH] Procrun Improvements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25789. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25789 [PATCH] Procrun Improvements [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-31 04:45 --- Patches committed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/unix/native home.c
billbarker2003/12/30 20:52:30
Modified:daemon/src/native/unix/native home.c
Log:
Fix parsing of 'jvm.cfg' files for the new 1.4.x format.
Fix for Bug #25790
Revision ChangesPath
1.2 +6 -2 jakarta-commons/daemon/src/native/unix/native/home.c
Index: home.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/native/home.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- home.c4 Sep 2003 23:28:20 - 1.1
+++ home.c31 Dec 2003 04:52:30 - 1.2
@@ -81,7 +81,7 @@
/* Parse a VM configuration file */
static bool parse(home_data *data) {
FILE *cfgf=fopen(data-cfgf,r);
-char *ret=NULL;
+char *ret=NULL, *sp;
char buf[1024];
if (cfgf==NULL) return(false);
@@ -104,6 +104,10 @@
ret[pos--]='\0';
} else break;
}
+/* Format changed for 1.4 JVMs */
+sp = strchr(ret, ' ');
+if(sp != NULL)
+*sp = '\0'
/* Did we find something significant? */
if (strlen(ret)0) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25790] - [PATCH] jsvc can't parse jvm.cfg file for 1.4 JVMs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25790. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25790 [PATCH] jsvc can't parse jvm.cfg file for 1.4 JVMs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-31 04:52 --- Patch applied - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/unix/native arguments.c debug.h home.c
billbarker2003/12/30 20:58:31
Modified:daemon/src/native/unix/native arguments.c debug.h home.c
Log:
Avoid NPEs when JAVA_HOME is not defined on debug build.
Fix for Bug #23722
Revision ChangesPath
1.2 +6 -6 jakarta-commons/daemon/src/native/unix/native/arguments.c
Index: arguments.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/native/arguments.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- arguments.c 4 Sep 2003 23:28:20 - 1.1
+++ arguments.c 31 Dec 2003 04:58:31 - 1.2
@@ -286,15 +286,15 @@
log_debug(| Remove service: %s,IsYesNo(args-remove));
-log_debug(| JVM Name:\%s\,args-name);
-log_debug(| Java Home: \%s\,args-home);
-log_debug(| PID File:\%s\,args-pidf);
-log_debug(| User Name: \%s\,args-user);
+log_debug(| JVM Name:\%s\,PRINT_NULL(args-name));
+log_debug(| Java Home: \%s\,PRINT_NULL(args-home));
+log_debug(| PID File:\%s\,PRINT_NULL(args-pidf));
+log_debug(| User Name: \%s\,PRINT_NULL(args-user));
log_debug(| Extra Options: %d,args-onum);
for (x=0; xargs-onum; x++) log_debug(| \%s\,args-opts[x]);
-log_debug(| Class Invoked: \%s\,args-clas);
+log_debug(| Class Invoked: \%s\,PRINT_NULL(args-clas));
log_debug(| Class Arguments: %d,args-anum);
for (x=0; xargs-anum; x++)log_debug(| \%s\,args-args[x]);
1.2 +6 -1 jakarta-commons/daemon/src/native/unix/native/debug.h
Index: debug.h
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/native/debug.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- debug.h 4 Sep 2003 23:28:20 - 1.1
+++ debug.h 31 Dec 2003 04:58:31 - 1.2
@@ -73,6 +73,11 @@
extern char *log_prog;
/**
+ * Helper macro to avoid NPEs in printf.
+ */
+#define PRINT_NULL(x) ((x) == NULL ? null : (x))
+
+/**
* Dump a debug message.
*
* @param fmt The printf style message format.
1.3 +3 -3 jakarta-commons/daemon/src/native/unix/native/home.c
Index: home.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/native/home.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- home.c31 Dec 2003 04:52:30 - 1.2
+++ home.c31 Dec 2003 04:58:31 - 1.3
@@ -267,8 +267,8 @@
if (log_debug_flag==true) {
log_debug(+-- DUMPING JAVA HOME STRUCTURE );
-log_debug(| Java Home: \%s\,data-path);
-log_debug(| Java VM Config.: \%s\,data-cfgf);
+log_debug(| Java Home: \%s\,PRINT_NULL(data-path));
+log_debug(| Java VM Config.: \%s\,PRINT_NULL(data-cfgf));
log_debug(| Found JVMs: %d,data-jnum);
for (x=0; xdata-jnum; x++) {
home_jvm *jvm=data-jvms[x];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23722] - jsvc cores when JAVA_HOME is not defined
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23722. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23722 jsvc cores when JAVA_HOME is not defined [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-31 04:58 --- patch applied - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/unix/native jsvc-unix.c
billbarker2003/12/30 21:03:26
Modified:daemon/src/native/unix/native jsvc-unix.c
Log:
Fix problems with signal handling on Solaris (possibly others).
Fix for Bug #24247
Reported By: Peter Poloha [EMAIL PROTECTED]
Revision ChangesPath
1.8 +4 -4 jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c
Index: jsvc-unix.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jsvc-unix.c 27 Sep 2003 16:49:13 - 1.7
+++ jsvc-unix.c 31 Dec 2003 05:03:25 - 1.8
@@ -271,10 +271,10 @@
/*
* Return the address of the current signal handler and set the new one.
*/
-static void * signal_set(int sig, void * handler) {
+static void * signal_set(int sig, void * newHandler) {
void *hand;
-hand=signal(sig,handler);
+hand=signal(sig,newHandler);
#ifdef SIG_ERR
if (hand==SIG_ERR)
hand=NULL;
@@ -350,7 +350,7 @@
/* Install signal handlers */
handler_hup=signal_set(SIGHUP,handler);
handler_trm=signal_set(SIGTERM,handler);
-handler_trm=signal_set(SIGINT,handler);
+handler_int=signal_set(SIGINT,handler);
controlled = getpid();
log_debug(Waiting for a signal to be delivered);
while (!stopping) sleep(60); /* pause() not threadsafe */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24247] - signal handling on Solaris 5.8
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24247. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24247 signal handling on Solaris 5.8 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-31 05:03 --- Fixed now in the CVS, and should appear in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes : failing but on a different line. I'm not sure what platform Jeff is on when he did the build, but I think I should rewrite this test in a way that doesn't assume any particular order since this seems to be JDK-implementation dependent. The JavaDoc for HashMap specifies no order that should be expected for HashMap.values(), nor for HashMap.keySet() for that matter. We could probably achieve a dependable order by using a TreeMap.keySet() instead. +1 However, this brings up the larger question, of what the target platform for commons-net is. I dimly remember that it being java 1.1. This is why I went through the annoying exercise of creating the FTPFileList and FTPFileIterator classes based on java-1.1-compatible containers like Vector. If we are now using HashMaps, though, we will have violated this contract, if, in fact, such a contract exists. Can someone clarify this question? This is a good question. At first I was going to say it doesn't impact the tests; but if your tests are dependent on a specific JDK, then you never run them on other JDKs. I'm of the mind that we ought to agree on a plan to migrate to J2SE 1.4 features. Still, there's the issue of Ant, which has a dependency on commons net. I know they abandoned JDK 1.1 support in the latest release, but is their new baseline J2SE 1.2 or 1.4? Anyone who needs JDK 1.1 support can live with the 1.1 release and we can support it in a separate branch applying bug fixes if there is sufficient demand. Another alternative is to start an experimental branch intended to become Commons Net 2.0 and continue releasing 1.x releases that meet Ant's compatibility requirements. Commons Net 2.0 could be a fundamental redesign and reimplementation based on the new IO features present in J2SE 1.4. The guts of the code would change, but not all of the protocol logic built around it, so it's not like it would be a complete rewrite. A lot of the kluginess in Commons Net stems from the lack of java.nio at its genesis. At any rate, until we hash some of this out in more detail, my vote is to support whatever Ant requires for compatibility. If it's J2SE 1.2, then HashMaps are okay in the unit tests. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24327] - MS Proxy with NTLM authentication set up does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24327. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24327 MS Proxy with NTLM authentication set up does not work --- Additional Comments From [EMAIL PROTECTED] 2003-12-30 23:52 --- Hello, this is Alfonso again. Excuse me for the delay in testing. I've downloaded the 2.0 rc 2 (dated Oct 13) and tried my app. The library fails to authenticate properly. What is the procedure now. ¿ Should this bug be reopen or a new one created ? I don't remember some of this, but as I need this feature working, can you tell me what was wrong with my initial sugested correction ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
