Re: [lang] FastDateFormat Month bug?
The ISO8601 value you are defining is the a Duration format, not the
DateTime format. So a better name would be good.
From ISO8601:
- Time-interval: a portion of time between two time-points. These
time-points are respectively labelled start
and end. Time intervals may be specified by these two time-points, by one
of these time-points and the
temporal distance between the points or by the temporal distance between
these points only.
- Recurring time-interval: a series of consecutive time-intervals of the
same duration. Recurring time-intervals
may be specified by specification of one time-interval and the number of
recurrences.
- Duration: a quantity (length) of time. Duration is a physical unit
expressed in the units of time of the
International System of Units (SI), as defined in ISO 31-1.
Your format is a Duration as it has no start or end time. Note that this
means it should go in DurationFormatUtils, not DateFormatUtils.
Stephen
- Original Message -
From: Gary Gregory [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 6:39 AM
Subject: [lang] FastDateFormat Month bug?
Hello all,
I am working on an ISO 8601 extended date time format and I think I might
have run into a bug but I would like someone else's eye to check this since
I am not familiar with this implementation (which by the way I find *very*
nice with the use of 'Rules', etc). I was going to commit this but I would
prefer some to check my sanity.
I have test cases and all that
Index: FastDateFormat.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/FastDat
eFormat.java,v
retrieving revision 1.8
diff -u -r1.8 FastDateFormat.java
--- FastDateFormat.java 14 Jul 2003 22:25:05 - 1.8
+++ FastDateFormat.java 16 Jul 2003 05:33:50 -
@@ -998,7 +998,7 @@
}
public void appendTo(StringBuffer buffer, Calendar calendar) {
-appendTo(buffer, calendar.get(Calendar.MONTH) + 1);
+appendTo(buffer, calendar.get(Calendar.MONTH));
}
public final void appendTo(StringBuffer buffer, int value) {
FYI,
This is the doo-dad I am working on:
/**
* pISO8601 formatter for the date time extended format./p
*
* pThis format represents the Gregorian year, month, day, hour,
minute, and second components defined
* in § 5.5.3.2 of ISO 8601, respectively. These components are ordered
in their significance by their order
* of appearance i.e. as year, month, day, hour, minute, and second./p
*
* pThe ISO8601 extended format PnYnMnDTnHnMnS, where nY represents
the number of years, nM the number of months,
* nD the number of days, 'T' is the date/time separator, nH the number
of hours, nM the number of minutes and
* nS the number of seconds. The number of seconds can include decimal
digits to arbitrary precision..p
*
* The format used is tt'P''Y'M'M'd'DT'H'H'm'M's'S'/tt.
*
* TODO: How does create a pattern to support iThe number of seconds
can include decimal digits to arbitrary precision./i
* when we want to format and parse (which is not supported yet).
*
* @see a
href=http://www.w3.org/TR/xmlschema-2/#duration;http://www.w3.org/TR/xmlsc
hema-2/#duration/a
*/
public static final FastDateFormat ISO_DATETIME_EXTENDED_FORMAT
= FastDateFormat.getInstance('P''Y'M'M'd'DT'H'H'm'M's'S');
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] NPEs in StringUtils
Yes, I mean adding
if (str == null) {
return null; // or whatevers appropriate...
}
to a number of methods in StringUtils.
Currently this is +1, if still so tonight, I will make the changes.
Stephen
- Original Message -
From: Steven Caswell [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 1:56 AM
Subject: RE: [lang] NPEs in StringUtils
Just want to be sure I understand. By quiet, I understand you to mean
nulls are handled in some well-defined way other than throwing an exception.
If that is what you meant, then I am +1. Otherwise I'll wait to hear a
clarification :)
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 7:31 PM
To: Jakarta Commons Developers List
Subject: [lang] NPEs in StringUtils
All this debate has reminded me that we have not sorted the
position on null handling in StringUtils.
Most of [lang] is quiet with respect to nulls wherever
possible. I would like to extend that to StringUtils. Are
there any objections to making this change? I feel a
consistent position would be good.
Now is the time to do this of course (pre 2.0). (Its amazing
what you find when you want to do a release...)
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: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
From: Gary Gregory [EMAIL PROTECTED]
I am not fond of isEmptyTrimmed, -1.
The semantics of trim() are very specific, and different to other
StringUtils methods (it removes all chars = 32). Hence the method name must
include the word trim.
Personally, I do not want to write code all over the place that reads
if (StringUtils.isEmptyTrimmedOrNull(value)) {
When I would be happy with a more *intelligent* isEmpty().
if (StringUtils.isEmpty(value)) {
My preference would also be for more intelligence, however I think we have
to recognise that StringUtils needs to be usable quickly without constant
javadoc reference. And that means explicit method names in certain cases.
The new behaviour will also be consistent with the isAlpha() etc. methods
where null is false.
At the risk my being dense (I can do that), can someone clarify why it is
important to test a trim String vs a /not/ trim'ed String? IOW, when would
it be incorrect for an app to do something when a value is but correct
when it is or \t?
Who knows? Its really just the case that users have different requirements.
We have already had one claim that null is treated differently from in an
application. Same for spaces I guess.
Stephen
Thanks,
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 17:12
To: Jakarta Commons Developers List
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces
OK, time to summarise the debate a little.
I have examined Java's String and StringBuffer classes. These refer to
'empty' as . They make no reference to 'blank'.
As a result I have updated StringUtils using the following terminology:
null - codenull/code
empty - a zero-length string (code/code)
space - the space character (code' '/code)(32)
whitespace - the characters defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}
All references to 'blank' have been removed. (Note that I've only gone
through StringUtils, not other classes).
This now means that the currently coded method isEmpty() is wrong as it
returns true for null. Similarly for isNotEmpty().
Thus I propose:
isEmpty(), true for , false for null
isEmptyOrNull(), true for and null
isEmptyTrimmed(), trim() then true for , false for null
isEmptyTrimmedOrNull(), trim() then true for , true for null
(Other proposed methods can be considered after 2.0. These should be
considered now)
I also propose the negative methods are the exact opposite.
isNotEmpty()
isNotEmptyOrNull()
isNotEmptyTrimmed()
isNotEmptyTrimmedOrNull()
For deprecation issues see another thread.
Can we have a +1 or not for this proposal.
Stephen
- Original Message -
From: Steven Caswell [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 12:04 AM
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces
I agree with Henri that a major benefit of the current isEmpty() is the
silent null handling. I would not be opposed to changing it to not trim,
as
long as there was an equivalent isEmptyTrimmed(), but I'm against
removing
the silent null handling. If I remember correctly, that was the original
intent.
I'm also very leery of a major change to the functionality of existing
methods. For backward compatibility, which I believe is very important,
I
hope we can come up with different names and leave the existing methods
pretty much as is.
And I also agree that Trivial just doesn't float my boat.
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:20 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(),
isNotEmpty() and stri ngsa with somespaces
The only major input I have at the moment is -1 to Trivial.
It's hard to find good words, but trivial just doesn't fit.
The number one piece of code to support is:
if( foo.getParameter() != null !.equals(foo.getParameter()) ) {
into
if( !StringUtils.isEmpty(foo.getParameter()) {
It reads a lot more easily, and is something that you quite
often find yourself doing in crappy ServletRequest-style environments.
Having the trims/not's is just syntactic sugar. I'm not a big
fan of the trim, and like the 'Trimmed' method to show it is there.
I do however like having systems that behave quietly when
possible under null. Throwing an NPE because null is just
utterly illegal is cool, such as a substring() method that's
meant to return an int, but for a boolean I quite like
returning false in the null case.
If an object was meant to be returned, I believe null should
be returned.
ie) replace(null,
cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse AbstractServiceDescriptor.java AbstractConfigurator.java ModuleDescriptor.java InterceptorDescriptor.java ParametersDescriptor.java AbstractConfigurationDescriptor.java
hlship 2003/07/16 07:11:02 Modified:hivemind/src/java/org/apache/commons/hivemind/impl BaseModule.java ElementImpl.java hivemind/src/java/org/apache/commons/hivemind/parse AbstractServiceDescriptor.java AbstractConfigurator.java ModuleDescriptor.java InterceptorDescriptor.java ParametersDescriptor.java AbstractConfigurationDescriptor.java Log: Don't include the location property in objects' toString() output. Revision ChangesPath 1.7 +1 -2 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/BaseModule.java Index: BaseModule.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/BaseModule.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- BaseModule.java 2 Jul 2003 21:41:12 - 1.6 +++ BaseModule.java 16 Jul 2003 14:11:01 - 1.7 @@ -290,7 +290,6 @@ extendDescription(builder); builder.append(resourceResolver, _resolver); -builder.append(location, getLocation()); return builder.toString(); } 1.2 +2 -3 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ElementImpl.java Index: ElementImpl.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ElementImpl.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ElementImpl.java 30 Jun 2003 23:04:29 - 1.1 +++ ElementImpl.java 16 Jul 2003 14:11:01 - 1.2 @@ -155,8 +155,7 @@ builder.append(attributes, _attributes); builder.append(elements, _elements); builder.append(content, _content); -builder.append(location, getLocation()); - + return builder.toString(); } } 1.7 +1 -2 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractServiceDescriptor.java Index: AbstractServiceDescriptor.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractServiceDescriptor.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- AbstractServiceDescriptor.java30 Jun 2003 23:05:03 - 1.6 +++ AbstractServiceDescriptor.java16 Jul 2003 14:11:01 - 1.7 @@ -84,7 +84,6 @@ builder.append(instanceBuilder, _instanceBuilder); builder.append(interceptors, _interceptors); -builder.append(location, getLocation()); return builder.toString(); } 1.8 +2 -3 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractConfigurator.java Index: AbstractConfigurator.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractConfigurator.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- AbstractConfigurator.java 2 Jul 2003 21:41:12 - 1.7 +++ AbstractConfigurator.java 16 Jul 2003 14:11:01 - 1.8 @@ -88,8 +88,7 @@ extendDescription(builder); builder.append(propertyName, _propertyName); - builder.append(location, getLocation()); - + return builder.toString(); } 1.5 +1 -2 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/ModuleDescriptor.java Index: ModuleDescriptor.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/ModuleDescriptor.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ModuleDescriptor.java 4 Jun 2003 23:52:47 - 1.4 +++ ModuleDescriptor.java 16 Jul 2003 14:11:01 - 1.5 @@ -95,7 +95,6 @@ builder.append(serviceContributions, _serviceContributions); builder.append(configurations, _configurations); builder.append(configurationContributions, _configurationContributions); -builder.append(location, getLocation()); return builder.toString(); } 1.6 +1 -2 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/InterceptorDescriptor.java Index: InterceptorDescriptor.java
Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
I don't have a vote, but I'd be quite happy with this set of methods. It's a great improvement over 1.x .T. On 7/15/03 8:12 PM, [EMAIL PROTECTED] wrote: Thus I propose: isEmpty(), true for , false for null isEmptyOrNull(), true for and null isEmptyTrimmed(), trim() then true for , false for null isEmptyTrimmedOrNull(), trim() then true for , true for null (Other proposed methods can be considered after 2.0. These should be considered now) I also propose the negative methods are the exact opposite. isNotEmpty() isNotEmptyOrNull() isNotEmptyTrimmed() isNotEmptyTrimmedOrNull() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/service/impl EJBProxyFactory.java
hlship 2003/07/16 10:22:38
Modified:hivemind/src/java/org/apache/commons/hivemind
HiveMindMessages.properties
ServiceImplementationFactory.java
hivemind/xdocs descriptor.xml services.xml
hivemind/src/java/org/apache/commons/hivemind/parse
FactoryDescriptor.java HiveMind_1.0.xsd
ParametersDescriptor.java
hivemind/src/test/hivemind/test/parse
TestDescriptorParser.java
ContributeFactoryParameters.xml
hivemind/src/test/hivemind/test/services EJBProxy.xml
hivemind/src/java/org/apache/commons/hivemind/service/impl
EJBProxyFactory.java
Log:
Change the parameters element to configure a parameters object provided by the
service implementation factory.
Revision ChangesPath
1.12 +5 -2
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/HiveMindMessages.properties
Index: HiveMindMessages.properties
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/HiveMindMessages.properties,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- HiveMindMessages.properties 15 Jul 2003 17:36:20 - 1.11
+++ HiveMindMessages.properties 16 Jul 2003 17:22:37 - 1.12
@@ -5,10 +5,13 @@
no-such-service-extension-id=Service extension point {0} does not exist.
no-such-configuration-extension-id=Configuration extension point {0} does not exist.
no-such-service=Service {0} (implementing interface {1}) does not exist.
-service-wrong-parameter-count=Service factory {0} expects {1,choice,0#no
parameters,1#one parameter, 1#{1} parameters} , but was passed {2,choice,0#no
parameters,1#one parameter, 1#{2} parameters} parameters.
+
+missing-factory-parameter=Core implementation factory parameter ''{0}'' is not
specified for factory {1}.
+
HiveMind.default-registry-not-set=HiveMind.getDefault() invoked before default
registry has been set.
HiveMind.elements-not-orderable=Elements of list {0} do not implement the Orderable
interface and can not be sorted.
+
# impl package
BaseRegistry.no-such-module-id=Registry does not contain module ''{0}''.
1.2 +14 -2
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/ServiceImplementationFactory.java
Index: ServiceImplementationFactory.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/ServiceImplementationFactory.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ServiceImplementationFactory.java 30 Jun 2003 23:04:30 - 1.1
+++ ServiceImplementationFactory.java 16 Jul 2003 17:22:37 - 1.2
@@ -65,6 +65,18 @@
*/
public interface ServiceImplementationFactory
{
+ /**
+ * Called first, to create a object to hold parameters. The lt;parametersgt;
+ * element will configure the empty object that is returned; the configured
+ * parameters object is passed back to
+ * [EMAIL PROTECTED] #createCoreServiceImplementation(ServiceExtensionPoint,
Object)}.
+ *
+ * @returns the object, or null if the factory does not use any
+ * parameters.
+ */
+
+ public Object createNewParameters();
+
/**
* Creates a core implementation object for a particular service extension
point.
* Typically, the factory creates an instance and modifies it to implement
@@ -76,5 +88,5 @@
* @param parameters any additional parameters that are needed by the factory.
* parameters may be empty, but won't be null.
*/
-public Object createCoreServiceImplementation(ServiceExtensionPoint point,
Object[] parameters);
+public Object createCoreServiceImplementation(ServiceExtensionPoint point,
Object parameters);
}
1.13 +8 -5 jakarta-commons-sandbox/hivemind/xdocs/descriptor.xml
Index: descriptor.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/descriptor.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- descriptor.xml2 Jul 2003 21:41:12 - 1.12
+++ descriptor.xml16 Jul 2003 17:22:37 - 1.13
@@ -682,13 +682,14 @@
td0..1/td
- tdA list of parameters passed to the
factory, used when it constructs the
[validator][digester] Compressed parsing exception....
Folks, I'm writing because I'm running across a really strange bug which I cannot, for the life of me figure out. Or rather, I know what's causing it, but I'm not sure why: I'm getting an exception when parsing an xml file (validation.xml) obtained as an input stream from the classpath within a compressed jar. The scenario...: I've written a stand-alone application which I release as an application jar for invocation as a jar. The jar file includes a validation.xml which is accessed as in input stream using ClassLoader.getResourceAsStream() and used as input to ValidatorResourcesInitializer in order to set up validation. The validator process makes use of digester to read the xml, and right now, what I see is an exception raised by the parser and propagated through digester and validator while parsing the validation.xml. Now comes the strange part: it appears that this exception is only raised when the validation.xml within the jar file has been compressed. Updating with a copy of the same file without compression resolved the problem. Has anyone seen anything like this before? (This may well have to do with the parser (xerces), as the exception is generated by the parser, but I thought it worth checking) I've used jar to extract the validation file, and update the jar file using the extracted file but without compression - no error occurs. Then I update the jar file once again (using the previously extracted file) with compression - the file compressed by about the same percentage as previously - and, once again, the exception occurs. How did I test for this? First, the system details: I'm running on windows XP using cygwin as my command line. (Ergo the strange mix between unix and windows notation in the following) I've tried invoking the program with both the sun jdk 1.4 and the ibm jdk 1.3 - the same problem occurs. I eventually determined what the final problem with the following bash script: jar -xvf mems-ear.ear rm mems-ear.ear jar -tvf mems.jar /tmp/predecomp.txt zipinfo -v mems.jar /tmp/predecomp.txt java com.solidusnetworks.mems.ui.controller.Controller /tmp/predecomp.txt jar -xvf mems.jar com/solidusnetworks/mems/resources/validation.xml jar -uvf0 mems.jar com/solidusnetworks/mems/resources/validation.xml jar -tvf mems.jar /tmp/postdecomp.txt zipinfo -v mems.jar /tmp/postdecomp.txt java com.solidusnetworks.mems.ui.controller.Controller /tmp/postdecomp.txt jar -uvf mems.jar com/solidusnetworks/mems/resources/validation.xml jar -tvf mems.jar /tmp/postrecomp.txt zipinfo -v mems.jar /tmp/postrecomp.txt java com.solidusnetworks.mems.ui.controller.Controller /tmp/postrecomp.txt diff /tmp/predecomp.txt /tmp/postdecomp.txt /tmp/diffdecomp.txt diff /tmp/postdecomp.txt /tmp/postrecomp.txt /tmp/diffrecomp.txt I attach as well the relevant results from the output files. 1) zipinfo.txt - Relevant sections of zipinfo output showing the change in validation.xml 2) appout.txt - Initial application log output showing validator initialization In each file, the three sections are denoted by the following labels: A) Original File B) After Decompression of validation.xml C) After Recompression of validation.xml Other libraries used: commons-beanutils.jar* commons-collections.jar* commons-digester.jar* commons-lang-1.0.1.jar* commons-logging-api.jar* commons-logging.jar* commons-validator-1.0.1-SOL-1.1.jar a version of validator edited to provide access to the results jakarta-oro-2.0.7.jar* jakarta-regexp-1.2.jar* mems-ejb.jar* contains shared code with ejb backend mems.jar* contains application code util.jar* xercesImpl.jar* lib\j2ee.jar lib\log4j.jar lib\jbossall-client.jar needed to access jboss JDNI repository If any of you have experienced something like this, I'd appreciate knowing. The behaviour is quite strange to me. Cheers, -AMT == Originial File == 0[main] DEBUG com.solidusnetworks.mems.ui.controller.Controller - java.assistive = ON java.runtime.name = Java(TM) 2 Runtime Environment, Standard Edition sun.boot.library.path = d:\Progra~1\IBM\WebSph~1\runtimes\base_v5\java\jre\bin java.vm.version = 1.3.1 java.vm.vendor = IBM Corporation java.vendor.url = http://www.ibm.com/ path.separator = ; java.vm.name = Classic VM file.encoding.pkg = sun.io java.vm.specification.name = Java Virtual Machine Specification user.dir = d:\Temp java.runtime.version = 1.3.1 java.fullversion = J2RE 1.3.1 IBM Windows 32 build cn131-20021107 (JIT enabled: jitc) java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment os.arch = x86 java.io.tmpdir = c:\DOCUME~1\ATHOMA~1.SOL\LOCALS~1\Temp\ line.separator = java.vm.specification.vendor = Sun Microsystems Inc. java.awt.fonts = os.name = Windows XP java.library.path =
DO NOT REPLY [Bug 21663] New: - [lang] Add support in ToStringStyle for DateFormat.
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=21663.
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=21663
[lang] Add support in ToStringStyle for DateFormat.
Summary: [lang] Add support in ToStringStyle for DateFormat.
Product: Commons
Version: 1.0.1 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This stems from a discussion on commons-user.
The basic idea is that ToStringStyle could be customized to include an optional
java.text DataFormat object. If the attched patch were in (mod some formatting
and unit tests which I can do), user could write code like this:
import java.lang.reflect.Field;
import java.text.SimpleDateFormat;
import java.util.Date;
import org.apache.commons.lang.builder.ReflectionToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;
public class TestRTSB {
static class MyToStringStyle extends ToStringStyle {
MyToStringStyle() {
this.setDateFormat(new SimpleDateFormat(-MM-dd));
}
}
public static void main(String[] arguments) {
System.out.println(new TestRTSB());
}
private int foo = 22;
private Date myDate = new Date();
public String toString() {
return new ReflectionToStringBuilder(this, new
MyToStringStyle()).toString();
}
// Use ToStringStyle.setDateFormat instead of:
//
//public String toString0() {
//return (new ReflectionToStringBuilder(this) {
//protected Object getValue(Field field) throws
IllegalArgumentException, IllegalAccessException {
//Object value = super.getValue(field);
//if (myDate.equals(field.getName())) {
//return new SimpleDateFormat(-MM-dd).format(value);
//} else {
//return value;
//}
//}
//}).toString();
//}
}
Any thoughts?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Add support in ToStringStyle for DateFormat.
Since I see Stephen's name on ToStringBuilder, would you care to comment on http://issues.apache.org/bugzilla/show_bug.cgi?id=21663 All other comments welcome, of course. Thanks, Gary
DO NOT REPLY [Bug 21663] - [lang] Add support in ToStringStyle for DateFormat.
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=21663. 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=21663 [lang] Add support in ToStringStyle for DateFormat. --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 18:50 --- Created an attachment (id=7332) ToStringBuilder.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] FastDateFormat Month bug?
Stephen,
Yes, you are absolutely right, thanks!
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 01:02
To: Jakarta Commons Developers List
Subject: Re: [lang] FastDateFormat Month bug?
The ISO8601 value you are defining is the a Duration format, not the
DateTime format. So a better name would be good.
From ISO8601:
- Time-interval: a portion of time between two time-points. These
time-points are respectively labelled start
and end. Time intervals may be specified by these two time-points, by one
of these time-points and the
temporal distance between the points or by the temporal distance between
these points only.
- Recurring time-interval: a series of consecutive time-intervals of the
same duration. Recurring time-intervals
may be specified by specification of one time-interval and the number of
recurrences.
- Duration: a quantity (length) of time. Duration is a physical unit
expressed in the units of time of the
International System of Units (SI), as defined in ISO 31-1.
Your format is a Duration as it has no start or end time. Note that this
means it should go in DurationFormatUtils, not DateFormatUtils.
Stephen
- Original Message -
From: Gary Gregory [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 6:39 AM
Subject: [lang] FastDateFormat Month bug?
Hello all,
I am working on an ISO 8601 extended date time format and I think I might
have run into a bug but I would like someone else's eye to check this since
I am not familiar with this implementation (which by the way I find *very*
nice with the use of 'Rules', etc). I was going to commit this but I would
prefer some to check my sanity.
I have test cases and all that
Index: FastDateFormat.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/FastDat
eFormat.java,v
retrieving revision 1.8
diff -u -r1.8 FastDateFormat.java
--- FastDateFormat.java 14 Jul 2003 22:25:05 - 1.8
+++ FastDateFormat.java 16 Jul 2003 05:33:50 -
@@ -998,7 +998,7 @@
}
public void appendTo(StringBuffer buffer, Calendar calendar) {
-appendTo(buffer, calendar.get(Calendar.MONTH) + 1);
+appendTo(buffer, calendar.get(Calendar.MONTH));
}
public final void appendTo(StringBuffer buffer, int value) {
FYI,
This is the doo-dad I am working on:
/**
* pISO8601 formatter for the date time extended format./p
*
* pThis format represents the Gregorian year, month, day, hour,
minute, and second components defined
* in § 5.5.3.2 of ISO 8601, respectively. These components are ordered
in their significance by their order
* of appearance i.e. as year, month, day, hour, minute, and second./p
*
* pThe ISO8601 extended format PnYnMnDTnHnMnS, where nY represents
the number of years, nM the number of months,
* nD the number of days, 'T' is the date/time separator, nH the number
of hours, nM the number of minutes and
* nS the number of seconds. The number of seconds can include decimal
digits to arbitrary precision..p
*
* The format used is tt'P''Y'M'M'd'DT'H'H'm'M's'S'/tt.
*
* TODO: How does create a pattern to support iThe number of seconds
can include decimal digits to arbitrary precision./i
* when we want to format and parse (which is not supported yet).
*
* @see a
href=http://www.w3.org/TR/xmlschema-2/#duration;http://www.w3.org/TR/xmlsc
hema-2/#duration/a
*/
public static final FastDateFormat ISO_DATETIME_EXTENDED_FORMAT
= FastDateFormat.getInstance('P''Y'M'M'd'DT'H'H'm'M's'S');
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] [PATCH] FileSystemManager.java
I believe it is useful for the FileSystemManager interface to declare a close method. This allows the close method in DefaultFileSystemManager to be called without casting. Index: FileSystemManager.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/ vfs/FileSystemManager.java,v retrieving revision 1.11 diff -r1.11 FileSystemManager.java 237a238,240 public void close(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
+1 to Stephen's plans btw for StringUtils.
Hen
On Wed, 16 Jul 2003, Stephen Colebourne wrote:
From: Gary Gregory [EMAIL PROTECTED]
I am not fond of isEmptyTrimmed, -1.
The semantics of trim() are very specific, and different to other
StringUtils methods (it removes all chars = 32). Hence the method name must
include the word trim.
Personally, I do not want to write code all over the place that reads
if (StringUtils.isEmptyTrimmedOrNull(value)) {
When I would be happy with a more *intelligent* isEmpty().
if (StringUtils.isEmpty(value)) {
My preference would also be for more intelligence, however I think we have
to recognise that StringUtils needs to be usable quickly without constant
javadoc reference. And that means explicit method names in certain cases.
The new behaviour will also be consistent with the isAlpha() etc. methods
where null is false.
At the risk my being dense (I can do that), can someone clarify why it is
important to test a trim String vs a /not/ trim'ed String? IOW, when would
it be incorrect for an app to do something when a value is but correct
when it is or \t?
Who knows? Its really just the case that users have different requirements.
We have already had one claim that null is treated differently from in an
application. Same for spaces I guess.
Stephen
Thanks,
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 17:12
To: Jakarta Commons Developers List
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces
OK, time to summarise the debate a little.
I have examined Java's String and StringBuffer classes. These refer to
'empty' as . They make no reference to 'blank'.
As a result I have updated StringUtils using the following terminology:
null - codenull/code
empty - a zero-length string (code/code)
space - the space character (code' '/code)(32)
whitespace - the characters defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}
All references to 'blank' have been removed. (Note that I've only gone
through StringUtils, not other classes).
This now means that the currently coded method isEmpty() is wrong as it
returns true for null. Similarly for isNotEmpty().
Thus I propose:
isEmpty(), true for , false for null
isEmptyOrNull(), true for and null
isEmptyTrimmed(), trim() then true for , false for null
isEmptyTrimmedOrNull(), trim() then true for , true for null
(Other proposed methods can be considered after 2.0. These should be
considered now)
I also propose the negative methods are the exact opposite.
isNotEmpty()
isNotEmptyOrNull()
isNotEmptyTrimmed()
isNotEmptyTrimmedOrNull()
For deprecation issues see another thread.
Can we have a +1 or not for this proposal.
Stephen
- Original Message -
From: Steven Caswell [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 12:04 AM
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces
I agree with Henri that a major benefit of the current isEmpty() is the
silent null handling. I would not be opposed to changing it to not trim,
as
long as there was an equivalent isEmptyTrimmed(), but I'm against
removing
the silent null handling. If I remember correctly, that was the original
intent.
I'm also very leery of a major change to the functionality of existing
methods. For backward compatibility, which I believe is very important,
I
hope we can come up with different names and leave the existing methods
pretty much as is.
And I also agree that Trivial just doesn't float my boat.
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:20 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(),
isNotEmpty() and stri ngsa with somespaces
The only major input I have at the moment is -1 to Trivial.
It's hard to find good words, but trivial just doesn't fit.
The number one piece of code to support is:
if( foo.getParameter() != null !.equals(foo.getParameter()) ) {
into
if( !StringUtils.isEmpty(foo.getParameter()) {
It reads a lot more easily, and is something that you quite
often find yourself doing in crappy ServletRequest-style environments.
Having the trims/not's is just syntactic sugar. I'm not a big
fan of the trim, and like the 'Trimmed' method to show it is there.
I do however like having systems that behave quietly when
possible under null. Throwing an NPE because null is just
utterly illegal is cool,
RE: [lang] commons-lang-2.0-rc1 ready for complaints
Erk. I will figure out why this happened. Explains the larger size. On Tue, 15 Jul 2003, Gary Gregory wrote: The file commons-lang-2.0-rc1.jar contains overview.html and all of the package.html files, which it should not. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 19:58 To: Jakarta Commons Developers List Subject: Re: [lang] commons-lang-2.0-rc1 ready for complaints Henri Yandell wrote: If people could take a look at http://www.apache.org/~bayard/commons-lang-2.0-rc1/ and complain about whatever is not right. The attached patch (against current HEAD) fixes some trivial typos in STATUS.html. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] commons-lang-2.0-rc1 ready for complaints
Yeah it is. I think this has been a problem in every version of the distribution. One thing I could do is make the zip file on Windows and the tar.gz file on Linux. That would probably work how people expect. Or I could unzip the txt files out, and unix2dos them, then rezip. Hen On Tue, 15 Jul 2003, Gary Gregory wrote: If you open LICENSE.txt and RELEASE-NOTES.txt with Notepad in Windows, there are no line breaks. If you open them in Wordpad, you see them ok. I imagine this is a CR vs. CR+LF thing. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 19:58 To: Jakarta Commons Developers List Subject: Re: [lang] commons-lang-2.0-rc1 ready for complaints Henri Yandell wrote: If people could take a look at http://www.apache.org/~bayard/commons-lang-2.0-rc1/ and complain about whatever is not right. The attached patch (against current HEAD) fixes some trivial typos in STATUS.html. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] commons-lang-2.0-rc1 ready for complaints
Is there not an ant task to change CR/LF for this reason? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 9:06 PM Subject: RE: [lang] commons-lang-2.0-rc1 ready for complaints Yeah it is. I think this has been a problem in every version of the distribution. One thing I could do is make the zip file on Windows and the tar.gz file on Linux. That would probably work how people expect. Or I could unzip the txt files out, and unix2dos them, then rezip. Hen On Tue, 15 Jul 2003, Gary Gregory wrote: If you open LICENSE.txt and RELEASE-NOTES.txt with Notepad in Windows, there are no line breaks. If you open them in Wordpad, you see them ok. I imagine this is a CR vs. CR+LF thing. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 19:58 To: Jakarta Commons Developers List Subject: Re: [lang] commons-lang-2.0-rc1 ready for complaints Henri Yandell wrote: If people could take a look at http://www.apache.org/~bayard/commons-lang-2.0-rc1/ and complain about whatever is not right. The attached patch (against current HEAD) fixes some trivial typos in STATUS.html. Phil - 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/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/07/16 13:19:24
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Remove old unused commented out code
Revision ChangesPath
1.57 +1 -32
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- StringUtils.java 15 Jul 2003 23:41:54 - 1.56
+++ StringUtils.java 16 Jul 2003 20:19:24 - 1.57
@@ -2226,37 +2226,6 @@
}
/**
- * pChecks if the String contains only certain chars./p
- *
- * @param str the String to check
- * @param validChars an array of valid chars
- * @return true if it only contains valid chars and is non-null
- */
- /* rewritten
-public static boolean containsOnly(String str, char[] validChars) {
-if (str == null || validChars == null) {
-return false;
-}
-int strSize = str.length();
-int validSize = validChars.length;
-for (int i = 0; i strSize; i++) {
-char ch = str.charAt(i);
-boolean contains = false;
-for (int j = 0; j validSize; j++) {
-if (validChars[j] == ch) {
-contains = true;
-break;
-}
-}
-if (contains == false) {
-return false;
-}
-}
-return true;
-}
-*/
-
-/**
* pChecks that the String does not contain certain chars./p
*
* @param str the String to check
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestGetMethodLocal.java TestHttpConnectionManager.java TestMethodCharEncoding.java TestMethodsExternalHost.java
olegk 2003/07/16 13:48:28
Modified:httpclient/src/java/org/apache/commons/httpclient
ChunkedInputStream.java HttpClient.java
HttpConnection.java HttpConnectionManager.java
HttpMethodBase.java HttpRecoverableException.java
MultiThreadedHttpConnectionManager.java
SimpleHttpConnectionManager.java URIException.java
httpclient/src/java/org/apache/commons/httpclient/methods
HeadMethod.java
httpclient/src/test/org/apache/commons/httpclient
TestGetMethodLocal.java
TestHttpConnectionManager.java
TestMethodCharEncoding.java
TestMethodsExternalHost.java
Removed: httpclient/src/java/org/apache/commons/httpclient
TransportException.java
Log:
Bug fix #19868 (Exception handling in HttpClient requires redesign)
Further exception handling clean-up
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke Laura Werner
Revision ChangesPath
1.18 +15 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java
Index: ChunkedInputStream.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ChunkedInputStream.java 13 Jul 2003 13:54:50 - 1.17
+++ ChunkedInputStream.java 16 Jul 2003 20:48:27 - 1.18
@@ -67,6 +67,9 @@
import java.io.IOException;
import java.io.InputStream;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
/**
* pTransparently coalesces chunks of a HTTP stream that uses
@@ -112,6 +115,8 @@
/** The method that this stream came from */
private HttpMethod method;
+/** Log object for this class. */
+private static final Log LOG = LogFactory.getLog(ChunkedInputStream.class);
/**
*
*
@@ -327,7 +332,13 @@
* @throws IOException If an IO problem occurs
*/
private void parseTrailerHeaders() throws IOException {
-Header[] footers = HttpParser.parseHeaders(in);
+Header[] footers = null;
+try {
+footers = HttpParser.parseHeaders(in);
+} catch(HttpException e) {
+LOG.error(Error parsing trailer headers, e);
+throw new IOException(e.getMessage());
+}
for (int i = 0; i footers.length; i++) {
method.addResponseFooter(footers[i]);
1.79 +5 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpClient.java
Index: HttpClient.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpClient.java,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -r1.78 -r1.79
--- HttpClient.java 5 Jul 2003 22:31:20 - 1.78
+++ HttpClient.java 16 Jul 2003 20:48:27 - 1.79
@@ -370,7 +370,7 @@
HttpConnectionManager connmanager = this.httpConnectionManager;
-HttpConnection connection = connmanager.getConnection(
+HttpConnection connection = connmanager.getConnectionWithTimeout(
methodConfiguration,
httpConnectionTimeout
);
1.69 +7 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- HttpConnection.java 5 Jul 2003 22:31:20 - 1.68
+++ HttpConnection.java 16 Jul 2003 20:48:27 - 1.69
@@ -1207,7 +1207,9 @@
// keep the original value of used, as it will be set to false by
close().
boolean tempUsed = used;
HttpConnection.this.close();
-if (tempUsed) {
+if (ioe instanceof InterruptedIOException) {
+return new IOTimeoutException(ioe.getMessage());
+} else if (tempUsed) {
LOG.debug(
Output exception occurred on a used connection. Will treat as
recoverable.,
ioe
1.16 +30 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnectionManager.java
Index: HttpConnectionManager.java
Re: [lang] commons-lang-2.0-rc1 ready for complaints
Good point. Will research that if we're happy with .zip being CR/LF and .tar.gz being CR. Hen On Wed, 16 Jul 2003, Stephen Colebourne wrote: Is there not an ant task to change CR/LF for this reason? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 9:06 PM Subject: RE: [lang] commons-lang-2.0-rc1 ready for complaints Yeah it is. I think this has been a problem in every version of the distribution. One thing I could do is make the zip file on Windows and the tar.gz file on Linux. That would probably work how people expect. Or I could unzip the txt files out, and unix2dos them, then rezip. Hen On Tue, 15 Jul 2003, Gary Gregory wrote: If you open LICENSE.txt and RELEASE-NOTES.txt with Notepad in Windows, there are no line breaks. If you open them in Wordpad, you see them ok. I imagine this is a CR vs. CR+LF thing. Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 19:58 To: Jakarta Commons Developers List Subject: Re: [lang] commons-lang-2.0-rc1 ready for complaints Henri Yandell wrote: If people could take a look at http://www.apache.org/~bayard/commons-lang-2.0-rc1/ and complain about whatever is not right. The attached patch (against current HEAD) fixes some trivial typos in STATUS.html. Phil - 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]
cvs commit: jakarta-commons/lang RELEASE-NOTES.txt
scolebourne2003/07/16 14:19:22
Modified:lang/src/java/org/apache/commons/lang/enum Enum.java
lang/src/java/org/apache/commons/lang/reflect
ReflectionUtils.java
lang/src/test/org/apache/commons/lang
StringUtilsTrimEmptyTest.java
lang/src/java/org/apache/commons/lang ClassUtils.java
StringUtils.java
lang RELEASE-NOTES.txt
Log:
Implement changes to StringUtils.isEmpty and friends
This is an incompatible change for isEmpty and isNotEmpty from 1.0
Revision ChangesPath
1.13 +5 -4
jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java
Index: Enum.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/enum/Enum.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Enum.java 14 Jul 2003 22:58:31 - 1.12
+++ Enum.java 16 Jul 2003 21:19:21 - 1.13
@@ -243,14 +243,15 @@
/**
* pConstructor to add a new named item to the enumeration./p
*
- * @param name the name of the enum object
+ * @param name the name of the enum object,
+ * must not be empty or codenull/code
* @throws IllegalArgumentException if the name is codenull/code
- * or a blank string
+ * or an empty string
*/
protected Enum(String name) {
super();
-if (StringUtils.isEmpty(name)) {
+if (StringUtils.isEmptyOrNull(name)) {
throw new IllegalArgumentException(The Enum name must not be empty or
null);
}
iName = name;
1.8 +4 -3
jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/ReflectionUtils.java
Index: ReflectionUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/ReflectionUtils.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ReflectionUtils.java 14 Jul 2003 22:28:48 - 1.7
+++ ReflectionUtils.java 16 Jul 2003 21:19:22 - 1.8
@@ -167,13 +167,14 @@
/**
* pGets a class object for the specified string./p
*
- * @param className fully qualified class name to find, must not be empty
+ * @param className fully qualified class name to find,
+ * must not be empty or codenull/code
* @return Class object for class
* @throws ReflectionException if an error occurs during reflection
* @throws IllegalArgumentException if the class name is empty
*/
public static Class getClass(String className) throws ReflectionException {
-if (StringUtils.isEmpty(className)) {
+if (StringUtils.isEmptyOrNull(className)) {
throw new IllegalArgumentException(The class name must not be null);
}
try {
1.9 +37 -5
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTrimEmptyTest.java
Index: StringUtilsTrimEmptyTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTrimEmptyTest.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- StringUtilsTrimEmptyTest.java 14 Jul 2003 22:26:22 - 1.8
+++ StringUtilsTrimEmptyTest.java 16 Jul 2003 21:19:22 - 1.9
@@ -137,7 +137,7 @@
assertEquals(false, StringUtils.isEmpty( foo ));
assertEquals(false, StringUtils.isEmpty( ));
assertEquals(true, StringUtils.isEmpty());
-assertEquals(true, StringUtils.isEmpty(null));
+assertEquals(false, StringUtils.isEmpty(null));
}
public void testIsNotEmpty() {
@@ -145,7 +145,23 @@
assertEquals(true, StringUtils.isNotEmpty( foo ));
assertEquals(true, StringUtils.isNotEmpty( ));
assertEquals(false, StringUtils.isNotEmpty());
-assertEquals(false, StringUtils.isNotEmpty(null));
+assertEquals(true, StringUtils.isNotEmpty(null));
+}
+
+public void testIsEmptyOrNull() {
+assertEquals(false, StringUtils.isEmptyOrNull(foo));
+assertEquals(false, StringUtils.isEmptyOrNull( foo ));
+assertEquals(false, StringUtils.isEmptyOrNull( ));
+assertEquals(true, StringUtils.isEmptyOrNull());
+assertEquals(true, StringUtils.isEmptyOrNull(null));
+}
+
+public void testIsNotEmptyOrNull() {
+assertEquals(true, StringUtils.isNotEmptyOrNull(foo));
+assertEquals(true, StringUtils.isNotEmptyOrNull( foo ));
+assertEquals(true, StringUtils.isNotEmptyOrNull( ));
cvs commit: jakarta-commons/lang RELEASE-NOTES.txt
scolebourne2003/07/16 14:23:50
Modified:lang/src/test/org/apache/commons/lang StringUtilsTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
lang RELEASE-NOTES.txt
Log:
Remove StringUtils.unescape
Its deprecated, and wasn't in 1.0
Revision ChangesPath
1.23 +1 -11
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java
Index: StringUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StringUtilsTest.java 15 Jul 2003 23:41:54 - 1.22
+++ StringUtilsTest.java 16 Jul 2003 21:23:50 - 1.23
@@ -478,16 +478,6 @@
\\u0234, StringUtils.escape(\u0234) );
assertEquals(escape(String) failed,
\\u00FD, StringUtils.escape(\u00fd) );
-assertEquals(unescape(String) failed,
- , StringUtils.unescape() );
-assertEquals(unescape(String) failed,
- test, StringUtils.unescape(test) );
-assertEquals(unescape(String) failed,
- \ntest\b, StringUtils.unescape(\\ntest\\b) );
-assertEquals(unescape(String) failed,
- \u123425foo\ntest\b,
StringUtils.unescape(\\u123425foo\\ntest\\b) );
-assertEquals(unescape(String) failed with unicode as final char,
- \u1234, StringUtils.unescape(\\u1234) );
}
public void testGetLevenshteinDistance() {
1.59 +1 -18
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- StringUtils.java 16 Jul 2003 21:19:22 - 1.58
+++ StringUtils.java 16 Jul 2003 21:23:50 - 1.59
@@ -1494,23 +1494,6 @@
return StringEscapeUtils.escapeJava(str);
}
-/**
- * pUnescapes any Java literals found in the String. For example,
- * it will turn a sequence of code'\'/code and code'n'/code
- * into a newline character, unless the code'\'/code is preceded
- * by another code'\'/code./p
- *
- * pAs of Lang 2.0, this calls [EMAIL PROTECTED]
StringEscapeUtils#unescapeJava(java.lang.String)}
- * behind the scenes./p
- *
- * @see StringEscapeUtils#unescapeJava(java.lang.String)
- * @deprecated Use [EMAIL PROTECTED]
StringEscapeUtils#unescapeJava(java.lang.String)}
- * This method will be removed in Commons Lang 3.0
- */
-public static String unescape(String str) {
-return StringEscapeUtils.unescapeJava(str);
-}
-
// Padding
//--
1.13 +3 -4 jakarta-commons/lang/RELEASE-NOTES.txt
Index: RELEASE-NOTES.txt
===
RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- RELEASE-NOTES.txt 16 Jul 2003 21:19:22 - 1.12
+++ RELEASE-NOTES.txt 16 Jul 2003 21:23:50 - 1.13
@@ -77,8 +77,8 @@
isNotEmpty() changed return true for null.
chomp() changed to be more like Perl.
Various methods changed in the handling of null (less exceptions).
-Thirty-one new methods.
-Eight methods deprecated.
+Thirty new methods.
+Seven methods deprecated.
SystemUtils:
isJavaVersionAtLeast(int) added. getJavaVersion() deprecated.
host of new constants.
@@ -274,7 +274,6 @@
public static java.lang.String sliceRemainder(java.lang.String,
java.lang.String);
public static java.lang.String sliceFirstRemainder(java.lang.String,
java.lang.String);
public static java.lang.String sliceFirst(java.lang.String, java.lang.String);
- public static java.lang.String unescape(java.lang.String);
public static java.lang.String rightPad(java.lang.String, int, char);
public static java.lang.String leftPad(java.lang.String, int, char);
public static java.lang.String uncapitaliseAllWords(java.lang.String);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] commons-lang-2.0-rc1 ready for complaints
Henri Yandell wrote: .tar.gz being CR. LF, I hope. CRs are for Macs (.sea) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/07/16 16:45:39
Modified:lang/src/test/org/apache/commons/lang StringUtilsTest.java
StringUtilsSubstringTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Update Null handling in StringUtils to handle nulls quietly
Revision ChangesPath
1.24 +113 -41
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java
Index: StringUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- StringUtilsTest.java 16 Jul 2003 21:23:50 - 1.23
+++ StringUtilsTest.java 16 Jul 2003 23:45:39 - 1.24
@@ -54,6 +54,7 @@
package org.apache.commons.lang;
import java.util.Arrays;
+import java.util.Iterator;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -153,6 +154,12 @@
}
public void testJoin() {
+assertEquals(null, StringUtils.concatenate(null));
+assertEquals(null, StringUtils.join((Object[]) null, null));
+assertEquals(null, StringUtils.join((Object[]) null, ','));
+assertEquals(null, StringUtils.join((Iterator) null, null));
+assertEquals(null, StringUtils.join((Iterator) null, ','));
+
assertEquals(concatenate(Object[]) failed,
TEXT_LIST_NOSEP, StringUtils.concatenate(ARRAY_LIST));
assertEquals(join(Object[], String) failed, TEXT_LIST,
@@ -256,6 +263,19 @@
public void testOverlayString() {
assertEquals(overlayString(String, String, int, int) failed,
foo foor baz, StringUtils.overlayString(SENTENCE, FOO, 4, 6)
);
+assertEquals(null, StringUtils.overlayString(null, null, 2, 4));
+assertEquals(abef, StringUtils.overlayString(abcdef, null, 2, 4));
+assertEquals(abef, StringUtils.overlayString(abcdef, , 2, 4));
+assertEquals(abef, StringUtils.overlayString(abcdef, , 2, 4));
+assertEquals(abcdcdef, StringUtils.overlayString(abcdef, , 4,
2));
+try {
+StringUtils.overlayString(abcdef, , -1, 4);
+fail();
+} catch (IndexOutOfBoundsException ex) {}
+try {
+StringUtils.overlayString(abcdef, , 2, 8);
+fail();
+} catch (IndexOutOfBoundsException ex) {}
}
public void testRepeat() {
@@ -272,8 +292,30 @@
}
public void testCenter() {
-assertEquals(center(String, int) failed,
-+FOO+ , StringUtils.center(FOO, 9) );
+assertEquals(null, StringUtils.center(null, -1));
+assertEquals(null, StringUtils.center(null, 4));
+assertEquals(, StringUtils.center(, 4));
+assertEquals( ab , StringUtils.center(ab, 4));
+assertEquals(abcd, StringUtils.center(abcd, 2));
+assertEquals( a , StringUtils.center(a, 4));
+
+assertEquals(null, StringUtils.center(null, -1, ));
+assertEquals(null, StringUtils.center(null, 4, ));
+assertEquals(, StringUtils.center(, 4, ));
+assertEquals( ab , StringUtils.center(ab, 4, ));
+assertEquals(abcd, StringUtils.center(abcd, 2, ));
+assertEquals( a , StringUtils.center(a, 4, ));
+assertEquals(yayz, StringUtils.center(a, 4, yz));
+try {
+StringUtils.center(abc, 4, null);
+fail();
+} catch (IllegalArgumentException ex) {
+}
+try {
+StringUtils.center(abc, 4, );
+fail();
+} catch (IllegalArgumentException ex) {
+}
}
public void testDeprecatedChompFunctions() {
@@ -304,6 +346,9 @@
{ \n, },
{ \r, },
{ \r\n, },
+{ null, null },
+{ , },
+{ a, },
};
for (int i = 0; i chopCases.length; i++) {
String original = chopCases[i][0];
@@ -370,6 +415,9 @@
{foo\nbar, foo},
{foo\nbar\n, foo\nbar},
{foo\nbar\nbaz, foo\nbar},
+{null, null},
+{, },
+{foo, foo},
};
for (int i = 0; i sliceCases.length; i++) {
String original = sliceCases[i][0];
@@ -381,47 +429,66 @@
String original = fooXXbarXXbaz;
String sep = XX;
-assertEquals(slice(String,String) failed,
- fooXXbar, StringUtils.slice(original, sep) );
+assertEquals(fooXXbar, StringUtils.slice(original, sep) );
+assertEquals(null, StringUtils.slice(null, sep) );
+
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/07/16 16:56:45
Modified:lang/src/test/org/apache/commons/lang StringUtilsTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Update Null handling in StringUtils to handle nulls quietly
Revision ChangesPath
1.25 +2 -6
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java
Index: StringUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- StringUtilsTest.java 16 Jul 2003 23:45:39 - 1.24
+++ StringUtilsTest.java 16 Jul 2003 23:56:44 - 1.25
@@ -279,16 +279,12 @@
}
public void testRepeat() {
+assertEquals(null, StringUtils.repeat(null, 2));
assertEquals(, StringUtils.repeat(ab, 0));
assertEquals(, StringUtils.repeat(, 3));
assertEquals(aaa, StringUtils.repeat(a, 3));
assertEquals(ababab, StringUtils.repeat(ab, 3));
assertEquals(abcabcabc, StringUtils.repeat(abc, 3));
-try {
-StringUtils.repeat(null, 0);
-fail();
-} catch (NullPointerException ex) {
-}
}
public void testCenter() {
1.61 +24 -15
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- StringUtils.java 16 Jul 2003 23:45:39 - 1.60
+++ StringUtils.java 16 Jul 2003 23:56:45 - 1.61
@@ -71,8 +71,15 @@
* liwhitespace - the characters defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}
* /ul
*
- * pThe codeStringUtils/code class varies in its handling of
- * codenull/code. Each method should be consulted individually./p
+ * pThe codeStringUtils/code tries to handle codenull/code input
+ * quietly. That is to say that a codenull/code will generally return a
+ * sensible value rather than throw an exception.
+ * Typically, codenull/code in gives codenull/code out.
+ * Each method should be consulted individually for full details./p
+ *
+ * pA side effect of the codenull/code handling is that a
+ * NullPointerException should be considered a bug in codeStringUtils/code.
+ * (Except for deprecated methods)./p
*
* @author a href=http://jakarta.apache.org/turbine/;Apache Jakarta Turbine/a
* @author GenerationJavaCore
@@ -1626,25 +1633,27 @@
* new string./p
*
* pre
+ * StringUtils.repeat(null, 2) = null
* StringUtils.repeat(, 0) =
* StringUtils.repeat(, 2) =
* StringUtils.repeat(a, 3) = aaa
* StringUtils.repeat(ab, 2) = abab
- * StringUtils.repeat(null, 2) = NullPointerException
- * StringUtils.repeat(a, -2) = NegativeArraySizeException
+ * StringUtils.repeat(a, -2) =
* /pre
*
- * @param str the String to repeat, must not be null
- * @param repeat number of times to repeat str
- * @return a new String consisting of the original String repeated
- * @throws NegativeArraySizeException if coderepeat lt; 0/code
- * @throws NullPointerException if str is codenull/code
+ * @param str the String to repeat, may be null
+ * @param repeat number of times to repeat str, negative treated as zero
+ * @return a new String consisting of the original String repeated,
+ * codenull/code if null string input
*/
public static String repeat(String str, int repeat) {
-int inputLength = str.length();
-if (repeat == 0) {
+if (str == null) {
+return null;
+}
+if (repeat = 0) {
return ;
}
+int inputLength = str.length();
if (inputLength == 1 repeat = PAD_LIMIT) {
return padding(repeat, str.charAt(0));
}
@@ -1904,8 +1913,8 @@
* StringUtils.leftPad(bat, 8, yz) = yzyzybat
* StringUtils.leftPad(bat, 1, yz) = bat
* StringUtils.leftPad(bat, -1, yz) = bat
- * StringUtils.leftPad(bat, 1, null) = NullPointerException
- * StringUtils.leftPad(bat, 1, )= ArithmeticException
+ * StringUtils.leftPad(bat, 1, null) = IllegalArgumentException
+ * StringUtils.leftPad(bat, 1, )= IllegalArgumentException
* /pre
*
* @param str the String to pad out, may be null
@@ -2841,7 +2850,7 @@
/**
* pFind the Levenshtein distance between two Strings./p
*
- * PThis is the number of changes needed
[lang] Pre 2.0 StringUtils NPE changes
I have done most of these. Still do do: strip methods case changing methods reverseDelimited() Currently the CVS tests do not pass. This is because the leftPad and rightPad methods don't work properly (as I see it) - I tightened the tests. Unfortunately I'm not going to be able to do anything until Fri eve GMT. Anyone can feel free to fix the bug! Or sort out the null handling... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
Changes made. Again a sanity check by someone would be good.
Hen, you might also want to re-run your diff for the release notes when we
are ready, as I'm sure its not completely accurate any more.
Stephen
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 9:05 PM
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri
ngsa with somespaces
+1 to Stephen's plans btw for StringUtils.
Hen
On Wed, 16 Jul 2003, Stephen Colebourne wrote:
From: Gary Gregory [EMAIL PROTECTED]
I am not fond of isEmptyTrimmed, -1.
The semantics of trim() are very specific, and different to other
StringUtils methods (it removes all chars = 32). Hence the method name
must
include the word trim.
Personally, I do not want to write code all over the place that reads
if (StringUtils.isEmptyTrimmedOrNull(value)) {
When I would be happy with a more *intelligent* isEmpty().
if (StringUtils.isEmpty(value)) {
My preference would also be for more intelligence, however I think we
have
to recognise that StringUtils needs to be usable quickly without
constant
javadoc reference. And that means explicit method names in certain
cases.
The new behaviour will also be consistent with the isAlpha() etc.
methods
where null is false.
At the risk my being dense (I can do that), can someone clarify why it
is
important to test a trim String vs a /not/ trim'ed String? IOW, when
would
it be incorrect for an app to do something when a value is but
correct
when it is or \t?
Who knows? Its really just the case that users have different
requirements.
We have already had one claim that null is treated differently from
in an
application. Same for spaces I guess.
Stephen
Thanks,
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 17:12
To: Jakarta Commons Developers List
Subject: Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and
stri
ngsa with somespaces
OK, time to summarise the debate a little.
I have examined Java's String and StringBuffer classes. These refer to
'empty' as . They make no reference to 'blank'.
As a result I have updated StringUtils using the following
terminology:
null - codenull/code
empty - a zero-length string (code/code)
space - the space character (code' '/code)(32)
whitespace - the characters defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}
All references to 'blank' have been removed. (Note that I've only gone
through StringUtils, not other classes).
This now means that the currently coded method isEmpty() is wrong as
it
returns true for null. Similarly for isNotEmpty().
Thus I propose:
isEmpty(), true for , false for null
isEmptyOrNull(), true for and null
isEmptyTrimmed(), trim() then true for , false for null
isEmptyTrimmedOrNull(), trim() then true for , true for null
(Other proposed methods can be considered after 2.0. These should be
considered now)
I also propose the negative methods are the exact opposite.
isNotEmpty()
isNotEmptyOrNull()
isNotEmptyTrimmed()
isNotEmptyTrimmedOrNull()
For deprecation issues see another thread.
Can we have a +1 or not for this proposal.
Stephen
- Original Message -
From: Steven Caswell [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List'
[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 12:04 AM
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and
stri
ngsa with somespaces
I agree with Henri that a major benefit of the current isEmpty() is
the
silent null handling. I would not be opposed to changing it to not
trim,
as
long as there was an equivalent isEmptyTrimmed(), but I'm against
removing
the silent null handling. If I remember correctly, that was the
original
intent.
I'm also very leery of a major change to the functionality of
existing
methods. For backward compatibility, which I believe is very
important,
I
hope we can come up with different names and leave the existing
methods
pretty much as is.
And I also agree that Trivial just doesn't float my boat.
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:20 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(),
isNotEmpty() and stri ngsa with somespaces
The only major input I have at the moment is -1 to Trivial.
It's hard to find good words, but trivial just doesn't fit.
The number one piece of code to support
Re: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces
On Thu, 17 Jul 2003, Stephen Colebourne wrote: Changes made. Again a sanity check by someone would be good. Hen, you might also want to re-run your diff for the release notes when we are ready, as I'm sure its not completely accurate any more. Will do once we get these bits all dealt with. I have this recurring fantasy that someday Lang 2.0 might happen :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
+1 Michael Becke wrote: I propose that we start using commons-codec (nightly builds) for our Base64 and URL encoding needs. This change would go into effect for the 2.1 release (HEAD). -- Vote: commons-codec dependency for 2.1 [ ] +1 I am in favor of this proposal. [ ] -1 I am against this proposal. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
+1. Also +1 for keeping a specific list of files that's required from codec so that applet developers like me can just pull them out instead of having the whole kit and kaboodle. I volunteer for such a role. Adrian Sutton. On Wednesday, July 16, 2003, at 05:05 PM, Ortwin Glück wrote: +1 Michael Becke wrote: I propose that we start using commons-codec (nightly builds) for our Base64 and URL encoding needs. This change would go into effect for the 2.1 release (HEAD). -- -- -- Vote: commons-codec dependency for 2.1 [ ] +1 I am in favor of this proposal. [ ] -1 I am against this proposal. -- -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Adrian Sutton wrote: +1. Also +1 for keeping a specific list of files that's required from codec so that applet developers like me can just pull them out instead of having the whole kit and kaboodle. I volunteer for such a role. Adrian Sutton. Currently Codec consists of 2 (two) classes, Adrian :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Packages always seem to get bigger - something about people wanting new functionality all the time... :) I'm actually keen to start a policy of very exact (but unofficial) dependency listings for those scungy folks like me. :) For instance if we add lang as a dependency I'd definitely be cutting it down as much as I could. Regards, Adrian Sutton. On Wednesday, July 16, 2003, at 06:45 PM, Ortwin Glück wrote: Adrian Sutton wrote: +1. Also +1 for keeping a specific list of files that's required from codec so that applet developers like me can just pull them out instead of having the whole kit and kaboodle. I volunteer for such a role. Adrian Sutton. Currently Codec consists of 2 (two) classes, Adrian :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
oops, true. No idea why I remembered only two classes... Kalnichevski, Oleg wrote: Odi, I do not think it is quite correct. There's now at least two dozens of files, and some of them are really of marginal use (language and phonetic encoders, for instance) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add commons-codec as an HttpClient dependency
Because only two are really worth remebering (Base64 URLCodec) as far as we are concerned ;-) (At least for now) Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 10:55 To: Commons HttpClient Project Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency oops, true. No idea why I remembered only two classes... Kalnichevski, Oleg wrote: Odi, I do not think it is quite correct. There's now at least two dozens of files, and some of them are really of marginal use (language and phonetic encoders, for instance) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
On Wednesday, July 16, 2003, at 05:38 AM, Kalnichevski, Oleg wrote: I have a few concerns, though: 1.) URLCodec that we should be using has not been officially released yet True, but neither has HttpClient 2.1:) We will most likely have to put some effort into getting a final codec release that contains this code. 2.) Introduction of an external dependency is (IMHO) also a breach of contract very much like API breakage. I would like to suggest that we keep a copy of relevant codec classes in HttpClient source tree for the 2.1 release. Does anyone see any downsides to that I may be missing? I agree, adding a jar could be considered an API break, but it was part of our plan for 2.1. The only real API changes that this requires is removing the already deprecated Base64 code. The EncodingUtil class will not be changed. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add commons-codec as an HttpClient dependency
True, but neither has HttpClient 2.1:) We will most likely have to put some effort into getting a final codec release that contains this code. I agree, adding a jar could be considered an API break, but it was part of our plan for 2.1. The only real API changes that this requires is removing the already deprecated Base64 code. The EncodingUtil class will not be changed. Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] One possible solution would be to build a version of HttpClient that unpacks the commons-codec and combines it with HttpClient. People who need the one jar does it all could use that one. We could even be clever and pull out only those class files we need, thus satisfying Adrian's desire as well. Granted, there would then be two JAR files, but we could clearly indicate that the combination one would go away by 3.0. Just an idea. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
That's not a bad idea, but I would definitely like to avoid having any more than one officially sanctioned jar file. It's quite simple for people to build their own uber-jar if needed. Personally, I don't see any problem with adding a dependency for 2.1. If anyone does have an issue with this, it would be really good to hear from you now. Regards, Adrian Sutton. On Wednesday, July 16, 2003, at 11:32 PM, Eric Johnson wrote: Kalnichevski, Oleg wrote: Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] One possible solution would be to build a version of HttpClient that unpacks the commons-codec and combines it with HttpClient. People who need the one jar does it all could use that one. We could even be clever and pull out only those class files we need, thus satisfying Adrian's desire as well. Granted, there would then be two JAR files, but we could clearly indicate that the combination one would go away by 3.0. Just an idea. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. No need to resort to the 'Evil Comrade'. I have been looking into standard versioning techniques http://jakarta.apache.org/site/versioning.html in order to get some perspective on this. On the positive side, it seems that for a minor release (what we are doing) it is okay to add an external dependency. So, if we ever plan to add codec we might as well do it now. On the negative side, we are supposed to be making only external-interface-compatible changes. In general this has been our goal, but we have removed some deprecated methods which is a no-no. We may also have some difficulty with this when it comes to redirects. This makes we wonder if our plans for 2.1 are compatible with a minor release. Granted we can bend the rules a little with the consensus of HttpClient users but I want to keep from going too far. I suggest we consider resurrecting the removed deprecated code (ever though it was nasty and I am glad it is gone). I also think we should start looking closely at how we will accomplish our plan to move redirect/retry logic to HttpClient. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add commons-codec as an HttpClient dependency
Mike, It may be too a strong opinion, but I am convinced 2.0 API is not worth a single hour of further development beyond bug fixes. I will also strongly object any cross-site redirect fix at the expense of overall quality. I think we have spent enough time already coming up with all sorts of creative ways of bending 2.0 API and it simply did not work. There's no way I take part in anything similar to HttpMethodBase#fakeResponse method. If it is just about release numbers, let us call it HttpClient 3.0, or HttpClient 3.1, or HttpClient NT, or HttpClient.NET, or HttpClient Whatever, but I finally want to be able to do things right Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 16:26 To: Commons HttpClient Project Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency Kalnichevski, Oleg wrote: Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. No need to resort to the 'Evil Comrade'. I have been looking into standard versioning techniques http://jakarta.apache.org/site/versioning.html in order to get some perspective on this. On the positive side, it seems that for a minor release (what we are doing) it is okay to add an external dependency. So, if we ever plan to add codec we might as well do it now. On the negative side, we are supposed to be making only external-interface-compatible changes. In general this has been our goal, but we have removed some deprecated methods which is a no-no. We may also have some difficulty with this when it comes to redirects. This makes we wonder if our plans for 2.1 are compatible with a minor release. Granted we can bend the rules a little with the consensus of HttpClient users but I want to keep from going too far. I suggest we consider resurrecting the removed deprecated code (ever though it was nasty and I am glad it is gone). I also think we should start looking closely at how we will accomplish our plan to move redirect/retry logic to HttpClient. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: True, but neither has HttpClient 2.1:) We will most likely have to put some effort into getting a final codec release that contains this code. I agree, adding a jar could be considered an API break, but it was part of our plan for 2.1. The only real API changes that this requires is removing the already deprecated Base64 code. The EncodingUtil class will not be changed. Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Chill out, dude. Personally, I was not insisting on complete (maximum) API compatibility, but was just offended/scared by your tone. I didn't expect to hear we guarantee 100% backwards compatibility, just a we'll try to preserve backwards compatibility as much as possible. I have read the 2.1 release plan when it was posted, and if I (as a user) would not have been in agreement, I'd have voiced my concerns. I also think that migrating to Commons-Codec is a good idea, and it should be a very managable change for all API clients (for example, there's no problem adding Commons-Codec to the classpath of HttpClient 2.0.x). Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. You could also work on choosing your words more carefully sometimes, put a little smiley behind sarcastic statements, and fix your caps lock ;-) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Christopher Lenz wrote: just a we'll try to preserve backwards compatibility as much as possible. May I remind everybody that we made the 2.0 branch so that we can finally overhaul the architecture. This normally implies large scale API changes. Maintaining backwards compatibility and doing rearchitecture at the same time is really hard. The term preserve backwards compatibility as much as possible is a silly term since nobody will break an API for no reason. What we need right now is the freedom to move code in the right places, fix design flaws and create the API we desire. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: If it is just about release numbers, let us call it HttpClient 3.0 Amen. I'm not sure how much point there is in a 2.1 release if there's not allowed to be *any* API breakage. Maybe we should freeze the 2.0 stream and just put out 2.0.1, etc. bug fix releases and call the current main trunk 3.0 so that we can clean up some of this stuff. I think it might still pay to do some of it gradually, like the current exception fixes in 3.0 and the removal of the IOException inheritance in 4.0 so that the transitions are easuer. But I don't think we should be striving for 100% API compatibility in the next release. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
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=19868. 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=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 16:40 --- Ditto. Check it in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: It may be too a strong opinion, but I am convinced 2.0 API is not worth a single hour of further development beyond bug fixes. I will also strongly object any cross-site redirect fix at the expense of overall quality. I think we have spent enough time already coming up with all sorts of creative ways of bending 2.0 API and it simply did not work. There's no way I take part in anything similar to HttpMethodBase#fakeResponse method. I agree. My desire is to leave 2.0 in the dust. If it is just about release numbers, let us call it HttpClient 3.0, or HttpClient 3.1, or HttpClient NT, or HttpClient.NET, or HttpClient Whatever, but I finally want to be able to do things right I guess you are right. It is mostly a case of semantics. What exactly do we mean by 2.1? The official description of a minor release does not really fit with our plans (which I still agree with). I do not think a 3.0 release is quite appropriate either though. Is there a middle ground? 2.55 perhaps:) Sorry to bring all of this up again. Perhaps I should just stop worrying about it. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add commons-codec as an HttpClient dependency
I guess you are right. It is mostly a case of semantics. What exactly do we mean by 2.1? The official description of a minor release does not really fit with our plans (which I still agree with). I do not think a 3.0 release is quite appropriate either though. Is there a middle ground? 2.55 perhaps:) Mike, My initial idea was we would bend the release guidelines somewhat for 2.1 release. 2.1 would be in essence '2.0 done more or less right'. We would have to do some selective and limited API changes but would retain the overall conceptual compatibility. Nothing truly radical and ground breaking. Since we can't seem to be able to take such approach, then I would simply call it the end of the story for the 2.x branch. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
My initial idea was we would bend the release guidelines somewhat for 2.1 release. 2.1 would be in essence '2.0 done more or less right'. We would have to do some selective and limited API changes but would retain the overall conceptual compatibility. Nothing truly radical and ground breaking. Since we can't seem to be able to take such approach, then I would simply call it the end of the story for the 2.x branch. Oleg, Well said. The 2.0 release is really not what any of us wanted. I was also looking to 2.1 as the first release 'done more or less right'. I think we can still accomplish this. We may just have to ignore the official guidelines for what constitutes a minor release. It sounds like you are leaning towards calling this 3.0, is that correct? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Well said. The 2.0 release is really not what any of us wanted. I was also looking to 2.1 as the first release 'done more or less right'. I think we can still accomplish this. We may just have to ignore the official guidelines for what constitutes a minor release. It sounds like you are leaning towards calling this 3.0, is that correct? Not really. I am still fully behind the 2.1 release plan (as long as it remains about 'doing 2.0 more or less right', and not about second attempt at trying to work around the existing design limitations). However, if the pressure mounts to strictly follow the Jakarta release guidelines, I will strongly favour bypassing 2.1 release and going straight to 3.0 Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
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=19868. 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=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 20:53 --- Patch (refactoring, try #5) committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
