cvs commit: jakarta-commons/docs/releases index.html mirror.html prepare.html release.html
psteitz 2004/01/04 23:02:09 Modified:docs beanutils.html charter.html collections.html commons.html contributors.html dbcp.html digester.html directory.html discovery.html el.html index.html jexl.html lang.html license.html logging.html modeler.html patches.html pool.html releases.html sandbox.html versioning.html volunteering.html docs/releases index.html mirror.html prepare.html release.html Log: Updated html to reflect Configuration promotion. Revision ChangesPath 1.96 +4 -2 jakarta-commons/docs/beanutils.html Index: beanutils.html === RCS file: /home/cvs/jakarta-commons/docs/beanutils.html,v retrieving revision 1.95 retrieving revision 1.96 diff -u -r1.95 -r1.96 --- beanutils.html7 Dec 2003 19:27:40 - 1.95 +++ beanutils.html5 Jan 2004 07:02:08 - 1.96 @@ -103,6 +103,8 @@ /li lia href=http://jakarta.apache.org/commons/collections.html;Collections/a /li +lia href=http://jakarta.apache.org/commons/configuration;Configuration/a +/li lia href=http://jakarta.apache.org/commons/daemon;Daemon/a /li lia href=http://jakarta.apache.org/commons/dbcp;DBCP/a @@ -158,7 +160,7 @@ /li lia href=http://jakarta.apache.org/commons/sandbox/compress/;Compress/a /li -lia href=http://jakarta.apache.org/commons/sandbox/configuration/;Configuration/a +lia href=http://jakarta.apache.org/commons/sandbox/convert/;Convert/a /li lia href=http://jakarta.apache.org/commons/sandbox/events/;Events/a /li @@ -349,7 +351,7 @@ /td/tr trtd colspan=2 div align=centerfont color=#525D76 size=-1em -Copyright #169; 1999-2003, Apache Software Foundation +Copyright #169; 1999-2004, Apache Software Foundation /em/font/div /td/tr /table 1.92 +4 -2 jakarta-commons/docs/charter.html Index: charter.html === RCS file: /home/cvs/jakarta-commons/docs/charter.html,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- charter.html 7 Dec 2003 19:27:40 - 1.91 +++ charter.html 5 Jan 2004 07:02:08 - 1.92 @@ -103,6 +103,8 @@ /li lia href=http://jakarta.apache.org/commons/collections.html;Collections/a /li +lia href=http://jakarta.apache.org/commons/configuration;Configuration/a +/li lia href=http://jakarta.apache.org/commons/daemon;Daemon/a /li lia href=http://jakarta.apache.org/commons/dbcp;DBCP/a @@ -158,7 +160,7 @@ /li lia href=http://jakarta.apache.org/commons/sandbox/compress/;Compress/a /li -lia href=http://jakarta.apache.org/commons/sandbox/configuration/;Configuration/a +lia href=http://jakarta.apache.org/commons/sandbox/convert/;Convert/a /li lia href=http://jakarta.apache.org/commons/sandbox/events/;Events/a /li @@ -621,7 +623,7 @@ /td/tr trtd colspan=2 div align=centerfont color=#525D76 size=-1em -Copyright #169; 1999-2003, Apache Software Foundation +Copyright #169; 1999-2004, Apache Software Foundation /em/font/div /td/tr /table 1.82 +4 -2 jakarta-commons/docs/collections.html Index: collections.html === RCS file: /home/cvs/jakarta-commons/docs/collections.html,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- collections.html 7 Dec 2003 19:27:40 - 1.81 +++ collections.html 5 Jan 2004 07:02:08 - 1.82 @@ -103,6 +103,8 @@ /li lia href=http://jakarta.apache.org/commons/collections.html;Collections/a /li +lia href=http://jakarta.apache.org/commons/configuration;Configuration/a +/li lia href=http://jakarta.apache.org/commons/daemon;Daemon/a /li lia href=http://jakarta.apache.org/commons/dbcp;DBCP/a @@ -158,7 +160,7 @@ /li lia
[discovery] maven/ibibilo seems wrong for disvovery
if I look at: http://www.ibiblio.org/maven/commons-discovery/jars/ I've got to think that something is badly screwed up. 0.2, the latest released version of discovery is not available, though 0.1 is. However, there is a 1.0 available from 6 months prior to the 0.1, though it is mis-named 'discover'. Any chance of a) Killing the discover? Or at least putting it in commons-discover if such a thing existed. b) uploading commons-discovery 0.2? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discovery] maven/ibibilo seems wrong for disvovery
In addition: The download link to binindex.cgi doesn't use the # a name and the commons-discovery-0.2.tar.gz contains a commons-discovery.jar and not a commons-discovery-0.2.jar. Unsure if either of these are meant to be standardised on, but I think they should be. Hen On Mon, 5 Jan 2004, Henri Yandell wrote: if I look at: http://www.ibiblio.org/maven/commons-discovery/jars/ I've got to think that something is badly screwed up. 0.2, the latest released version of discovery is not available, though 0.1 is. However, there is a 1.0 available from 6 months prior to the 0.1, though it is mis-named 'discover'. Any chance of a) Killing the discover? Or at least putting it in commons-discover if such a thing existed. b) uploading commons-discovery 0.2? Hen - 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]
cvs commit: jakarta-commons-sandbox/id - New directory
psteitz 2004/01/04 23:47:06 jakarta-commons-sandbox/id - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src - New directory
psteitz 2004/01/04 23:48:04 jakarta-commons-sandbox/id/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/xdocs - New directory
psteitz 2004/01/04 23:48:14 jakarta-commons-sandbox/id/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java - New directory
psteitz 2004/01/04 23:48:39 jakarta-commons-sandbox/id/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org - New directory
psteitz 2004/01/04 23:49:00 jakarta-commons-sandbox/id/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache - New directory
psteitz 2004/01/04 23:49:14 jakarta-commons-sandbox/id/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons - New directory
psteitz 2004/01/04 23:49:35 jakarta-commons-sandbox/id/src/java/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id - New directory
psteitz 2004/01/04 23:49:51 jakarta-commons-sandbox/id/src/java/org/apache/commons/id - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid - New directory
psteitz 2004/01/04 23:50:13 jakarta-commons-sandbox/id/src/java/org/apache/commons/id/uuid - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/random - New directory
psteitz 2004/01/04 23:50:22 jakarta-commons-sandbox/id/src/java/org/apache/commons/id/random - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discovery] maven/ibibilo seems wrong for disvovery
commons-discover is gone. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Henri Yandell [EMAIL PROTECTED] wrote on 05/01/2004 06:29:03 PM: if I look at: http://www.ibiblio.org/maven/commons-discovery/jars/ I've got to think that something is badly screwed up. 0.2, the latest released version of discovery is not available, though 0.1 is. However, there is a 1.0 available from 6 months prior to the 0.1, though it is mis-named 'discover'. Any chance of a) Killing the discover? Or at least putting it in commons-discover if such a thing existed. b) uploading commons-discovery 0.2? Hen - 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]
cvs commit: jakarta-commons-sandbox/id/src/java/org/apache/commons/id/serial - New directory
psteitz 2004/01/04 23:50:43 jakarta-commons-sandbox/id/src/java/org/apache/commons/id/serial - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/test - New directory
psteitz 2004/01/04 23:51:14 jakarta-commons-sandbox/id/src/test - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/test/org - New directory
psteitz 2004/01/04 23:51:28 jakarta-commons-sandbox/id/src/test/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/id/src/test/org/apache - New directory
psteitz 2004/01/04 23:51:46 jakarta-commons-sandbox/id/src/test/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote io from commons-sandbox to commons-proper
--- Vote: Promote commons-io to commons proper [ ] +1 I am in favor of the move, and will help support it [ X ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [ ] -1 I am against this proposal (must include a reason). --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] maven site Was: [collections] What is left to do for 3.0?
I favour keeping the default navigation, but adding the useful ones to the top, see http://joda-time.sourceforge.net sortof like what you've done. Stephen from:Henri Yandell [EMAIL PROTECTED] Any thoughts on not using Maven's 'Project Documentation' standard bit in the corner? I've been playing with sites that throw it all away and define their own navigation completely and quite like the result: http://www.osjava.org/norbert/ So many of the Maven reports are just extra noise. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] Uuid
I can understand this POV, but I favour FTPUNIXXMLThing. In our example here, UUIDFactory just seems better than UuidFactory to me. Stephen from:__matthewHawthorne [EMAIL PROTECTED] Gary Gregory wrote: I prefer treating acronyms as words (Uuid), which avoids IMO silly and *unreadable* names like FTPUNIXXMLThing in favor or FtpUnixXmlThing. Gary I agree. Once you have a class with more than 1 acronym in the name, things get out of hand. I feel that this is a nice consistent approach to producing readable names. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAEMON] Problems with JSVC and Solaris 9
Hello, this is my first post in this list. I'm not an expert so I apologize for any mistake in the description of the problem. Scenario - Hardware: SunFire V210 (sparc) - OS: Solaris 9 - Common daemons version: I'm using the JSVC source code included with Tomcat 5.0.16 release. Main problem: I compile jsvc source code following the indications in http://jakarta.apache.org/tomcat/tomcat-5.0-doc/setup.html without errors. I run jsvc with the following command $CATALINA_HOME/bin/jsvc -user tomcat -Djava.endorsed.dirs=$CATALINA_HOME/common/endorsed -cp $CATALINA_HOME/bin/bootstrap.jar -outfile /export/logs/tomcat/catalina.out -errfile /export/logs/tomcat/catalina.err -pidfile $CATALINA_HOME/bin/jsvc.pid org.apache.catalina.startup.Bootstrap The Tomcat server started and the user change is made. No problems here. The problem is in the shoutdown. When I kill the process with the command kill #process_number_in_jsvc.pid the server stops but if I have a look to the errfile (catalina.err) I see that in the last line jsvc error: Service exit with a return value of 143. And the most important thing is that tomcat didn't stop correctly. When I have a look to tomcat's log there are no references to the shutdown, the last line is INFO: Server startup in 8109 ms (usually when you stop Tomcat without using JSVC there are always some lines in the log describing the shtdown process). I try to track the program with debug mode. I also add a print line after waitpid() in the parent process to know the status value before processing it with wstat macros. Here it is, I hope it can be helpful: $CATALINA_HOME/bin/jsvc -verbose -debug -jvm server -home /usr/local/java -user tomcat -Djava.endorsed.dirs=$CATALINA_HOME/common/endorsed -cp $CATALINA_HOME/bin/bootstrap.jar -outfile /export/logs/tomcat/catalina.out -errfile /export/logs/tomcat/catalina.err -pidfile $CATALINA_HOME/bin/jsvc.pid org.apache.catalina.startup.Bootstrap jsvc debug: +-- DUMPING PARSED COMMAND LINE ARGUMENTS -- jsvc debug: | Detach: True jsvc debug: | Show Version:No jsvc debug: | Show Help: No jsvc debug: | Check Only: Disabled jsvc debug: | Run as service: No jsvc debug: | Install service: No jsvc debug: | Remove service: No jsvc debug: | JVM Name:server jsvc debug: | Java Home: /usr/local/java jsvc debug: | PID File:/usr/local/tomcat/bin/jsvc.pid jsvc debug: | User Name: tomcat jsvc debug: | Extra Options: 3 jsvc debug: | -verbose jsvc debug: | -Djava.endorsed.dirs=/usr/local/tomcat/common/endorsed jsvc debug: | -Djava.class.path=/usr/local/tomcat/bin/bootstrap.jar jsvc debug: | Class Invoked: org.apache.catalina.startup.Bootstrap jsvc debug: | Class Arguments: 0 jsvc debug: +--- jsvc debug: user changed to 'tomcat' jsvc debug: User 'tomcat' validated jsvc debug: Attempting to locate Java Home in /usr/local/java jsvc debug: Attempting to locate VM configuration file /usr/local/java/jre/lib/jvm.cfg jsvc debug: Found VM configuration file at /usr/local/java/jre/lib/jvm.cfg jsvc debug: Found VM client definition in configuration jsvc debug: Checking library /usr/local/java/jre/lib/sparc/client/libjvm.so jsvc debug: Found VM hotspot definition in configuration jsvc debug: Checking library /usr/local/java/jre/lib/sparc/hotspot/libjvm.so jsvc debug: Checking library /usr/local/java/lib/sparc/hotspot/libjvm.so jsvc debug: Cannot locate library for VM hotspot (skipping) jsvc debug: Found VM server definition in configuration jsvc debug: Checking library /usr/local/java/jre/lib/sparc/server/libjvm.so jsvc debug: Found VM classic definition in configuration jsvc debug: Checking library /usr/local/java/jre/lib/sparc/classic/libjvm.so jsvc debug: Checking library /usr/local/java/lib/sparc/classic/libjvm.so jsvc debug: Cannot locate library for VM classic (skipping) jsvc debug: Java Home located in /usr/local/java jsvc debug: +-- DUMPING JAVA HOME STRUCTURE jsvc debug: | Java Home: /usr/local/java jsvc debug: | Java VM Config.: /usr/local/java/jre/lib/jvm.cfg jsvc debug: | Found JVMs: 2 jsvc debug: | JVM Name:client jsvc debug: | /usr/local/java/jre/lib/sparc/client/libjvm.so jsvc debug: | JVM Name:server jsvc debug: | /usr/local/java/jre/lib/sparc/server/libjvm.so jsvc debug: +--- [EMAIL PROTECTED]:/usr/local/tomcat/bin# more jsvc.pid 16253 [EMAIL PROTECTED]:/usr/local/tomcat/bin# kill 16253 [EMAIL PROTECTED]:/usr/local/tomcat/bin# more /export/logs/tomcat/catalina.err jsvc debug: Using specific JVM in /usr/local/java/jre/lib/sparc/server/libjvm.so jsvc debug: Attemtping to load library /usr/local/java/jre/lib/sparc/server/libjvm.so jsvc debug: JVM library /usr/local/java/jre/lib/sparc/server/libjvm.so loaded jsvc debug: JVM library entry point found (0xFEEE6F5C) jsvc debug: +-- DUMPING JAVA VM CREATION ARGUMENTS -
[jira] Created: (JELLY-102) multiple calls to multiproject gives erroneous No Action Definition
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-102 Here is an overview of the issue: - Key: JELLY-102 Summary: multiple calls to multiproject gives erroneous No Action Definition Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: jelly Components: core / taglib.core Assignee: Reporter: Nathan Coast Created: Mon, 5 Jan 2004 7:32 AM Updated: Mon, 5 Jan 2004 7:32 AM Description: attainGoal name=multiproject:install/ attainGoal name=multiproject:site/ these goals execute no problem independently but when I execute them sequentially within some maven.xml I get the following error: org.apache.commons.jelly.JellyTagException: file:/D:/apache/maven/plugins/maven-site-plugin-1.3/:22: 42: attainGoal Goal [xdoc:register-reports] has no action definition. at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:159) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:360) cheers Nathan - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote io from commons-sandbox to commons-proper
Howdy, I'd like to go ahead and call a vote for 'io' to be promoted from commons-sandbox to commons-proper. --- Vote: Promote commons-io to commons proper [ ] +1 I am in favor of the move, and will help support it [ X ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [ ] -1 I am against this proposal (must include a reason). --- Yoav Shapira 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: [Daemon] Update tomcat.sh for TC 5?
Howdy, +1 to having both tocmat4.sh and tomcat5.sh. (And X.sh for every server X we wish to support out of the box with daemon). Yoav Shapira Millennium ChemInformatics -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker Sent: Sunday, January 04, 2004 2:31 AM To: [EMAIL PROTECTED] Subject: Re: [Daemon] Update tomcat.sh for TC 5? Noel J. Bergman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] is it time to update the script to work with Tomcat 5 (and change the docs to say how to modify it for Tomcat 4.1.x)? What is the nature of the change? Does it make sense to copy the current one to tomcat4.sh, and then make the modifications for TC5? Or I suppose you could just tag the current one, so that someone could pull it from CVS. The changes are pretty minor. Mostly the startup class has changed from 'BootstrapService' to 'Bootstrap'. Also adding commons-logging-api.jar to the boot classpath. I have no objection to adding a 'tomcat4.sh' file. However, jsvc has never shipped-with TC 4, so it likely has a smaller user-base. But I like the suggestion :). --- Noel - 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]
cvs commit: jakarta-commons-sandbox/id project.xml project.properties checkstyle.xml
psteitz 2004/01/05 06:29:35
Modified:id project.xml project.properties checkstyle.xml
Log:
Made changes to project config submitted by Tim Reilly in PR #25894.
Revision ChangesPath
1.2 +1 -1 jakarta-commons-sandbox/id/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/id/project.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.xml 5 Jan 2004 08:10:56 - 1.1
+++ project.xml 5 Jan 2004 14:29:35 - 1.2
@@ -1,6 +1,6 @@
?xml version=1.0?
project
- extend../../jakarta-commons/xdocs/maven/project-base.xml/extend
+ extend${commons.project.extendsUri}project-base.xml/extend
nameCommons Id/name
idcommons-id/id
logo/logo
1.2 +3 -0 jakarta-commons-sandbox/id/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/id/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties5 Jan 2004 08:10:56 - 1.1
+++ project.properties5 Jan 2004 14:29:35 - 1.2
@@ -22,4 +22,7 @@
maven.junit.sysproperties=org.xml.sax.driver
org.xml.sax.driver=org.apache.xerces.parsers.SAXParser
+commons.project.extendsUri=../../jakarta-commons/xdocs/maven/
+
+
1.2 +1 -0 jakarta-commons-sandbox/id/checkstyle.xml
Index: checkstyle.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/id/checkstyle.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- checkstyle.xml5 Jan 2004 08:10:56 - 1.1
+++ checkstyle.xml5 Jan 2004 14:29:35 - 1.2
@@ -38,6 +38,7 @@
/module
module name=LineLength
property name=max value=132/
+ property name=ignorePattern value=\* \$/
/module
module name=MethodLength
property name=max value=175/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25894] - [id] 2 Project related enhancements
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=25894. 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=25894 [id] 2 Project related enhancements [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 14:30 --- Patches applied. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor LICENSE.txt
rwaldhoff2004/01/05 07:57:38 Modified:functor LICENSE.txt Log: update copyright year, remove $Header$ Revision ChangesPath 1.2 +1 -3 jakarta-commons-sandbox/functor/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons-sandbox/functor/LICENSE.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- LICENSE.txt 27 Jan 2003 19:33:37 - 1.1 +++ LICENSE.txt 5 Jan 2004 15:57:38 - 1.2 @@ -1,9 +1,7 @@ /* - * $Header$ - * * The Apache Software License, Version 1.1 * - * Copyright (c) 2003 The Apache Software Foundation. All rights + * Copyright (c) 2003-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] EnumerationUtils IteratorUtils have private ctors unlike other *Utils classes
Just looking through a some classes and I noticed that EnumerationUtils and IteratorUtils supply a private constructor while the remainder (apart from ./functors/FunctorUtils.java) supply a explicit public constructor. ./BagUtils.java ./BufferUtils.java ./ClosureUtils.java ./CollectionUtils.java ./ComparatorUtils.java ./EnumerationUtils.java -- private public ctor ./FactoryUtils.java ./IteratorUtils.java -- private public ctor ./ListUtils.java ./MapUtils.java ./PredicateUtils.java ./PriorityQueueUtils.java ./SetUtils.java ./TransformerUtils.java ./functors/FunctorUtils.java -- default public ctor For consistency EnumerationUtils and IteratorUtils should change. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net build.xml project.xml
dfs 2004/01/05 08:17:27
Modified:net build.xml project.xml
Log:
Changed dependency from oro 2.0.7 to 2.0.8 since the newer version contains bug
fixes.
Revision ChangesPath
1.19 +1 -1 jakarta-commons/net/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/net/build.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- build.xml 29 Dec 2003 20:25:12 - 1.18
+++ build.xml 5 Jan 2004 16:17:27 - 1.19
@@ -139,7 +139,7 @@
/javadoc
/target
target name=get-deps unless=noget depends=init
-get dest=${libdir}/oro-2.0.7.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/oro/jars/oro-2.0.7.jar;
+get dest=${libdir}/oro-2.0.8.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/oro/jars/oro-2.0.8.jar;
/get
get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar;
/get
1.37 +1 -1 jakarta-commons/net/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/net/project.xml,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- project.xml 1 Jan 2004 17:33:03 - 1.36
+++ project.xml 5 Jan 2004 16:17:27 - 1.37
@@ -119,7 +119,7 @@
dependencies
dependency
idoro/id
-version2.0.7/version
+version2.0.8/version
/dependency
/dependencies
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25905] New: - PropertyUtils.copyProperties: use different names in method signature
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=25905. 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=25905 PropertyUtils.copyProperties: use different names in method signature Summary: PropertyUtils.copyProperties: use different names in method signature Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] right now, it is (Object arg0, Object arg1) if it were (Object toBean, Object fromBean) there is a lot less confusion even if one doesn't have the source attached to the jar in the IDE eclipse or the javadoc open - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor project.xml
rwaldhoff2004/01/05 08:45:46 Modified:functor project.xml Log: ensure resource files are availble in the classpath Revision ChangesPath 1.6 +6 -0 jakarta-commons-sandbox/functor/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/functor/project.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- project.xml 12 Nov 2003 00:14:23 - 1.5 +++ project.xml 5 Jan 2004 16:45:46 - 1.6 @@ -92,6 +92,12 @@ includes includeorg/apache/commons/functor/TestAll.java/include /includes + resources +resource + directorysrc/test/directory + include**/*.txt/include +/resource + /resources /unitTest /build /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25906] New: - [collections] [PATCH] fixes typos in 18 classes in o-a-c-c package
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=25906. 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=25906 [collections] [PATCH] fixes typos in 18 classes in o-a-c-c package Summary: [collections] [PATCH] fixes typos in 18 classes in o-a- c-c package Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached patch fixes some typos in 18 classes in the in o-a-c-c package in the version of collections from 04-Jan-5. 'hashcode' was replaced with 'hash code' to match the JDK docs and usage elsewhere in collections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25906] - [collections] [PATCH] fixes typos in 18 classes in o-a-c-c package
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=25906. 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=25906 [collections] [PATCH] fixes typos in 18 classes in o-a-c-c package --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 17:08 --- Created an attachment (id=9816) patch file to fix typos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] checked in parser factory implementation
In message [EMAIL PROTECTED], steve cohen writes: Problem is, the current implementations of FTPFileEntryParser, also, for reasons of backward compatibility, implement FTPFileListParser. I don't remember exactly why I did that but there was a reason. But the problem is that deprecating FTPFileListParser will deprecate every parser currently in the package. I don't have a comment on this one yet as I have to look at the code in more detail. I'm in favor of deprecating the old stuff, but figuring out the right way to do it isn't immediately obvious. (Actually, scratch that, now that I've finished writing this email, I have comments at the end). parser and specification of parser either by classname or key (UNIX, VMS, etc.) will go a long way to making this easier to deal with. The key is to now use the new FTPClient.getFileList() methods in place of FTPClient.listFiles(). They can use the autodetect feature and never get near the question of which parser interface to use. Even if specifying by key, all these internals are handled for them. It really should be lots better. If anything needs deprecation at this point, I would say it might be FTPClient.listFiles(). I disagree slightly (it's actually agreement, but with a naming difference) and have some suggested code changes (I can make them if there's agreement). First, the getFileList methods should be named listFiles() as that's what they're replacing. We can deprecate the old listFile methods that take FTPFileListParser arguments and reimplement listFiles() and listFiles(String pathname) in terms of the new stuff using autodection (removing getFileList(String parserKey) since the signatures conflict and the common case will be to use autodetection anyway). Second, we shouldn't create an FTPFileListParserFactory on every call to getFileList. Instead, FTPClient should maintain a reference to an FTPFileEntryParserFactory. This reference should be configurable by the user with a setter method. That allows API users to change the factory implementation. Third, we shouldn't set the default factory based on a property. Once we add the setter method, there is no need for the property. In general, it's better to let applications handle their configuration through properties and leave the library free of dependencies on property values. Which factory to use is an application-level decision (e.g., an ant task can define a property that changes the factory for its purposes), not a library-level decision. Jeffrey Brekke writes: list parsers, and/or implementing the existing list parsers with an implementation that uses the entry parsers. That way we are parsing with one implementation? That should be probably be our first step toward deprecation so the parsers behave consistently. In the 1.2 release we can deprecate the old listFiles methods presuming we agree to keep the method name for the files (the class method names currently mirror as closely as possible the FTP commands they implement). We're stuck by the Commons versioning/release rules regarding when we can remove the old stuff. It has to stay in all of the 1.x releases. Otherwise, I'd say that in 1.2 we announce that in 1.3 FTPFileListParserImpl will no longer implement FTPFileListParser and deprecate the interface in 1.2, removing it in 1.4 along with the old listFiles() methods. We'll just have to wait until 2.0. I just tested it, and if we deprecate FTPFileListParser now, it only affects the javadocs for FTPFileListParser. I think we can live with any compiler warnings saying that you're using a deprecated interface as long as we document this. With a J2SE 1.4 compile, you only get warnings for the listFiles methods, DefaultFTPFileLister (which we also need to deprecate), and FTPFileListParserImpl, but none of the FTPFileListParserImpl subclasses. So I propose deprecation in 1.2 and removal in 2.0. I'd also like to tweak the build files before a 1.2 release because, given our limited free time, it's excessive to trigger unit tests every time you build the javadocs since the unit tests don't test anything in the javadocs. It's just that the unit tests take much so long on my development box (I'm still using sub-1GHz processors), I need a way to bypass them when it's not necessary to run them. It's a tradeoff between productivity and comprehensiveness. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] 1.2 release (Re: [net] checked in parser factory implementation)
I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Uuid
I can understand this POV, but I favour FTPUNIXXMLThing. In our example here, UUIDFactory just seems better than UuidFactory to me. +1 And it matches the Sun recommendations, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] checked in parser factory implementation
On Monday 05 January 2004 11:17 am, Daniel F. Savarese wrote: I disagree slightly (it's actually agreement, but with a naming difference) and have some suggested code changes (I can make them if there's agreement). First, the getFileList methods should be named listFiles() as that's what they're replacing. We can deprecate the old listFile methods that take FTPFileListParser arguments and reimplement listFiles() and listFiles(String pathname) in terms of the new stuff using autodection (removing getFileList(String parserKey) since the signatures conflict and the common case will be to use autodetection anyway). Second, we shouldn't create an FTPFileListParserFactory on every call to getFileList. Instead, FTPClient should maintain a reference to an FTPFileEntryParserFactory. This reference should be configurable by the user with a setter method. That allows API users to change the factory implementation. Third, we shouldn't set the default factory based on a property. Once we add the setter method, there is no need for the property. In general, it's better to let applications handle their configuration through properties and leave the library free of dependencies on property values. Which factory to use is an application-level decision (e.g., an ant task can define a property that changes the factory for its purposes), not a library-level decision. I have no disagreement with any of this. In fact the getFileList(String parserKey) bothered me as much as it bothered you. However, since I continue to have free time, I'd just as soon fix this stuff myself. Just to verify that I have understood all your points: 1) deprecate listFiles() methods that take a FileEntryParser parameter. 2) reimplement listFiles() to do what getFileList(null) now does. 3) reimplement listFiles(String pathname) to do what getFileList(null, pathname) now does. 4) rename getFileList(String parserKey, String pathname) to listFiles(String parserKey, String pathname). Even though autodetection will be the primary use case, it already will not work for every system (see EnterpriseUnix) and there must be some way around it. This is that way. 5) don't use properties to select the parser factory in our library. Instead, add a property and a setter method. Initialize in the library to use the default. Have I missed anything? One problem remains. getFileList() throws a new exception: ParserInitializationException. If we simply rename these methods to listFiles() we will break lots of code. That was my primary reason for giving them a different name. One way around this would be to make ParserInitializationException a RuntimeException. That makes sense, as the error is not recoverable and is always due to a programming error - passing in a key that the system cannot parse, specifying a class that has not been made available. Would you agree? (Parenthetical note: this distinction has always seemed a little confusing to me and I think I finally understand why: the name. It should not have been named RuntimeException. All exceptions occur at runtime, both checked, recoverable exceptions and those caused by programming errors. Joshua Bloch, in Effective Java lays this out clearly enough. If it was called PreconditionViolationException or some such, it would be much clearer. As it is, I've seen too many instance of exceptions being made RuntimeExceptions simply because the programmer thought that propagating it up though the call stack was too difficult. But I don't think that's the case here. This is legitimately a RuntimeException). Jeffrey Brekke writes: list parsers, and/or implementing the existing list parsers with an implementation that uses the entry parsers. That way we are parsing with one implementation? That should be probably be our first step toward deprecation so the parsers behave consistently. In the 1.2 release we can deprecate the old listFiles methods presuming we agree to keep the method name for the files (the class method names currently mirror as closely as possible the FTP commands they implement). We're stuck by the Commons versioning/release rules regarding when we can remove the old stuff. It has to stay in all of the 1.x releases. Otherwise, I'd say that in 1.2 we announce that in 1.3 FTPFileListParserImpl will no longer implement FTPFileListParser and deprecate the interface in 1.2, removing it in 1.4 along with the old listFiles() methods. We'll just have to wait until 2.0. I just tested it, and if we deprecate FTPFileListParser now, it only affects the javadocs for FTPFileListParser. I think we can live with any compiler warnings saying that you're using a deprecated interface as long as we document this. With a J2SE 1.4 compile, you only get warnings for the listFiles methods, DefaultFTPFileLister (which we also need to deprecate), and FTPFileListParserImpl, but none of the FTPFileListParserImpl subclasses.
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util CollectionTransformer.java
rwaldhoff2004/01/05 10:11:36
Modified:functor/src/java/org/apache/commons/functor/generator
BaseTransformer.java Transformer.java
Generator.java BaseGenerator.java
functor/src/test/org/apache/commons/functor/generator
TestBaseTransformer.java
functor/src/java/org/apache/commons/functor/generator/util
CollectionTransformer.java
Log:
deprecate Transformer, to be replaced by UnaryFunction
Revision ChangesPath
1.2 +4 -3
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/BaseTransformer.java
Index: BaseTransformer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/BaseTransformer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BaseTransformer.java 25 Nov 2003 19:55:02 - 1.1
+++ BaseTransformer.java 5 Jan 2004 18:11:36 - 1.2
@@ -3,7 +3,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -61,6 +61,7 @@
* @since 1.0
* @version $Revision$ $Date$
* @author Rodney Waldhoff
+ * @deprecated To be removed.
*/
public abstract class BaseTransformer implements Transformer {
public abstract Object transform(Generator gen);
1.3 +4 -3
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Transformer.java
Index: Transformer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Transformer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Transformer.java 25 Nov 2003 19:55:02 - 1.2
+++ Transformer.java 5 Jan 2004 18:11:36 - 1.3
@@ -3,7 +3,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -66,6 +66,7 @@
* @since 1.0
* @version $Revision$ $Date$
* @author Jason Horman ([EMAIL PROTECTED])
+ * @deprecated Simply use UnaryFunction.
*/
public interface Transformer extends UnaryFunction {
1.9 +5 -5
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Generator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Generator.java2 Dec 2003 01:01:59 - 1.8
+++ Generator.java5 Jan 2004 18:11:36 - 1.9
@@ -3,7 +3,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -96,11 +96,11 @@
/** See [EMAIL PROTECTED] org.apache.commons.functor.Algorithms#until}. */
public abstract Generator until(UnaryPredicate pred);
/**
- * [EMAIL PROTECTED] Transformer Transforms} this generator using the passed in
+ * Transforms this generator using the passed in
* transformer. An example transformer might turn the contents of the
* generator into a [EMAIL PROTECTED] Collection} of elements.
*/
-public abstract Object to(Transformer transformer);
+public abstract Object to(UnaryFunction transformer);
/** Same as to(new CollectionTransformer(collection)). */
public abstract Collection to(Collection collection);
/** Same as to(new CollectionTransformer()). */
1.6 +5 -5
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/BaseGenerator.java
Index: BaseGenerator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/BaseGenerator.java,v
retrieving revision 1.5
Re: [net] Let's get rid of org.apache.commons.net.ftp.ftp2
In message [EMAIL PROTECTED], steve cohen writes: On the fresh checkout I did, there was an ftp2 directory but it was empty. Is that another reason to get away from CVS - that it's too hard to get rid of directories? Yep. CVS doesn't treat directories the same as files. I have -P flags next to update and checkout in my .cvsrc which prevents empty directories from being checked out. The only problem with doing that is that sometimes empty directories are meant to be checked out and don't signify an old removed directory. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Uuid
In the case of factories, I think what really matters is that the Widget names match exactly between WidgetFactory and Widget, in this case, UUID and UUIDFactory or Uuid and UuidFactory. I guess we can agree to disagree since a compromise does not seem possible :-( Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 05:05 To: [EMAIL PROTECTED] Subject: Re: [uid] Uuid I can understand this POV, but I favour FTPUNIXXMLThing. In our example here, UUIDFactory just seems better than UuidFactory to me. Stephen from:__matthewHawthorne [EMAIL PROTECTED] Gary Gregory wrote: I prefer treating acronyms as words (Uuid), which avoids IMO silly and *unreadable* names like FTPUNIXXMLThing in favor or FtpUnixXmlThing. Gary I agree. Once you have a class with more than 1 acronym in the name, things get out of hand. I feel that this is a nice consistent approach to producing readable names. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Uuid
Hello, Sun's naming recommendation [1] are not consistent IMO. I would also think that we [lang], [id], etc should be able to expand on them just as we are expanding and complementing the JRE. Sun does suggest using caps with examples like URL and HTML, but does not always follow their own conventions [2], even in 1.4 [3]. Sun's Javamail even has oddball class names like text_html and text_xml. For class names, Sun says to use mixed case name and ACRONYMS and for statics, use uppercase with underscores (MAX_WIDTH). Does this mean that we should have class names like XML_DOM_ReaderThing? I doubt it! ;-) Gary [1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 [2] Html11Writer, HtmlDocWriter, HtmlStandardWriter, HtmlWriter (com.sun.tools.doclets) [3] java.util.prefs.XmlSupport -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 09:36 To: Jakarta Commons Developers List Subject: RE: [uid] Uuid I can understand this POV, but I favour FTPUNIXXMLThing. In our example here, UUIDFactory just seems better than UuidFactory to me. +1 And it matches the Sun recommendations, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Uuid
Gary Gregory wrote: Sun's naming recommendation [1] are not consistent IMO. Sure they are. But their application of them has not been, although over time they have changed to follow them more closely, and have deprecated methods that don't. The Code Conventions for the Java Programming Language document was revised and updated on April 20, 1999. If I recall correctly, the PDF I mentioned recently goes into more detail. Sun's Javamail even has oddball class names like text_html and text_xml. And with good reason, if you look at JAF. Part of a pattern for matching up with MIME. For class names, Sun says to use mixed case name and ACRONYMS and for statics, use uppercase with underscores (MAX_WIDTH). Does this mean that we should have class names like XML_DOM_ReaderThing? No, it would be XMLDOMReaderThing, since a class is not a static member. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25905] - PropertyUtils.copyProperties: use different names in method signature
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=25905. 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=25905 PropertyUtils.copyProperties: use different names in method signature [EMAIL PROTECTED] changed: What|Removed |Added URL||http://cvs.apache.org/viewcv ||s.cgi/jakarta- ||commons/beanutils/src/java/o ||rg/apache/commons/beanutils/ ||PropertyUtils.java?rev=1.41 ||view=markup Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 20:03 --- apologies, saw it in the source that it is Object dest, Object orig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
There's still one problem with deprecating FTPFileListParser. The one method of this interface (parseFileList()) is used in the VMSFTPEntryParser. There is an implementation here that is distinct from the default one in FTPFileListParserImpl. This is for a very good reason. The idea of a File Entry parser (as opposed to a File List parser) was to parse each entry separately. This was a good idea and allowed for cleaner logic to be used. It made the business of not creating FTPFile objects until needed possible. The only problem here was in the VMS case where versioning is turned on. In that case the question of whether or not to keep an entry depends on the existence of other entries with the same name and different version numbers. In that case you do want a whole-list parsing mechanism. If we still want to deprecate FTPFileListParser, I would recommend, then, that we move parseFileList() into the FTPFileEntryParser interface. However, I wanted to throw this question out there for general comment before I do that. On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - 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: [uid] Uuid
For class names, Sun says to use mixed case name and ACRONYMS and for statics, use uppercase with underscores (MAX_WIDTH). Does this mean that we should have class names like XML_DOM_ReaderThing? No, it would be XMLDOMReaderThing, since a class is not a static member. --- Noel Which is what I not too seriously claim is inconsistent. I was trying to give a silly example where in one case, having all caps is a reading problem and underscores have to be used to split word boundaries, e.g. MAXWIDTH vs. MAX_WIDTH, and in the other case, for class names, nothing is mentioned XMLDOMReaderThing or c.net's VMSFTPEntryParser vs. an imaginary nasty VMS_FTPEntryParser (or VM_SFTPEntryParser? ;-) Gary
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale LocaleBeanificationTestCase.java LocaleConvertTestSuite.java
rdonkin 2004/01/05 12:56:16
Modified:beanutils/src/java/org/apache/commons/beanutils/locale
LocaleBeanUtilsBean.java
LocaleConvertUtilsBean.java
beanutils/src/test/org/apache/commons/beanutils/locale
LocaleConvertTestSuite.java
Added: beanutils/src/test/org/apache/commons/beanutils/locale
LocaleBeanificationTestCase.java
Log:
Made LocaleBeanUtils a per context-classloader pseudo-singleton (like BeanUtils is).
Thanks to flaviostutz for contributing the bones of the implementation.
Revision ChangesPath
1.4 +117 -55
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsBean.java
Index: LocaleBeanUtilsBean.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsBean.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- LocaleBeanUtilsBean.java 9 Oct 2003 20:41:40 - 1.3
+++ LocaleBeanUtilsBean.java 5 Jan 2004 20:56:16 - 1.4
@@ -63,6 +63,7 @@
import org.apache.commons.beanutils.*;
+import org.apache.commons.beanutils.ContextClassLoaderLocal;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -87,13 +88,30 @@
public class LocaleBeanUtilsBean extends BeanUtilsBean {
-/** Singleton instance used by static methods */
-private static LocaleBeanUtilsBean singleton;
-
-/** Gets singleton instance */
-public static LocaleBeanUtilsBean getLocaleBeanUtilsInstance() {
-return singleton;
-}
+ /**
+ * Contains codeLocaleBeanUtilsBean/code instances indexed by context
classloader.
+ */
+private static final ContextClassLoaderLocal
+localeBeansByClassLoader = new ContextClassLoaderLocal() {
+// Creates the default instance used when the context
classloader is unavailable
+protected Object initialValue() {
+return new LocaleBeanUtilsBean();
+}
+};
+
+ /** Gets singleton instance */
+ public synchronized static LocaleBeanUtilsBean getLocaleBeanUtilsInstance() {
+return (LocaleBeanUtilsBean)localeBeansByClassLoader.get();
+ }
+
+ /**
+ * Sets the instance which provides the functionality for [EMAIL PROTECTED]
LocaleBeanUtils}.
+ * This is a pseudo-singleton - an single instance is provided per (thread)
context classloader.
+ * This mechanism provides isolation for web apps deployed in the same
container.
+ */
+ public synchronized static void setInstance(LocaleBeanUtilsBean newInstance) {
+localeBeansByClassLoader.set(newInstance);
+ }
/** All logging goes through this logger */
private static Log log = LogFactory.getLog(LocaleBeanUtilsBean.class);
@@ -107,7 +125,7 @@
/** Construct instance with standard conversion bean */
public LocaleBeanUtilsBean() {
-this.localeConvertUtils = LocaleConvertUtilsBean.getInstance();
+this.localeConvertUtils = new LocaleConvertUtilsBean();
}
/**
@@ -138,13 +156,13 @@
// - Public Methods
-/** Gets bean used for conversions */
+/** Gets the bean instance used for conversions */
public LocaleConvertUtilsBean getLocaleConvertUtils() {
return localeConvertUtils;
}
/**
- * getter for defaultLocale
+ * Gets the default Locale
*/
public Locale getDefaultLocale() {
@@ -153,7 +171,7 @@
/**
- * setter for defaultLocale
+ * Sets the default Locale
*/
public void setDefaultLocale(Locale locale) {
@@ -161,7 +179,7 @@
}
/**
- * getter for applyLocalized
+ * Is the pattern to be applied localized
* (Indicate whether the pattern is localized or not)
*/
public boolean getApplyLocalized() {
@@ -170,7 +188,7 @@
}
/**
- * setter for applyLocalized
+ * Sets whether the pattern is applied localized
* (Indicate whether the pattern is localized or not)
*/
public void setApplyLocalized(boolean newApplyLocalized) {
@@ -200,11 +218,16 @@
* @exception NoSuchMethodException if an accessor method for this
* propety cannot be found
*/
-public String getIndexedProperty(Object bean, String name, String pattern)
-throws IllegalAccessException, InvocationTargetException,
-NoSuchMethodException {
+public
Re: [betwixt] Status of Betwixt
i've now realized that releasing the alpha was a major mistake: it should have been a 0.1 release. it's reasonable solid as far as it goes. the problem is that the code needs a *lot* of refactoring before the functionality that consider the minimal for a full release can be added. there's also going to be a lot of deprecated code that will need to be removed before it's ready. this means that probably one or two minor 0.x releases would be needed. (a secondary issue is that now i'm not on the pmc i don't feel able to cast binding vote on legally important issues or cut releases so even if the work was done, someone else would need to act as release manager.) i've been working on a major refactoring of betwixt for a long time now but i've also got a number of local versions with extra bits and pieces in. unfortunately, too much of my time has been taken up with jakarta stuff in the last few months and i haven't been able to sort out this mess :( now that i've finished with that, i should have more coding time :) i've made some progress on the refactoring recently but i've neglected a lot of other projects i'm interested in and have a lot of catching up to do. realistically i'm not going to be in a position to put the refactored stuff in cvs for a while yet. (i'm very committed to backwards compatibility and the final details of the design aren't clear in my mind yet though the broad outline is). if there's interest from other committers i could think about tidying the refactored stuff up and putting it into a branch so that we can talk about the design. - robert On 29 Dec 2003, at 14:38, Tim O'Brien wrote: Understood. I'm in the same boat as you. Let me know if you need any release support. In the meantime, if you find yourself overburdened, let's start delegating. I'm surprised that we have enough time to talk about all these philosophical J-C vs. A-C issues, or even debating author tags when something as important as Betwixt sits in an Alpha for so long. Tim On 29 Dec 2003, Martin van den Bemt wrote: Hi Tim, On my part that almost all my resources go to my gui framework xulux on codehaus, my work, my newly acquired family and preparation for my new house. I try to organize a betwixt night so now and then, but that is hardly enough time to get a new release out the door. Robert is probably busy (or on a holiday?) and James has moved on to other projects. So currently betwixt is a bit asleep and wakes up so know and then when I can schedule a betwixt night. Mvgr, Martin On Tue, 2003-12-23 at 19:55, Tim O'Brien wrote: Betwixt is a very useful component, and a number of people would like to start using it in production systems. Could someone give a quick update as to why Betwixt is still at a 1.0 alpha? and, also provide a timeline for a 1.0 release. Tim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections project.xml
scolebourne2004/01/05 13:20:51 Modified:collections project.xml Log: Linkcheck report is slow Revision ChangesPath 1.23 +1 -1 jakarta-commons/collections/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/collections/project.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- project.xml 2 Jan 2004 00:05:56 - 1.22 +++ project.xml 5 Jan 2004 21:20:51 - 1.23 @@ -268,7 +268,7 @@ reportmaven-junit-report-plugin/report reportmaven-jxr-plugin/report reportmaven-license-plugin/report - reportmaven-linkcheck-plugin/report + !--reportmaven-linkcheck-plugin/report-- reportmaven-statcvs-plugin/report reportmaven-tasklist-plugin/report /reports - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections EnumerationUtils.java
scolebourne2004/01/05 13:23:45
Modified:collections/src/java/org/apache/commons/collections
EnumerationUtils.java
Log:
Add missing since tag
Add public constructor
Revision ChangesPath
1.2 +7 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java
Index: EnumerationUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EnumerationUtils.java 28 Oct 2003 18:47:47 - 1.1
+++ EnumerationUtils.java 5 Jan 2004 21:23:44 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 1999-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -65,15 +65,17 @@
/**
* Provides utility methods for [EMAIL PROTECTED] Enumeration} instances.
*
- * @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
+ * @since Commons Collections 3.0
* @version $Id$
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
*/
public class EnumerationUtils {
/**
- * Do not instantiate.
+ * EnumerationUtils is not normally instantiated.
*/
-private EnumerationUtils() {
+public EnumerationUtils() {
// no init.
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/functors FunctorUtils.java
scolebourne2004/01/05 13:31:49
Modified:collections/src/java/org/apache/commons/collections/functors
FunctorUtils.java
Log:
Add constructor
Fix javadoc, from Gary Gregory
Revision ChangesPath
1.4 +9 -6
jakarta-commons/collections/src/java/org/apache/commons/collections/functors/FunctorUtils.java
Index: FunctorUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/functors/FunctorUtils.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FunctorUtils.java 23 Nov 2003 23:25:33 - 1.3
+++ FunctorUtils.java 5 Jan 2004 21:31:48 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2001-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -75,6 +75,12 @@
class FunctorUtils {
/**
+ * Restricted constructor.
+ */
+private FunctorUtils() {
+}
+
+/**
* Clone the predicates to ensure that the internal reference can't be messed
with.
*
* @param predicates the predicates to copy
@@ -91,7 +97,6 @@
* Validate the predicates to ensure that all is well.
*
* @param predicates the predicates to validate
- * @return the validated predicates
*/
static void validate(Predicate[] predicates) {
if (predicates == null) {
@@ -108,7 +113,6 @@
* Validate the predicates to ensure that all is well.
*
* @param predicates the predicates to validate
- * @return the validated predicates
*/
static void validateMin2(Predicate[] predicates) {
if (predicates == null) {
@@ -169,7 +173,6 @@
* Validate the closures to ensure that all is well.
*
* @param closures the closures to validate
- * @return the validated closures
*/
static void validate(Closure[] closures) {
if (closures == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map AbstractHashedMap.java
scolebourne2004/01/05 13:32:10
Modified:collections/src/java/org/apache/commons/collections/map
AbstractHashedMap.java
Log:
Fix javadoc, from Gary Gregory
Revision ChangesPath
1.7 +2 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractHashedMap.java
Index: AbstractHashedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractHashedMap.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- AbstractHashedMap.java3 Jan 2004 05:15:00 - 1.6
+++ AbstractHashedMap.java5 Jan 2004 21:32:10 - 1.7
@@ -480,7 +480,6 @@
*
* @param entry the entry to update
* @param newValue the new value to store
- * @return value the previous value
*/
protected void updateEntry(HashEntry entry, Object newValue) {
entry.setValue(newValue);
@@ -518,7 +517,6 @@
* @param hashCode the hash code of the key to add
* @param key the key to add
* @param value the value to add
- * @return the value previously mapped to this key, null if none
*/
protected void addMapping(int hashIndex, int hashCode, Object key, Object
value) {
modCount++;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map LRUMap.java
scolebourne2004/01/05 13:32:47
Modified:collections/src/java/org/apache/commons/collections/map
LRUMap.java
Log:
Fix javadoc, from Gary Gregory
Revision ChangesPath
1.6 +2 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/map/LRUMap.java
Index: LRUMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/LRUMap.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- LRUMap.java 2 Jan 2004 01:36:52 - 1.5
+++ LRUMap.java 5 Jan 2004 21:32:47 - 1.6
@@ -194,7 +194,6 @@
*
* @param entry the entry to update
* @param newValue the new value to store
- * @return value the previous value
*/
protected void updateEntry(HashEntry entry, Object newValue) {
moveToMRU((LinkEntry) entry); // handles modCount
@@ -210,7 +209,6 @@
* @param hashCode the hash code of the key to add
* @param key the key to add
* @param value the value to add
- * @return the value previously mapped to this key, null if none
*/
protected void addMapping(int hashIndex, int hashCode, Object key, Object
value) {
if (size = maxSize removeLRU(header.before)) {
@@ -228,7 +226,6 @@
* @param hashCode the hash code of the key to add
* @param key the key to add
* @param value the value to add
- * @return the value previously mapped to this key, null if none
*/
protected void reuseMapping(LinkEntry entry, int hashIndex, int hashCode,
Object key, Object value) {
// find the entry before the entry specified in the hash table
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer UnboundedFifoBuffer.java
scolebourne2004/01/05 13:33:22
Modified:collections/src/java/org/apache/commons/collections/buffer
UnboundedFifoBuffer.java
Log:
Fix javadoc
Revision ChangesPath
1.5 +2 -3
jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/UnboundedFifoBuffer.java
Index: UnboundedFifoBuffer.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/UnboundedFifoBuffer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- UnboundedFifoBuffer.java 4 Jan 2004 18:56:37 - 1.4
+++ UnboundedFifoBuffer.java 5 Jan 2004 21:33:22 - 1.5
@@ -160,7 +160,6 @@
* @param obj the element to add
* @return true, always
* @throws NullPointerException if the given element is null
- * @throws BufferOverflowException if this buffer is full
*/
public boolean add(final Object obj) {
if (obj == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections MapIterator.java EnumerationUtils.java OrderedIterator.java BeanMap.java
scolebourne2004/01/05 13:37:13
Modified:collections/src/java/org/apache/commons/collections
MapIterator.java EnumerationUtils.java
OrderedIterator.java BeanMap.java
Log:
Fix javadoc, from Gary Gregory
Revision ChangesPath
1.5 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/MapIterator.java
Index: MapIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/MapIterator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- MapIterator.java 2 Dec 2003 23:51:49 - 1.4
+++ MapIterator.java 5 Jan 2004 21:37:13 - 1.5
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -99,7 +99,7 @@
* Gets the next emkey/em from the codeMap/code.
*
* @return the next key in the iteration
- * @throws NoSuchElementException if the iteration is finished
+ * @throws java.util.NoSuchElementException if the iteration is finished
*/
Object next();
1.3 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java
Index: EnumerationUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EnumerationUtils.java 5 Jan 2004 21:23:44 - 1.2
+++ EnumerationUtils.java 5 Jan 2004 21:37:13 - 1.3
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2004 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -86,7 +86,7 @@
* created. The new list is returned./p
*
* @param enumeration the enumeration to traverse, which should not be
codenull/code.
- * @throws codeNullPointerException/code if the enumeration parameter is
codenull/code.
+ * @throws NullPointerException if the enumeration parameter is
codenull/code.
*/
public static List toList(Enumeration enumeration) {
return IteratorUtils.toList(new EnumerationIterator(enumeration));
1.2 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/OrderedIterator.java
Index: OrderedIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/OrderedIterator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- OrderedIterator.java 1 Dec 2003 22:48:59 - 1.1
+++ OrderedIterator.java 5 Jan 2004 21:37:13 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -82,7 +82,7 @@
* Gets the previous element from the collection.
*
* @return the previous key in the iteration
- * @throws NoSuchElementException if the iteration is finished
+ * @throws java.util.NoSuchElementException if the iteration is finished
*/
Object previous();
1.26 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/BeanMap.java
Index: BeanMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BeanMap.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- BeanMap.java 5 Dec 2003 20:23:57 - 1.25
+++ BeanMap.java 5 Jan 2004 21:37:13 - 1.26
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2001-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -519,7 +519,7 @@
}
public Object next() {
Object key = iter.next();
-
Re: [betwixt] Status of Betwixt
robert burrell donkin wrote: if there's interest from other committers i could think about tidying the refactored stuff up and putting it into a branch so that we can talk about the design. I think this may be the best idea. Or, you could create an experimental/refactoring directory in CVS and put the code in there. I've had no time to work on Jakarta stuff lately, but I use Betwixt and am interested in helping to get a release going. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap UnmodifiableOrderedBidiMap.java AbstractDualBidiMap.java DualHashBidiMap.java AbstractOrderedBidiMapDecorator.java AbstractBidiMapDecorator.java UnmodifiableBidiMap.java DualTreeBidiMap.java UnmodifiableSortedBidiMap.java AbstractSortedBidiMapDecorator.java
scolebourne2004/01/05 13:46:49
Modified:collections/src/java/org/apache/commons/collections/bidimap
UnmodifiableOrderedBidiMap.java
AbstractDualBidiMap.java DualHashBidiMap.java
AbstractOrderedBidiMapDecorator.java
AbstractBidiMapDecorator.java
UnmodifiableBidiMap.java DualTreeBidiMap.java
UnmodifiableSortedBidiMap.java
AbstractSortedBidiMapDecorator.java
Log:
Update file layout for consistency
Revision ChangesPath
1.2 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/UnmodifiableOrderedBidiMap.java
Index: UnmodifiableOrderedBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/UnmodifiableOrderedBidiMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UnmodifiableOrderedBidiMap.java 3 Dec 2003 14:03:35 - 1.1
+++ UnmodifiableOrderedBidiMap.java 5 Jan 2004 21:46:49 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,8 +79,8 @@
*
* @author Stephen Colebourne
*/
-public final class UnmodifiableOrderedBidiMap extends
AbstractOrderedBidiMapDecorator
-implements Unmodifiable {
+public final class UnmodifiableOrderedBidiMap
+extends AbstractOrderedBidiMapDecorator implements Unmodifiable {
/** The inverse unmodifiable map */
private UnmodifiableOrderedBidiMap inverse;
1.8 +5 -3
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/AbstractDualBidiMap.java
Index: AbstractDualBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/AbstractDualBidiMap.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- AbstractDualBidiMap.java 29 Dec 2003 01:28:20 - 1.7
+++ AbstractDualBidiMap.java 5 Jan 2004 21:46:49 - 1.8
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -75,6 +75,8 @@
* An implementation can be written simply by implementing the
* codecreateMap/code method.
*
+ * @see DualHashBidiMap
+ * @see DualTreeBidiMap
* @since Commons Collections 3.0
* @version $Id$
*
1.3 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/DualHashBidiMap.java
Index: DualHashBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/DualHashBidiMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DualHashBidiMap.java 1 Dec 2003 22:34:54 - 1.2
+++ DualHashBidiMap.java 5 Jan 2004 21:46:49 - 1.3
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -75,7 +75,8 @@
* @author Matthew Hawthorne
* @author Stephen Colebourne
*/
-public class DualHashBidiMap extends AbstractDualBidiMap implements Serializable {
+public class DualHashBidiMap
+extends AbstractDualBidiMap implements Serializable {
/** Ensure serialization compatability */
private static final long serialVersionUID = 721969328361808L;
1.2 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/AbstractOrderedBidiMapDecorator.java
Index: AbstractOrderedBidiMapDecorator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/AbstractOrderedBidiMapDecorator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractOrderedBidiMapDecorator.java 3 Dec 2003 14:03:35 - 1.1
+++ AbstractOrderedBidiMapDecorator.java 5 Jan 2004
Re: [VOTE] Promote io from commons-sandbox to commons-proper
On 04.01.2004 03:05:58 Henri Yandell wrote: --- Vote: Promote commons-io to commons proper [ X ] +1 I am in favor of the move, and will help support it [ ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [ ] -1 I am against this proposal (must include a reason). --- Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/bag TreeBag.java TransformedBag.java UnmodifiableSortedBag.java SynchronizedSortedBag.java PredicatedBag.java TypedBag.java TypedSortedBag.java SynchronizedBag.java AbstractSortedBagDecorator.java PredicatedSortedBag.java UnmodifiableBag.java TransformedSortedBag.java HashBag.java AbstractBagDecorator.java
scolebourne2004/01/05 13:54:07
Modified:collections/src/java/org/apache/commons/collections/bag
TreeBag.java TransformedBag.java
UnmodifiableSortedBag.java
SynchronizedSortedBag.java PredicatedBag.java
TypedBag.java TypedSortedBag.java
SynchronizedBag.java
AbstractSortedBagDecorator.java
PredicatedSortedBag.java UnmodifiableBag.java
TransformedSortedBag.java HashBag.java
AbstractBagDecorator.java
Log:
Update file layout for consistency
Revision ChangesPath
1.6 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/bag/TreeBag.java
Index: TreeBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bag/TreeBag.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TreeBag.java 28 Dec 2003 17:58:53 - 1.5
+++ TreeBag.java 5 Jan 2004 21:54:06 - 1.6
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2002-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -87,7 +87,8 @@
* @author Chuck Burdick
* @author Stephen Colebourne
*/
-public class TreeBag extends AbstractMapBag implements SortedBag, Serializable {
+public class TreeBag
+extends AbstractMapBag implements SortedBag, Serializable {
/** Serial version lock */
static final long serialVersionUID = -7740146511091606676L;
1.2 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/bag/TransformedBag.java
Index: TransformedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bag/TransformedBag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TransformedBag.java 16 Nov 2003 00:05:43 - 1.1
+++ TransformedBag.java 5 Jan 2004 21:54:06 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -77,7 +77,8 @@
*
* @author Stephen Colebourne
*/
-public class TransformedBag extends TransformedCollection implements Bag {
+public class TransformedBag
+extends TransformedCollection implements Bag {
/**
* Factory method to create a transforming bag.
1.4 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/bag/UnmodifiableSortedBag.java
Index: UnmodifiableSortedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bag/UnmodifiableSortedBag.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- UnmodifiableSortedBag.java3 Dec 2003 12:27:37 - 1.3
+++ UnmodifiableSortedBag.java5 Jan 2004 21:54:06 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -72,7 +72,8 @@
*
* @author Stephen Colebourne
*/
-public final class UnmodifiableSortedBag extends AbstractSortedBagDecorator
implements Unmodifiable {
+public final class UnmodifiableSortedBag
+extends AbstractSortedBagDecorator implements Unmodifiable {
/**
* Factory method to create an unmodifiable bag.
1.3 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/bag/SynchronizedSortedBag.java
Index: SynchronizedSortedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bag/SynchronizedSortedBag.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SynchronizedSortedBag.java28 Dec 2003 14:55:46 - 1.2
+++ SynchronizedSortedBag.java5 Jan 2004 21:54:06 - 1.3
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale LocaleConvertTestSuite.java LocaleConvertUtilsTestCase.java
rdonkin 2004/01/05 13:55:53 Modified:beanutils LICENSE.txt beanutils/src/java/org/apache/commons/beanutils/locale LocaleBeanUtilsBean.java LocaleConvertUtilsBean.java beanutils/src/test/org/apache/commons/beanutils/locale LocaleConvertTestSuite.java LocaleConvertUtilsTestCase.java Log: Doh! Forgot to update the copyrights. Revision ChangesPath 1.7 +4 -4 jakarta-commons/beanutils/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons/beanutils/LICENSE.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- LICENSE.txt 9 Oct 2003 20:43:52 - 1.6 +++ LICENSE.txt 5 Jan 2004 21:55:52 - 1.7 @@ -7,7 +7,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.5 +4 -4 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsBean.java Index: LocaleBeanUtilsBean.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsBean.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocaleBeanUtilsBean.java 5 Jan 2004 20:56:16 - 1.4 +++ LocaleBeanUtilsBean.java 5 Jan 2004 21:55:52 - 1.5 @@ -7,7 +7,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.5 +4 -4 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleConvertUtilsBean.java Index: LocaleConvertUtilsBean.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleConvertUtilsBean.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocaleConvertUtilsBean.java 5 Jan 2004 20:56:16 - 1.4 +++ LocaleConvertUtilsBean.java 5 Jan 2004 21:55:52 - 1.5 @@ -7,7 +7,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.5 +5 -5 jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale/LocaleConvertTestSuite.java Index: LocaleConvertTestSuite.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale/LocaleConvertTestSuite.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocaleConvertTestSuite.java 5 Jan 2004 20:56:16 - 1.4 +++ LocaleConvertTestSuite.java 5 Jan 2004 21:55:52 - 1.5 @@ -7,7 +7,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.5 +5 -5 jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale/LocaleConvertUtilsTestCase.java Index: LocaleConvertUtilsTestCase.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/locale/LocaleConvertUtilsTestCase.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocaleConvertUtilsTestCase.java 9 Oct 2003 20:39:04 - 1.4 +++ LocaleConvertUtilsTestCase.java 5 Jan 2004 21:55:52 - 1.5 @@ -7,7 +7,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [VOTE] Promote io from commons-sandbox to commons-proper
On 4 Jan 2004, at 02:05, Henri Yandell wrote: --- Vote: Promote commons-io to commons proper [ X ] +1 I am in favor of the move, and will help support it [ ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [ ] -1 I am against this proposal (must include a reason). --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map LazySortedMap.java CompositeMap.java FixedSizeSortedMap.java HashedMap.java LazyMap.java FixedSizeMap.java AbstractHashedMap.java ListOrderedMap.java LinkedMap.java IdentityMap.java AbstractLinkedMap.java LRUMap.java Flat3Map.java
scolebourne2004/01/05 14:04:20
Modified:collections/src/java/org/apache/commons/collections/map
LazySortedMap.java CompositeMap.java
FixedSizeSortedMap.java HashedMap.java LazyMap.java
FixedSizeMap.java AbstractHashedMap.java
ListOrderedMap.java LinkedMap.java IdentityMap.java
AbstractLinkedMap.java LRUMap.java Flat3Map.java
Log:
Update file layout for consistency
Revision ChangesPath
1.2 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/map/LazySortedMap.java
Index: LazySortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/LazySortedMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LazySortedMap.java16 Nov 2003 00:05:45 - 1.1
+++ LazySortedMap.java5 Jan 2004 22:04:19 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -91,7 +91,8 @@
* @author Stephen Colebourne
* @author Paul Jack
*/
-public class LazySortedMap extends LazyMap implements SortedMap {
+public class LazySortedMap
+extends LazyMap implements SortedMap {
/**
* Factory method to create a lazily instantiated sorted map.
1.4 +11 -11
jakarta-commons/collections/src/java/org/apache/commons/collections/map/CompositeMap.java
Index: CompositeMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/CompositeMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CompositeMap.java 29 Dec 2003 15:26:39 - 1.3
+++ CompositeMap.java 5 Jan 2004 22:04:19 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,20 +79,20 @@
* @author Brian McCallister
*/
public class CompositeMap implements Map {
-
+
/** Array of all maps in the composite */
private Map[] composite;
-
+
/** Handle mutation operations */
private MapMutator mutator;
-
+
/**
* Create a new, empty, CompositeMap.
*/
public CompositeMap() {
this(new Map[]{}, null);
}
-
+
/**
* Create a new CompositeMap with two composited Map instances.
*
@@ -103,7 +103,7 @@
public CompositeMap(Map one, Map two) {
this(new Map[]{one, two}, null);
}
-
+
/**
* Create a new CompositeMap with two composited Map instances.
*
@@ -114,7 +114,7 @@
public CompositeMap(Map one, Map two, MapMutator mutator) {
this(new Map[]{one, two}, mutator);
}
-
+
/**
* Create a new CompositeMap which composites all of the Map instances in the
* argument. It copies the argument array, it does not use it directly.
@@ -125,7 +125,7 @@
public CompositeMap(Map[] composite) {
this(composite, null);
}
-
+
/**
* Create a new CompositeMap which composites all of the Map instances in the
* argument. It copies the argument array, it does not use it directly.
@@ -140,7 +140,7 @@
this.addComposited(composite[i]);
}
}
-
+
//---
/**
* Specify the MapMutator to be used by mutation operations.
1.3 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/map/FixedSizeSortedMap.java
Index: FixedSizeSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/FixedSizeSortedMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FixedSizeSortedMap.java 11 Dec 2003 22:55:25 - 1.2
+++ FixedSizeSortedMap.java 5 Jan 2004 22:04:19 - 1.3
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software
[VFS] [PATCH] SftpFileObject.java
Need to accommodate other presentations of '.' and '..' (such as './' and '../'). Ran into this when we tried to find children from an ssh server that presented things as ../ and ./ . Index: SftpFileObject.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/ vfs/provider/sftp/SftpFileObject.java,v retrieving revision 1.5 diff -r1.5 SftpFileObject.java 236c236 if ( name.equals( . ) || name.equals( .. ) ) --- if ( name.matches(\\./?) || name.matches( \\.\\./? ) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] Status of Betwixt
Robert, please, at the very least, put the code up somewhere for inspection. BTW, Your work has been invaluable, and J-C, in your absence, has suffered. Tim On Mon, 5 Jan 2004, robert burrell donkin wrote: i've now realized that releasing the alpha was a major mistake: it should have been a 0.1 release. it's reasonable solid as far as it goes. the problem is that the code needs a *lot* of refactoring before the functionality that consider the minimal for a full release can be added. there's also going to be a lot of deprecated code that will need to be removed before it's ready. this means that probably one or two minor 0.x releases would be needed. (a secondary issue is that now i'm not on the pmc i don't feel able to cast binding vote on legally important issues or cut releases so even if the work was done, someone else would need to act as release manager.) i've been working on a major refactoring of betwixt for a long time now but i've also got a number of local versions with extra bits and pieces in. unfortunately, too much of my time has been taken up with jakarta stuff in the last few months and i haven't been able to sort out this mess :( now that i've finished with that, i should have more coding time :) i've made some progress on the refactoring recently but i've neglected a lot of other projects i'm interested in and have a lot of catching up to do. realistically i'm not going to be in a position to put the refactored stuff in cvs for a while yet. (i'm very committed to backwards compatibility and the final details of the design aren't clear in my mind yet though the broad outline is). if there's interest from other committers i could think about tidying the refactored stuff up and putting it into a branch so that we can talk about the design. - robert On 29 Dec 2003, at 14:38, Tim O'Brien wrote: Understood. I'm in the same boat as you. Let me know if you need any release support. In the meantime, if you find yourself overburdened, let's start delegating. I'm surprised that we have enough time to talk about all these philosophical J-C vs. A-C issues, or even debating author tags when something as important as Betwixt sits in an Alpha for so long. Tim On 29 Dec 2003, Martin van den Bemt wrote: Hi Tim, On my part that almost all my resources go to my gui framework xulux on codehaus, my work, my newly acquired family and preparation for my new house. I try to organize a betwixt night so now and then, but that is hardly enough time to get a new release out the door. Robert is probably busy (or on a holiday?) and James has moved on to other projects. So currently betwixt is a bit asleep and wakes up so know and then when I can schedule a betwixt night. Mvgr, Martin On Tue, 2003-12-23 at 19:55, Tim O'Brien wrote: Betwixt is a very useful component, and a number of people would like to start using it in production systems. Could someone give a quick update as to why Betwixt is still at a 1.0 alpha? and, also provide a timeline for a 1.0 release. Tim - 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] - 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]
cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser DefaultFTPFileEntryParserFactory.java ParserInitializationException.java
scohen 2004/01/05 14:11:12
Modified:net/src/java/org/apache/commons/net/ftp
DefaultFTPFileListParser.java FTPClient.java
net/src/java/org/apache/commons/net/ftp/parser
DefaultFTPFileEntryParserFactory.java
ParserInitializationException.java
Log:
Cleanup of File parsing interface:
Deprecate class DefaultFTPFileListParser
Remove __defaultFileListParser from FTPClient
Deprecate FTPClient.listFiles() methods that take a FTPFileListParser param
For those FTPClient.listFiles() methods that do not take a FTPFileListParser
param, reimplement as per previous FTPClient.getFileList() methods
Remove FTPClient.getFileList methods
Change ParserInitializationException to inherit from RuntimeException
Add FTPFileEntryParserFactory member to FTPClient and initialize this
member to a new DefaultFTPFileEntryParserFactory. Add a set() method
for this member. Remove logic that attempts to initialize this member
based on a system property.
Revision ChangesPath
1.8 +4 -3
jakarta-commons/net/src/java/org/apache/commons/net/ftp/DefaultFTPFileListParser.java
Index: DefaultFTPFileListParser.java
===
RCS file:
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/DefaultFTPFileListParser.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DefaultFTPFileListParser.java 2 Jan 2004 03:39:04 - 1.7
+++ DefaultFTPFileListParser.java 5 Jan 2004 22:11:12 - 1.8
@@ -61,7 +61,7 @@
import java.util.Calendar;
import java.util.Vector;
-/***
+/**
* DefaultFTPFileListParser is the default implementation of
* a href=org.apache.commons.net.ftp.FTPFileListParser.html FTPFileListParser
/a
* used by a href=org.apache.commons.net.ftp.FTPClient.html FTPClient /a
@@ -75,8 +75,9 @@
* @see FTPFileListParser
* @see FTPFile
* @see FTPClient#listFiles
- ***/
-
+ * @see org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory
+ * @deprecated use autodetect mechanism in DefaultFTPFileEntryParserFactory instead
+ */
public final class DefaultFTPFileListParser implements FTPFileListParser
{
1.21 +219 -242
jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java
Index: FTPClient.java
===
RCS file:
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- FTPClient.java3 Jan 2004 22:15:23 - 1.20
+++ FTPClient.java5 Jan 2004 22:11:12 - 1.21
@@ -69,6 +69,7 @@
import org.apache.commons.net.io.ToNetASCIIOutputStream;
import org.apache.commons.net.io.Util;
import org.apache.commons.net.MalformedServerReplyException;
+import org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory;
import org.apache.commons.net.ftp.parser.FTPFileEntryParserFactory;
import org.apache.commons.net.ftp.parser.ParserInitializationException;
@@ -205,7 +206,9 @@
* @author Daniel F. Savarese
* @see FTP
* @see FTPConnectionClosedException
- * @see DefaultFTPFileListParser
+ * @see FTPFileEntryParser
+ * @see FTPFileEntryParserFactory
+ * @see DefaultFTPFileEntryParserFactory
* @see org.apache.commons.net.MalformedServerReplyException
***/
@@ -247,8 +250,8 @@
private String __passiveHost;
private int __fileType, __fileFormat, __fileStructure, __fileTransferMode;
private boolean __remoteVerificationEnabled;
-private FTPFileListParser __fileListParser;
private long __restartOffset;
+private FTPFileEntryParserFactory parserFactory;
/***
* Default FTPClient constructor. Creates a new FTPClient instance
@@ -262,9 +265,9 @@
public FTPClient()
{
__initDefaults();
-__fileListParser = new DefaultFTPFileListParser();
__dataTimeout = -1;
__remoteVerificationEnabled = true;
+parserFactory = new DefaultFTPFileEntryParserFactory();
}
@@ -524,6 +527,19 @@
__dataTimeout = timeout;
}
+/**
+ * set the factory used for parser creation to the supplied factory object.
+ *
+ * @param parserFactory
+ * factory object used to create FTPFileEntryParsers
+ *
+ * @see org.apache.commons.net.ftp.parser.FTPFileEntryParserFactory
+ * @see org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory
+ */
+public void setParserFactory(FTPFileEntryParserFactory parserFactory) {
+this.parserFactory = parserFactory;
+}
+
/***
* Closes the connection to the FTP server and
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map TypedSortedMap.java TransformedMap.java AbstractOrderedMapDecorator.java TransformedSortedMap.java AbstractMapDecorator.java TypedMap.java AbstractSortedMapDecorator.java StaticBucketMap.java UnmodifiableEntrySet.java ReferenceMap.java UnmodifiableMap.java UnmodifiableOrderedMap.java PredicatedSortedMap.java PredicatedMap.java UnmodifiableSortedMap.java
scolebourne2004/01/05 14:15:15
Modified:collections/src/java/org/apache/commons/collections/map
TypedSortedMap.java TransformedMap.java
AbstractOrderedMapDecorator.java
TransformedSortedMap.java AbstractMapDecorator.java
TypedMap.java AbstractSortedMapDecorator.java
StaticBucketMap.java UnmodifiableEntrySet.java
ReferenceMap.java UnmodifiableMap.java
UnmodifiableOrderedMap.java
PredicatedSortedMap.java PredicatedMap.java
UnmodifiableSortedMap.java
Log:
Update file layout for consistency
Revision ChangesPath
1.2 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/map/TypedSortedMap.java
Index: TypedSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/TypedSortedMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TypedSortedMap.java 16 Nov 2003 00:05:45 - 1.1
+++ TypedSortedMap.java 5 Jan 2004 22:15:14 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -96,7 +96,7 @@
PredicateUtils.instanceofPredicate(valueType)
);
}
-
+
/**
* Restrictive constructor.
*/
1.4 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/map/TransformedMap.java
Index: TransformedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/TransformedMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TransformedMap.java 25 Dec 2003 00:49:14 - 1.3
+++ TransformedMap.java 5 Jan 2004 22:15:14 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -102,7 +102,7 @@
public static Map decorate(Map map, Transformer keyTransformer, Transformer
valueTransformer) {
return new TransformedMap(map, keyTransformer, valueTransformer);
}
-
+
//---
/**
* Constructor that wraps (not copies).
1.4 +6 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractOrderedMapDecorator.java
Index: AbstractOrderedMapDecorator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractOrderedMapDecorator.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractOrderedMapDecorator.java 1 Dec 2003 22:48:59 - 1.3
+++ AbstractOrderedMapDecorator.java 5 Jan 2004 22:15:14 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -78,8 +78,9 @@
*
* @author Stephen Colebourne
*/
-public abstract class AbstractOrderedMapDecorator extends AbstractMapDecorator
implements OrderedMap {
-
+public abstract class AbstractOrderedMapDecorator
+extends AbstractMapDecorator implements OrderedMap {
+
/**
* Constructor that wraps (not copies).
*
1.2 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/map/TransformedSortedMap.java
Index: TransformedSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/TransformedSortedMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TransformedSortedMap.java 16 Nov 2003 00:05:45 - 1.1
+++ TransformedSortedMap.java 5 Jan 2004 22:15:14 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2003 The Apache
Re: [betwixt] Status of Betwixt
robert burrell donkin wrote: if there's interest from other committers i could think about tidying the refactored stuff up and putting it into a branch so that we can talk about the design. I think this may be the best idea. Or, you could create an experimental/refactoring directory in CVS and put the code in there. You could consider a new sandbox project. Then you don't worry about compatability. (Its what I'd do...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections IteratorUtils.java
scolebourne2004/01/05 14:19:51
Modified:collections/src/java/org/apache/commons/collections
IteratorUtils.java
Log:
Add public constructor
Revision ChangesPath
1.19 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/IteratorUtils.java
Index: IteratorUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/IteratorUtils.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- IteratorUtils.java1 Dec 2003 22:48:59 - 1.18
+++ IteratorUtils.java5 Jan 2004 22:19:51 - 1.19
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2002-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -126,9 +126,9 @@
public static final OrderedMapIterator EMPTY_ORDERED_MAP_ITERATOR = new
EmptyOrderedMapIterator();
/**
- * Prevents instantiation.
+ * IteratorUtils is not normally instantiated.
*/
-private IteratorUtils() {
+public IteratorUtils() {
}
// Empty
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections OrderedBidiMap.java SortedBidiMap.java BoundedCollection.java KeyValue.java BidiMap.java IterableMap.java Unmodifiable.java BoundedMap.java Buffer.java
scolebourne2004/01/05 14:27:08
Modified:collections/src/java/org/apache/commons/collections
OrderedBidiMap.java SortedBidiMap.java
BoundedCollection.java KeyValue.java BidiMap.java
IterableMap.java Unmodifiable.java BoundedMap.java
Buffer.java
Log:
Update file layout for consistency
Revision ChangesPath
1.2 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/OrderedBidiMap.java
Index: OrderedBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/OrderedBidiMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- OrderedBidiMap.java 1 Dec 2003 22:34:55 - 1.1
+++ OrderedBidiMap.java 5 Jan 2004 22:27:08 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -70,7 +70,7 @@
* @author Stephen Colebourne
*/
public interface OrderedBidiMap extends BidiMap, OrderedMap {
-
+
/**
* Gets a view of this map where the keys and values are reversed.
* p
1.4 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/SortedBidiMap.java
Index: SortedBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/SortedBidiMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SortedBidiMap.java1 Dec 2003 22:34:55 - 1.3
+++ SortedBidiMap.java5 Jan 2004 22:27:08 - 1.4
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -72,7 +72,7 @@
* @author Stephen Colebourne
*/
public interface SortedBidiMap extends OrderedBidiMap, SortedMap {
-
+
/**
* Gets a view of this map where the keys and values are reversed.
* p
1.8 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedCollection.java
Index: BoundedCollection.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedCollection.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- BoundedCollection.java11 Dec 2003 22:48:09 - 1.7
+++ BoundedCollection.java5 Jan 2004 22:27:08 - 1.8
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2002-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -80,12 +80,12 @@
* @return codetrue/code if the collection is full
*/
boolean isFull();
-
+
/**
* Gets the maximum size of the collection (the bound).
*
* @return the maximum number of elements the collection can hold
*/
int maxSize();
-
+
}
1.2 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/KeyValue.java
Index: KeyValue.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/KeyValue.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- KeyValue.java 5 Dec 2003 20:23:57 - 1.1
+++ KeyValue.java 5 Jan 2004 22:27:08 - 1.2
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2003-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -70,7 +70,7 @@
* @author Stephen Colebourne
*/
public interface KeyValue {
-
+
/**
* Gets the key from the pair.
*
1.11 +4 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/BidiMap.java
Index: BidiMap.java
Re: [collections] What is left to do for 3.0?
Done - Original Message - From: Gary Gregory [EMAIL PROTECTED] To: Gary Gregory [EMAIL PROTECTED]; 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, January 05, 2004 1:57 AM Subject: RE: [collections] What is left to do for 3.0? Forgot to attach. Gary -Original Message- From: Gary Gregory Sent: Sunday, January 04, 2004 17:57 To: 'Jakarta Commons Developers List' Subject: RE: [collections] What is left to do for 3.0? Please find attached some Javadoc patches ( 1 code patch). I can commit those if you want but I do not want to step on any toes/changes so close to a release, there are more fixes like the attached to do but that's all the time I have right now. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, January 04, 2004 11:50 To: Jakarta Commons Developers List Subject: [collections] What is left to do for 3.0? The [collections] CVS has been tidied up prior to a 3.0 release today. The CVS now only contains those classes to be released in a 3.0. These are all I know of: - Should PriorityQueue be deprecated? (Buffer effectively replaces it) - Add CaseInsensitiveMap? Do we just RC1 and then release, or do we need a public Beta? (I favour the former) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] What is left to do for 3.0?
From: Phil Steitz [EMAIL PROTECTED] It's in. Have a look. I will add to / improve the tests if we decide to keep it in (though, once again, I am amazed at how good the stock framework tests are :-) Looks fine to me :-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] EnumerationUtils IteratorUtils have private ctorsunlike other *Utils classes
Done,thanks Stephen - Original Message - From: Janek Bogucki [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:16 PM Subject: [collections] EnumerationUtils IteratorUtils have private ctorsunlike other *Utils classes Just looking through a some classes and I noticed that EnumerationUtils and IteratorUtils supply a private constructor while the remainder (apart from ./functors/FunctorUtils.java) supply a explicit public constructor. ./BagUtils.java ./BufferUtils.java ./ClosureUtils.java ./CollectionUtils.java ./ComparatorUtils.java ./EnumerationUtils.java -- private public ctor ./FactoryUtils.java ./IteratorUtils.java -- private public ctor ./ListUtils.java ./MapUtils.java ./PredicateUtils.java ./PriorityQueueUtils.java ./SetUtils.java ./TransformerUtils.java ./functors/FunctorUtils.java -- default public ctor For consistency EnumerationUtils and IteratorUtils should change. -Janek - 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]
cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp FTPFileEntryParser.java
scohen 2004/01/05 14:29:21 Modified:net/src/java/org/apache/commons/net/ftp FTPFileEntryParser.java Log: Change documentation to reflect previous FTPClient changes Revision ChangesPath 1.9 +13 -11 jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPFileEntryParser.java Index: FTPFileEntryParser.java === RCS file: /home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPFileEntryParser.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- FTPFileEntryParser.java 3 Jan 2004 17:55:22 - 1.8 +++ FTPFileEntryParser.java 5 Jan 2004 22:29:21 - 1.9 @@ -89,19 +89,20 @@ *} * /pre * - * The second example uses the newer codeFTPClient.getFileList()/code - * API to pull the whole list from the codesubfolder/codein one call, - * attempting to automatically detect the parser type. The null parameter - * indicates that autodection should be used. + * The second example uses the revised codeFTPClient.listFiles()/code + * API to pull the whole list from the subfolder codesubfolder/code in + * one call, attempting to automatically detect the parser type. This + * method, without a parserKey parameter, indicates that autodection should + * be used. * * pre *FTPClient f=FTPClient(); *f.connect(server); *f.login(username, password); - *FTPFile[] files = f.getFileList(null, subfolder); + *FTPFile[] files = f.listFiles(subfolder); * /pre * - * The third example uses the newer codeFTPClient.getFileList()/code + * The third example uses the revised codeFTPClient.listFiles()/code * API to pull the whole list from the current working directory in one call, * but specifying by classname the parser to be used. For this particular * parser class, this approach is necessary since there is no way to @@ -111,11 +112,12 @@ *FTPClient f=FTPClient(); *f.connect(server); *f.login(username, password); - *FTPFile[] files = f.getFileList( - * org.apache.commons.net.ftp.parser.EnterpriseUnixFTPFileEntryParser); + *FTPFile[] files = f.listFiles( + * org.apache.commons.net.ftp.parser.EnterpriseUnixFTPFileEntryParser, + * .); * /pre * - * The fourth example uses the newer codeFTPClient.getFileList()/code + * The fourth example uses the revised codeFTPClient.listFiles()/code * API to pull a single file listing in an arbitrary directory in one call, * specifying by KEY the parser to be used, in this case, VMS. * @@ -123,7 +125,7 @@ *FTPClient f=FTPClient(); *f.connect(server); *f.login(username, password); - *FTPFile[] files = f.getFileList(VMS, subfolder/foo.java); + *FTPFile[] files = f.listFiles(VMS, subfolder/foo.java); * /pre * * @author a href=mailto:[EMAIL PROTECTED]Steve Cohen/a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Except for the issue outlined below (re FTPFileListParser deprecation) my latest commit have implemented everything that Daniel discussed earlier today: Cleanup of File parsing interface: Deprecate class DefaultFTPFileListParser Remove __defaultFileListParser from FTPClient Deprecate FTPClient.listFiles() methods that take a FTPFileListParser param For those FTPClient.listFiles() methods that do not take a FTPFileListParser param, reimplement as per previous FTPClient.getFileList() methods Remove FTPClient.getFileList methods Change ParserInitializationException to inherit from RuntimeException Add FTPFileEntryParserFactory member to FTPClient and initialize this member to a new DefaultFTPFileEntryParserFactory. Add a set() method for this member. Remove logic that attempts to initialize this member based on a system property. Once we have agreement on what to do about FTPFileListParser, I can make those changes as well Steve On Monday 05 January 2004 02:27 pm, steve cohen wrote: There's still one problem with deprecating FTPFileListParser. The one method of this interface (parseFileList()) is used in the VMSFTPEntryParser. There is an implementation here that is distinct from the default one in FTPFileListParserImpl. This is for a very good reason. The idea of a File Entry parser (as opposed to a File List parser) was to parse each entry separately. This was a good idea and allowed for cleaner logic to be used. It made the business of not creating FTPFile objects until needed possible. The only problem here was in the VMS case where versioning is turned on. In that case the question of whether or not to keep an entry depends on the existence of other entries with the same name and different version numbers. In that case you do want a whole-list parsing mechanism. If we still want to deprecate FTPFileListParser, I would recommend, then, that we move parseFileList() into the FTPFileEntryParser interface. However, I wanted to throw this question out there for general comment before I do that. On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] What is left to do for 3.0?
Would it be possible to add a class that extends ListOrderedMap and provides the default map constructors, e.g. XxxListOrderedMap() XxxListOrderedMap(Map map) // copies, not wraps where Xxx is Default or Simple or somesuch. Alternatively, change ListOrderedMap to ListOrderedMapDecorator and call the new class ListOrderedMap. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote io from commons-sandbox to commons-proper
+0 -- = 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: [net] checked in parser factory implementation
On Mon, 05 Jan 2004 12:07:28 -0600, steve cohen [EMAIL PROTECTED] said: [SNIPPED] 4) rename getFileList(String parserKey, String pathname) to listFiles(String parserKey, String pathname). Even though autodetection will be the primary use case, it already will not work for every system (see EnterpriseUnix) and there must be some way around it. This is that way. [SNIPPED] I don't believe this method needs to be public. It seems that the listFiles(FTPFileEntryParser parser, String pathname) is sufficient. A fully-qualified classname is required for the EnterpriseUnix use case anyway, right? And if you want to use autodetection, just use the listFiles(String pathname) version. -- = 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: [collections] What is left to do for 3.0?
Very minor typo fixes: $ cvs diff -u xdocs/*.xml Index: xdocs/index.xml === RCS file: /home/cvspublic/jakarta-commons/collections/xdocs/index.xml,v retrieving revision 1.7 diff -u -r1.7 index.xml --- xdocs/index.xml 6 Jan 2004 00:44:20 - 1.7 +++ xdocs/index.xml 6 Jan 2004 04:14:44 - @@ -15,7 +15,7 @@ The a href=http://java.sun.com/products/j2se/1.4/docs/guide/collections/;Java Collections Framework/a was a major addition in JDK 1.2. It added many powerful data structures that accelerate development of most significant Java applications. -Since that time it has become the regognised standard for collection handling in the Java language. +Since that time it has become the recognised standard for collection handling in the Java language. /p p Commons-Collections seek to build upon the JDK classes by providing new interfaces, implementations and utilities. Index: xdocs/userguide.xml === RCS file: /home/cvspublic/jakarta-commons/collections/xdocs/userguide.xml,v retrieving revision 1.1 diff -u -r1.1 userguide.xml --- xdocs/userguide.xml 6 Jan 2004 00:44:20 - 1.1 +++ xdocs/userguide.xml 6 Jan 2004 04:14:44 - @@ -21,7 +21,7 @@ section name=Utils classes p -A Utility class is provided for each major collection interface. +An Utility class is provided for each major collection interface. Thus, the codeSet/code and codeSortedSet/code interfaces are provided for by codeSetUtils/code. These classes provide useful methods for working with that collection type. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net build.xml
brekke 2004/01/05 20:26:12
Modified:net build.xml
Log:
Newly generated build.xml which removes the jar dep on the javadoc target.
Revision ChangesPath
1.20 +3 -3 jakarta-commons/net/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/net/build.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- build.xml 5 Jan 2004 16:17:27 - 1.19
+++ build.xml 6 Jan 2004 04:26:12 - 1.20
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 1.2.0-dev
- on date December 29 2003, time 1419--
+ on date January 5 2004, time 2208--
project default=jar name=commons-net basedir=.
property name=defaulttargetdir value=target
@@ -116,7 +116,7 @@
/classpath
/javac
/target
- target name=javadoc description=o Generate javadoc depends=jar
+ target name=javadoc description=o Generate javadoc
mkdir dir=${javadocdir}
/mkdir
tstamp
@@ -154,4 +154,4 @@
unjar dest=${maven.home} src=${user.home}/maven-install-latest.jar
/unjar
/target
-/project
+/project
\ No newline at end of file
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] checked in parser factory implementation
On Mon, 05 Jan 2004 12:17:28 -0500, Daniel F. Savarese [EMAIL PROTECTED] said: [SNIPPED] I'd also like to tweak the build files before a 1.2 release because, given our limited free time, it's excessive to trigger unit tests every time you build the javadocs since the unit tests don't test anything in the javadocs. It's just that the unit tests take much so long on my development box (I'm still using sub-1GHz processors), I need a way to bypass them when it's not necessary to run them. It's a tradeoff between productivity and comprehensiveness. [SNIPPED] I've submitted a patch to the maven-ant plugin to resolve this. In the meantime I've committed a newly regenerated build.xml with the changes. Maven does not execute the tests on a javadoc goal. -- = 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: [net] checked in parser factory implementation
On Mon, 05 Jan 2004 21:34:01 -0600, [EMAIL PROTECTED] (Jeffrey D. Brekke) said: On Mon, 05 Jan 2004 12:07:28 -0600, steve cohen [EMAIL PROTECTED] said: [SNIPPED] 4) rename getFileList(String parserKey, String pathname) to listFiles(String parserKey, String pathname). Even though autodetection will be the primary use case, it already will not work for every system (see EnterpriseUnix) and there must be some way around it. This is that way. [SNIPPED] I don't believe this method needs to be public. It seems that the listFiles(FTPFileEntryParser parser, String pathname) is sufficient. A fully-qualified classname is required for the EnterpriseUnix use case anyway, right? And if you want to use autodetection, just use the listFiles(String pathname) version. I meant to say that createFiles(String pathname, FTPFileEntryParser parser) is sufficient for this case. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [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: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Couldn't we handle this with a FilterIterator or some other adapter on the iterator from an FTPFileList? I never thought of this when the version patch was submitted, but it seems like a possible solution. Better than supporting multiple ways of parsing the list. Of course it wouldn't help for the methods that return an array, but the user could sort that out also, converting the array to a list and using the FilterIterator. On Mon, 05 Jan 2004 14:27:22 -0600, steve cohen [EMAIL PROTECTED] said: There's still one problem with deprecating FTPFileListParser. The one method of this interface (parseFileList()) is used in the VMSFTPEntryParser. There is an implementation here that is distinct from the default one in FTPFileListParserImpl. This is for a very good reason. The idea of a File Entry parser (as opposed to a File List parser) was to parse each entry separately. This was a good idea and allowed for cleaner logic to be used. It made the business of not creating FTPFile objects until needed possible. The only problem here was in the VMS case where versioning is turned on. In that case the question of whether or not to keep an entry depends on the existence of other entries with the same name and different version numbers. In that case you do want a whole-list parsing mechanism. If we still want to deprecate FTPFileListParser, I would recommend, then, that we move parseFileList() into the FTPFileEntryParser interface. However, I wanted to throw this question out there for general comment before I do that. On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote: I forgot to add that I think we need a beta release for 1.2 to give us a chance to back out or fix anything that we discover is suboptimal before we set the stuff in stone in the API. Mostly I'm thinking of method signatures. Anyway, to recap the proposed deprecation list: interfaces: FTPFileListParser classes: DefaultFTPFileListParser methods: FTPClient.listFiles(FTPFileListParser, String) FTPClient.listFiles(FTPFileListParser) Did I miss anything? daniel - 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]
cvs commit: jakarta-commons/validator project.xml
rleland 2004/01/05 21:09:01 Modified:validator project.xml Log: Remove references to nagoya and use issues and mail-archive instead. Revision ChangesPath 1.30 +3 -3 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- project.xml 15 Dec 2003 09:24:11 - 1.29 +++ project.xml 6 Jan 2004 05:09:01 - 1.30 @@ -24,7 +24,7 @@ urlhttp://jakarta.apache.org/commons/validator//url gumpRepositoryIdjakarta/gumpRepositoryId - issueTrackingUrlhttp://nagoya.apache.org/bugzilla//issueTrackingUrl + issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl siteAddressjakarta.apache.org/siteAddress repository @@ -40,13 +40,13 @@ nameCommons Dev List/name subscribe[EMAIL PROTECTED]/subscribe unsubscribe[EMAIL PROTECTED]/unsubscribe - archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive + archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]/archive /mailingList mailingList nameCommons User List/name subscribe[EMAIL PROTECTED]/subscribe unsubscribe[EMAIL PROTECTED]/unsubscribe - archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive + archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]/archive /mailingList /mailingLists - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : authentication ...
hi :) maybe preemptive authentication is what you're looking for - i haven't tried it personnaly, but here's what the doc says : --- from http://jakarta.apache.org/commons/httpclient/authentication.html --- Preemptive authentication can be enabled within HttpClient. In this mode HttpClient will send the basic authentication response even before the server gives an unauthorized response in certain situations, thus reducing the overhead of making the connection. To enable this use the following: client.getState().setAuthenticationPreemptive(true); To enable preemptive authentication by default for all newly created HttpState 's, a system property can be set, as shown below. setSystemProperty(Authenticator.PREEMPTIVE_PROPERTY, true); --- --- have a nice day Isabelle -Original Message- From: Sid Subr [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 8:04 PM To: Commons HttpClient Project Subject: Re: authentication ... on the same note of authentication.. I know this question sounds dumb (when I read back the contents) but is there a way to send the authentication digest/credentials with the first request so that the request does not get challenged? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - 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]
SSL problem on HPUX
I have written a simple Java application to call a URL using Jakarta HttpClient. The code works like a champ on my windows 2K development workstation when accessing a URL the is protected by Siteminder (which redirects to SSL for Authentication). The big difference is that when I try to run the same code on a HPUX box I get the following message... javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: CA certificate does not include basic constraints extension I read some posts about Trusted CAs. I used 'keytool' to create a keystore and import the Root Certificate for the Trusted Authority and I start my JVM like this... keystore filename is cacerts keystore password is password java -Djavax.net.ssl.trustStore=/full/path/to/cacerts - Djavax.net.ssl.trustStorePassword=password ClassName ARGS Any help is greatly appreciated. Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload large files- Filepart
Siddhartha,
I believe the solution to this problem is trivial. All it takes is
checking for availability of a response from the target server prior to
sending each consecutive chunk of request body. A premature response
from the target server detected before the request body has been
transmitted in its entirety most likely signifies a problem (such as
authentication failure), which should cause the request to be aborted
and the connection force-closed once the response is read.
I'll happily provide a fix for this problem, but currently there are
more pressing issues that must be addressed first. Besides, it is
already too late to incorporate the fix into 2.0 release, so it will
have to wait until next release (2.1). You are welcome to work on a
patch, if you feel like to, or you can wait until the problem makes it
to the top of our priority list (which may take a while) to be fixed in
its due time
Cheers
Oleg
On Sat, 2004-01-03 at 21:34, Sid Subr wrote:
from looking at the filepart code seems that this part
would be creating a problem which makes the code not
recoverable from the server closing the connection
when authentication fails...
Filepart.java for httpclient
sendData(){
create a new byte array of size 4K
while thereis stuff to be read from the file send it
out to the outputstream
finally close the stream
}
I know the while loop is the one that chokes when the
connection is closed as the httpclient has not yet
finished writing the whole file (the release
connection is also not called which might help in teh
retry)and the IOException from that write is sent all
the way up and since it is not an
HttpRecoverableException the whole thing does not even
go to the point of trying to send it out the next time
with credentials.. how do you propose to change this?
The only way I see is to send part of the file to the
server and when the challenge comes and the connection
is closed start sending the file in parts and hope it
will not get challenged.. otherwise we might be stuck
in the sending (a max of three times specified in the
MethodRetryHandler) ..
any input would be helpful..
Sid
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
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: SSL problem on HPUX
David, You may want to take a different approach and provide a custom SSL trust manager (which in its crudest and ugliest form may be programmed to simply trust all target servers) Take a look at the 'Customizing SSL in HttpClient' section of the HttpClient SSL guide at the following location http://jakarta.apache.org/commons/httpclient/sslguide.html Hope this helps Oleg On Mon, 2004-01-05 at 22:47, David Webb wrote: I have written a simple Java application to call a URL using Jakarta HttpClient. The code works like a champ on my windows 2K development workstation when accessing a URL the is protected by Siteminder (which redirects to SSL for Authentication). The big difference is that when I try to run the same code on a HPUX box I get the following message... javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: CA certificate does not include basic constraints extension I read some posts about Trusted CAs. I used 'keytool' to create a keystore and import the Root Certificate for the Trusted Authority and I start my JVM like this... keystore filename is cacerts keystore password is password java -Djavax.net.ssl.trustStore=/full/path/to/cacerts - Djavax.net.ssl.trustStorePassword=password ClassName ARGS Any help is greatly appreciated. Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile - 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: SSL problem on HPUX
Oleg, I appreciate the input. I will create my own SSLProtocolSocketFactory like you suggested. Can you shed any light on the different behavior in Windows vs HPUX? Not that it will change anything, but I like to learn why these things behave the way they do to prevent future time wasting activities. Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile Quoting Oleg Kalnichevski [EMAIL PROTECTED]: David, You may want to take a different approach and provide a custom SSL trust manager (which in its crudest and ugliest form may be programmed to simply trust all target servers) Take a look at the 'Customizing SSL in HttpClient' section of the HttpClient SSL guide at the following location http://jakarta.apache.org/commons/httpclient/sslguide.html Hope this helps Oleg On Mon, 2004-01-05 at 22:47, David Webb wrote: I have written a simple Java application to call a URL using Jakarta HttpClient. The code works like a champ on my windows 2K development workstation when accessing a URL the is protected by Siteminder (which redirects to SSL for Authentication). The big difference is that when I try to run the same code on a HPUX box I get the following message... javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: CA certificate does not include basic constraints extension I read some posts about Trusted CAs. I used 'keytool' to create a keystore and import the Root Certificate for the Trusted Authority and I start my JVM like this... keystore filename is cacerts keystore password is password java -Djavax.net.ssl.trustStore=/full/path/to/cacerts - Djavax.net.ssl.trustStorePassword=password ClassName ARGS Any help is greatly appreciated. Thanks. -- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateParser pluggability
Hi Charles,
You will need to login at some point. I haven't looked at the site
closely, but it seems to use form authentication. There is an example
using HttpClient for form authentication at
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/
examples/FormLoginDemo.java?
rev=1.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=auto.
Enjoy,
Mike
On Jan 3, 2004, at 12:03 PM, protean wrote:
You will need to authenticate first, which will most likely set a
cookie.
Yes, i gave that a try, but i'm possibly doing something wrong (or not
doing
something). I only got a session cookie using that url:
Initial set of cookies:
- session.ID=ID32f64093ff0d1c
Perhaps you can check it? This is the code I'm using (possibly
something
missing as i was not sure of the sequence):
public static void main(String[] args) throws Exception {
HttpClient client = new HttpClient();
client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT,
http);
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
client.getState().setCredentials(null, null, new
UsernamePasswordCredentials(xxx, yyy));
GetMethod authget = new GetMethod(args[0]);
client.executeMethod(authget);
System.out.println(Login form get: +
authget.getStatusLine().toString());
Cookie[] initcookies = client.getState().getCookies(LOGON_SITE,
LOGON_PORT, /, false);
System.out.println(Initial set of cookies:);
if (initcookies != null) {
if (initcookies.length == 0) {
System.out.println(None);
} else {
for (int i = 0; i initcookies.length; i++) {
System.out.println(- + initcookies[i].toString());
}
}
}
System.out.println(authget.getResponseBodyAsString());
authget.releaseConnection();
}
Constants are:
final static String LOGON_SITE = www.racingpost.co.uk;
final static int LOGON_PORT = 80;
Thanks in advance.
Charles Johnson
On Saturday 03 January 2004 16:32 pm, you wrote:
Hi Charles,
It seems that this page is protected. You will need to authenticate
first, which will most likely set a cookie. Once that is done you
should be able to perform a get using the URL you've given.
Mike
On Jan 3, 2004, at 9:57 AM, Charles Johnson wrote:
Thanks Michael - that looks encouraging and I shall try it.
First though, I'm a little concerned that the software may not be
able
to do
what I want, as I've tried several approaches using the one-man code
fork
previously described, without any success. What I want to do is to be
able
to get onto this page:
http://www.racingpost.co.uk/horses/?
MIval=v2_a_days_racingday=04month=Jan
year=2004flag=3
which is (subject to parameter changes) a link in the menu called
'Future
racing' at that page. Do you think this IS possible, and if so, how
should
it be done?
Charles Johnson
- Original Message -
From: Michael Becke [EMAIL PROTECTED]
To: Commons HttpClient Project
[EMAIL PROTECTED]
Sent: Friday, January 02, 2004 10:07 PM
Subject: Re: DateParser pluggability
Hello,
Date parser formats can be configured in the post 2.0 HttpClient
code.
This code, in CVS HEAD, is still pre-alpha but everything should
still
be working. You can add a format using something like the
following:
HttpParams params = DefaultHttpParams.getDefaultParams();
HashSet patterns = new HashSet((Collection)
params.getParameter(DateParser.KEY_DATE_PATTERNS));
patterns.add(SOME_PATTERN);
params.setParameter(DateParser.KEY_DATE_PATTERNS,
patterns);
Mike
On Dec 31, 2003, at 10:57 AM, protean wrote:
I have had to supply an extra format String as follows:
/** The patterns used for parsing dates */
private static final String[] DATE_PATTERNS = {
PATTERN_RFC1123,
PATTERN_RFC1036,
PATTERN_ASCTIME,
EEE, dd-MMM- HH:mm:ss z,
EEE, dd-MMM- HH-mm-ss z,
EEE, dd MMM yy HH:mm:ss z,
EEE dd-MMM- HH:mm:ss z,
EEE dd MMM HH:mm:ss z,
EEE dd-MMM- HH-mm-ss z,
EEE dd-MMM-yy HH:mm:ss z,
EEE dd MMM yy HH:mm:ss z,
EEE,dd-MMM-yy HH:mm:ss z,
EEE,dd-MMM- HH:mm:ss z,
EEE, dd-MM- HH:mm:ss z,
// Extra for non-compliant site
dd-MMM- HH:mm:ss zzz
};
to the DateParser class and produce my own build, as the DateParser
does not
seem to provide pluggability for non-compliant sites. Can anyone
tell
me when
this situation may change so I no longer have to produce a one-man
code fork?
C Johnson
---
--
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
