Re: [latka] - is Latka still alive ?
Well - uhmm - I'll have to look for specifics then :-) But the many (Under Construction) on this page http://jakarta.apache.org/commons/latka/users-guide.html the (more to come)'s on this page http://jakarta.apache.org/commons/latka/index.html And the - by much - out-datedness of this page http://jakarta.apache.org/commons/latka/status.html sort of scared me away. It's very encourageing that you and Morgan answered, though - I think I'll take another look at Latka. Thanks Anders PS I just had a wild idea. How about wrapping Mozilla/Firebird (or Konqueror, if it's cross-platform enough) in JNI-stubs implementing the org.apache.commons.latka.http interfaces. In my brief testing of it, the commons httpclient seems to have some weeknesses on redirection (to other domains and protocols eg. http - https) and redirection by javaScript (eg document.location=someNewUrlVar;- I know it's atrocious, but some pages do it) Have you thought about that?? dion gillard [EMAIL PROTECTED] To: [EMAIL PROTECTED] com.aucc: Sent by: Subject: Re: [latka] - is Latka still alive ? news [EMAIL PROTECTED] .org 07/11/2003 05:35 AM Please respond to Jakarta Commons Developers List Anders B. Nørgaard wrote: Is there some kind of schedule or roadmap to look at? Or is it considered fully functional (and not necessary to document ;-) -Anders What's missing from the documentation :-( -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au - 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: [functor] generators
I've been digging into the generator stuff Jason submitted a while back a little more closely, and I have a few questions and comments I'd like to drill into, but let me start with an easy one. Currently functor.generators includes a io subpackage, containing EachLine, which is a Generator for each line of some BufferedReader. Since BufferedReader may throw an IOException, this introduces a need for GeneratorException (a RuntimeException wrapping an Exception, in this case, an IOException), which in turn introduces a dependency on JDK 1.4 (for the RuntimeException(Exception) constructor). In the long run, it seems like there may be quite a number of functor subpackage like io (or net, or sql, etc.). These may have a home in functor itself, in extension jars distributed via the functor component (functor-core.jar, functor-io.jar, functor-sql.jar, etc.) or in some other component (in commons or elsewhere) that happens to use or support the functor interfaces (commons-io.jar, for example). In the short run, which may include everything up to a 1.0 release, I wonder if we may be better off not including these sorts of extensions in functor itself. These aren't difficult to create outside of functor and not having them will allow us to punt on a host of issues (packaging and exception handling to name just two) in the interim. In particular, this would mean dropping EachLine (and hence GeneratorException) from current HEAD, which would remove a few types, a package, and as restore support of JDK 1.2 and 1.3 (as well as 1.1 with the java.util collections). Complaints? - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] named stacks
On Monday, July 14, 2003, at 01:08 AM, Simon Kitching wrote: Hi Robert, From this email, I presume that your implementation of pass return value of CallMethodRule as parameter to another CallMethodRule requires another stack? i have a few different ideas which could solve variations of this problem. Can you explain why the new stack is required? a new stack would only be needed to solve the most general use case. it would be pretty simple to provide an easy solution that pushes the result onto the main object stack and which a param could later read. the object would only available on the main object stack for child elements of the element to which the CallMethodRule was mapped. for example consider alphabeta//alphagamma/ with the call method pusher mapped onto the alpha element. a param rule mapped to beta would be able to access the object but not a rule mapped to gamma. another solution would be to alter the parameter stack when the call method is executed. this would work only when the parameter setting call method rule was mapped within the element to which the major call method rule was mapped. for example with alphabeta//alphagamma/ this would work when the parameter setting call method was mapped to beta and the call method using the parameter was mapped to alpha but not when the parameter setting rule was mapped to gamma. but i think that the most general use case requires an independent communication channel independent of the main object stack and the parameter stack. stacks feel like the right way to communicate for SAX-based applications. allowing a rule to push this onto an arbitrary named stack which another rule could pop off later seems to me like a good way to provide the most general form of this functionality. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building the commons website
On Monday, July 14, 2003, at 12:31 AM, Tim O'Brien wrote: On Sun, 2003-07-13 at 11:13, robert burrell donkin wrote: storing jars in cvs should be avoided (where possible). Agreed in principle, I've never enjoyed storing dependencies in CVS myself. but jakarta-commons build.xml simply references jar files that have been checked into another project's CVS module. Namely, by default, we get JDOM jars from ../jakarta-velocity/build/(I forget)/jdom-b8.jar IIRC this was done for the convenience of those who have most of jakarta checked out and because no one has ever been to agree on any better defaults. Anyone for a Maven-esque solution? Or a half-measure aimed at reducing the amount of manual work involved... i'm not really convinced that the trouble of manually adding half a dozen properties to a build.properties.sample file is so great that we need to do anything too radical. maybe we could reference (by default) the jars in jakarta-site2/lib. this would isolate us from problems with later velocity versions and jakarta-site2 is a small module which most jakarta committers will want access to sooner or later. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils ConvertUtilsBean.java
rdonkin 2003/07/14 14:11:05 Modified:beanutils/src/java/org/apache/commons/beanutils ConvertUtilsBean.java Log: Some small tidying up of the source code by a little refactoring. Submitted by Eric Pabst. Revision ChangesPath 1.9 +43 -39 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java Index: ConvertUtilsBean.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ConvertUtilsBean.java 7 Jul 2003 22:06:44 - 1.8 +++ ConvertUtilsBean.java 14 Jul 2003 21:11:05 - 1.9 @@ -529,55 +529,59 @@ short shortArray[] = new short[0]; String stringArray[] = new String[0]; -converters.clear(); -converters.put(BigDecimal.class, new BigDecimalConverter()); -converters.put(BigInteger.class, new BigIntegerConverter()); -converters.put(Boolean.TYPE, new BooleanConverter(defaultBoolean)); -converters.put(Boolean.class, new BooleanConverter(defaultBoolean)); -converters.put(booleanArray.getClass(), + converters.clear(); +register(BigDecimal.class, new BigDecimalConverter()); +register(BigInteger.class, new BigIntegerConverter()); +register(Boolean.TYPE, new BooleanConverter(defaultBoolean)); +register(Boolean.class, new BooleanConverter(defaultBoolean)); +register(booleanArray.getClass(), new BooleanArrayConverter(booleanArray)); -converters.put(Byte.TYPE, new ByteConverter(defaultByte)); -converters.put(Byte.class, new ByteConverter(defaultByte)); -converters.put(byteArray.getClass(), +register(Byte.TYPE, new ByteConverter(defaultByte)); +register(Byte.class, new ByteConverter(defaultByte)); +register(byteArray.getClass(), new ByteArrayConverter(byteArray)); -converters.put(Character.TYPE, +register(Character.TYPE, new CharacterConverter(defaultCharacter)); -converters.put(Character.class, +register(Character.class, new CharacterConverter(defaultCharacter)); -converters.put(charArray.getClass(), +register(charArray.getClass(), new CharacterArrayConverter(charArray)); -converters.put(Class.class, new ClassConverter()); -converters.put(Double.TYPE, new DoubleConverter(defaultDouble)); -converters.put(Double.class, new DoubleConverter(defaultDouble)); -converters.put(doubleArray.getClass(), +register(Class.class, new ClassConverter()); +register(Double.TYPE, new DoubleConverter(defaultDouble)); +register(Double.class, new DoubleConverter(defaultDouble)); +register(doubleArray.getClass(), new DoubleArrayConverter(doubleArray)); -converters.put(Float.TYPE, new FloatConverter(defaultFloat)); -converters.put(Float.class, new FloatConverter(defaultFloat)); -converters.put(floatArray.getClass(), +register(Float.TYPE, new FloatConverter(defaultFloat)); +register(Float.class, new FloatConverter(defaultFloat)); +register(floatArray.getClass(), new FloatArrayConverter(floatArray)); -converters.put(Integer.TYPE, new IntegerConverter(defaultInteger)); -converters.put(Integer.class, new IntegerConverter(defaultInteger)); -converters.put(intArray.getClass(), +register(Integer.TYPE, new IntegerConverter(defaultInteger)); +register(Integer.class, new IntegerConverter(defaultInteger)); +register(intArray.getClass(), new IntegerArrayConverter(intArray)); -converters.put(Long.TYPE, new LongConverter(defaultLong)); -converters.put(Long.class, new LongConverter(defaultLong)); -converters.put(longArray.getClass(), +register(Long.TYPE, new LongConverter(defaultLong)); +register(Long.class, new LongConverter(defaultLong)); +register(longArray.getClass(), new LongArrayConverter(longArray)); -converters.put(Short.TYPE, new ShortConverter(defaultShort)); -converters.put(Short.class, new ShortConverter(defaultShort)); -converters.put(shortArray.getClass(), +register(Short.TYPE, new ShortConverter(defaultShort)); +register(Short.class, new ShortConverter(defaultShort)); +register(shortArray.getClass(), new ShortArrayConverter(shortArray)); -converters.put(String.class, new
Just4log a postprocessor to optimize performances of Apache loggingCommons
Hi, I have started a postprocessor, using BCEL, to optimize the performance of Java classes that use Jakarta Logging Commons. What should I do if I want to be referenced in the website ? http://just4log.sourceforge.net/ It is released under the Apache License. Do not hesitate to contact me for any questions. Thanks in advance, Lucas Bruand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils MethodUtils.java
rdonkin 2003/07/14 14:38:53
Modified:beanutils/src/java/org/apache/commons/beanutils
MethodUtils.java
Log:
Refactored and exposed a few more methods which some people might find useful.
Submitted by Eric Pabst.
Revision ChangesPath
1.22 +91 -18
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/MethodUtils.java
Index: MethodUtils.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/MethodUtils.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- MethodUtils.java 20 May 2003 20:36:57 - 1.21
+++ MethodUtils.java 14 Jul 2003 21:38:52 - 1.22
@@ -722,35 +722,108 @@
*
* @return true if the assignement is compatible.
*/
-protected static final boolean isAssignmentCompatible(Class parameterType,
Class parameterization) {
+public static final boolean isAssignmentCompatible(Class parameterType, Class
parameterization) {
// try plain assignment
if (parameterType.isAssignableFrom(parameterization)) {
return true;
}
if (parameterType.isPrimitive()) {
-// does anyone know a better strategy than comparing names?
-// also, this method does *not* do widening - you must specify exactly
+// this method does *not* do widening - you must specify exactly
// is this the right behaviour?
-if (boolean.class.equals(parameterType)) {
-return Boolean.class.equals(parameterization);
-}
-if (float.class.equals(parameterType)) {
-return Float.class.equals(parameterization);
-}
-if (long.class.equals(parameterType)) {
-return Long.class.equals(parameterization);
-}
-if (int.class.equals(parameterType)) {
-return Integer.class.equals(parameterization);
-}
-if (double.class.equals(parameterType)) {
-return Double.class.equals(parameterization);
-}
+Class parameterWrapperClazz = getPrimitiveWrapper(parameterType);
+if (parameterWrapperClazz != null) {
+return parameterWrapperClazz.equals(parameterization);
+}
}
return false;
}
+
+/**
+ * Gets the wrapper object class for the given primitive type class.
+ * For example, passing codeboolean.class/code returns
codeBoolean.class/code
+ * @param primitiveType the primitive type class for which a match is to be
found
+ * @return the wrapper type associated with the given primitive
+ * or null if no match is found
+ */
+public static Class getPrimitiveWrapper(Class primitiveType) {
+// does anyone know a better strategy than comparing names?
+if (boolean.class.equals(primitiveType)) {
+return Boolean.class;
+} else if (float.class.equals(primitiveType)) {
+return Float.class;
+} else if (long.class.equals(primitiveType)) {
+return Long.class;
+} else if (int.class.equals(primitiveType)) {
+return Integer.class;
+} else if (short.class.equals(primitiveType)) {
+return Short.class;
+} else if (byte.class.equals(primitiveType)) {
+return Byte.class;
+} else if (double.class.equals(primitiveType)) {
+return Double.class;
+} else if (char.class.equals(primitiveType)) {
+return Character.class;
+} else {
+
+return null;
+}
+}
+
+/**
+ * Gets the class for the primitive type corresponding to the primitive wrapper
class given.
+ * For example, an instance of codeBoolean.class/code returns a
codeboolean.class/code.
+ * @param wrapperType the
+ * @return the primitive type class corresponding to the given wrapper class,
+ * null if no match is found
+ */
+public static Class getPrimitiveType(Class wrapperType) {
+// does anyone know a better strategy than comparing names?
+if (Boolean.class.equals(wrapperType)) {
+return boolean.class;
+} else if (Float.class.equals(wrapperType)) {
+return float.class;
+} else if (Long.class.equals(wrapperType)) {
+return long.class;
+} else if (Integer.class.equals(wrapperType)) {
+return int.class;
+} else if (Short.class.equals(wrapperType)) {
+return short.class;
+} else if
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale LocaleBeanUtils.java
rdonkin 2003/07/14 14:44:08 Modified:beanutils/src/java/org/apache/commons/beanutils/locale LocaleBeanUtils.java Log: Correct bugs in javadocs which were causing warnings. Revision ChangesPath 1.5 +6 -6 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtils.java Index: LocaleBeanUtils.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleBeanUtils.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocaleBeanUtils.java 20 Mar 2003 20:12:25 - 1.4 +++ LocaleBeanUtils.java 14 Jul 2003 21:44:08 - 1.5 @@ -76,8 +76,8 @@ * pUtility methods for populating JavaBeans properties * via reflection in a locale-dependent manner./p * - * pThe implementations for these methods are provided by codeLocalBeanUtilsBean/code. - * For more details see [EMAIL PROTECTED] LocalBeanUtilsBean}./p + * pThe implementations for these methods are provided by codeLocaleBeanUtilsBean/code. + * For more details see [EMAIL PROTECTED] LocaleBeanUtilsBean}./p * * @author Craig R. McClanahan * @author Ralph Schaer @@ -454,7 +454,7 @@ /** * Resolve any nested expression to get the actual target bean. * - * @deprecated moved into codeLocalBeanUtilsBean/code + * @deprecated moved into codeLocaleBeanUtilsBean/code * @param bean The bean * @param name The property name * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/enum Enum.java
bayard 2003/07/14 15:20:20
Modified:lang/src/java/org/apache/commons/lang/enum Enum.java
Log:
Javadoc fixes and a refactoring to use StringUtils.
Revision ChangesPath
1.11 +104 -71
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.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Enum.java 6 Feb 2003 20:13:07 - 1.10
+++ Enum.java 14 Jul 2003 22:20:20 - 1.11
@@ -62,21 +62,23 @@
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import org.apache.commons.lang.StringUtils;
/**
- * Abstract superclass for type-safe enums.
- * p
- * One feature of the C programming language lacking in Java is enumerations. The
+ * pAbstract superclass for type-safe enums./p
+ *
+ * pOne feature of the C programming language lacking in Java is enumerations. The
* C implementation based on ints was poor and open to abuse. The original Java
* recommendation and most of the JDK also uses int constants. It has been
recognised
* however that a more robust type-safe class-based solution can be designed. This
- * class follows the basic Java type-safe enumeration pattern.
- * p
- * emNOTE:/emDue to the way in which Java ClassLoaders work, comparing Enum
objects
+ * class follows the basic Java type-safe enumeration pattern./p
+ *
+ * pemNOTE:/emDue to the way in which Java ClassLoaders work, comparing Enum
objects
* should always be done using the equals() method, not ==. The equals() method will
- * try == first so in most cases the effect is the same.
+ * try == first so in most cases the effect is the same./p
*
* h4Simple Enums/h4
- * To use this class, it must be subclassed. For example:
+ *
+ * pTo use this class, it must be subclassed. For example:/p
*
* pre
* public final class ColorEnum extends Enum {
@@ -105,19 +107,19 @@
* }
* }
* /pre
- * p
- * As shown, each enum has a name. This can be accessed using codegetName/code.
- * p
- * The codegetEnum/code and codeiterator/code methods are recommended.
+ *
+ * pAs shown, each enum has a name. This can be accessed using
codegetName/code./p
+ *
+ * pThe codegetEnum/code and codeiterator/code methods are recommended.
* Unfortunately, Java restrictions require these to be coded as shown in each
subclass.
- * An alternative choice is to use the [EMAIL PROTECTED] EnumUtils} class.
+ * An alternative choice is to use the [EMAIL PROTECTED] EnumUtils} class./p
*
* h4Subclassed Enums/h4
- * A hierarchy of Enum classes can be built. In this case, the superclass is
+ * pA hierarchy of Enum classes can be built. In this case, the superclass is
* unaffected by the addition of subclasses (as per normal Java). The subclasses
- * may add additional Enum constants iof the type of the superclass/i. The
+ * may add additional Enum constants emof the type of the superclass/em. The
* query methods on the subclass will return all of the Enum constants from the
- * superclass and subclass.
+ * superclass and subclass./p
*
* pre
* public class ExtraColorEnum extends ColorEnum {
@@ -146,15 +148,16 @@
* }
* }
* /pre
- *
- * This example will return RED, GREEN, BLUE, YELLOW from the List and iterator
+ *
+ * pThis example will return RED, GREEN, BLUE, YELLOW from the List and iterator
* methods in that order. The RED, GREEN and BLUE instances will be the same (==)
* as those from the superclass ColorEnum. Note that YELLOW is declared as a
- * ColorEnum and not an ExtraColorEnum.
+ * ColorEnum and not an ExtraColorEnum./p
*
* h4Functional Enums/h4
- * The enums can have functionality by using anonymous inner classes
- * [Effective Java, Bloch01]:
+ *
+ * pThe enums can have functionality by using anonymous inner classes
+ * [Effective Java, Bloch01]:/p
*
* pre
* public abstract class OperationEnum extends Enum {
@@ -192,9 +195,8 @@
* }
* }
* /pre
- * p
- * emNOTE:/em This class originated in the Jakarta Avalon project.
- * /p
+ *
+ * pemNOTE:/em This class originated in the Jakarta Avalon project./p
*
* @author Stephen Colebourne
* @author Chris Webb
@@ -207,11 +209,11 @@
// sizing algorithm changes across the JDK versions
/**
- * An empty map, as JDK1.2 didn't have an empty map
+ * An empty codeMap/code, as JDK1.2 didn't have an empty map.
*/
private static final Map EMPTY_MAP = Collections.unmodifiableMap(new
HashMap(0));
/**
- * Map, key of class name, value of Entry.
+ * codeMap/code, key of class name, value of codeEntry/code.
*/
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/exception ExceptionUtils.java
bayard 2003/07/14 15:22:46
Modified:lang/src/java/org/apache/commons/lang/exception
ExceptionUtils.java
Log:
Javadoc fixes and a refactoring to use StringUtils.
Revision ChangesPath
1.25 +63 -54
jakarta-commons/lang/src/java/org/apache/commons/lang/exception/ExceptionUtils.java
Index: ExceptionUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/exception/ExceptionUtils.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ExceptionUtils.java 31 May 2003 17:16:11 - 1.24
+++ ExceptionUtils.java 14 Jul 2003 22:22:46 - 1.25
@@ -65,8 +65,8 @@
import java.util.LinkedList;
import java.util.List;
import java.util.StringTokenizer;
-
import org.apache.commons.lang.ArrayUtils;
+import org.apache.commons.lang.StringUtils;
import org.apache.commons.lang.SystemUtils;
/**
@@ -83,15 +83,16 @@
public class ExceptionUtils {
/**
- * Used when printing stack frames to denote the start of a
- * wrapped exception. Package private for accessibility by test
- * suite.
+ * pUsed when printing stack frames to denote the start of a
+ * wrapped exception./p
+ *
+ * pPackage private for accessibility by test suite./p
*/
static final String WRAPPED_MARKER = [wrapped] ;
/**
- * The names of methods commonly used to access a wrapped
- * exception.
+ * pThe names of methods commonly used to access a wrapped
+ * exception./p
*/
protected static String[] CAUSE_METHOD_NAMES = {
getCause,
@@ -105,8 +106,8 @@
};
/**
- * Constructs a new codeExceptionUtils/code. Protected to
- * discourage instantiation.
+ * pConstructs a new codeExceptionUtils/code. Protected to
+ * discourage instantiation./p
*/
protected ExceptionUtils() {
}
@@ -115,10 +116,11 @@
* pAdds to the list of method names used in the search for
codeThrowable/code
* objects./p
*
- * @param methodName the methodName to add to the list, null and empty strings
are ignored
+ * @param methodName the methodName to add to the list, codenull/code
+ * and empty strings are ignored
*/
public static void addCauseMethodName(String methodName) {
-if (methodName != null methodName.length() 0) {
+ if(StringUtils.isNotEmpty(methodName)) {
List list = new ArrayList(Arrays.asList(CAUSE_METHOD_NAMES));
list.add(methodName);
CAUSE_METHOD_NAMES = (String[]) list.toArray(new String[list.size()]);
@@ -132,17 +134,18 @@
* codeThrowable/code object. This will pick up most wrapping exceptions,
* including those from JDK 1.4, and
* [EMAIL PROTECTED] org.apache.commons.lang.exception.NestableException
NestableException}.
- * The method names can be added to using [EMAIL PROTECTED]
#addCauseMethodName(String)}.
- * The default list searched for are:/p
+ * The method names can be added to using [EMAIL PROTECTED]
#addCauseMethodName(String)}./p
+ *
+ * pThe default list searched for are:/p
* ul
- * licodegetCause()/code
- * licodegetNextException()/code
- * licodegetTargetException()/code
- * licodegetException()/code
- * licodegetSourceException()/code
- * licodegetRootCause()/code
- * licodegetCausedByException()/code
- * licodegetNested()/code
+ * licodegetCause()/code/li
+ * licodegetNextException()/code/li
+ * licodegetTargetException()/code/li
+ * licodegetException()/code/li
+ * licodegetSourceException()/code/li
+ * licodegetRootCause()/code/li
+ * licodegetCausedByException()/code/li
+ * licodegetNested()/code/li
* /ul
*
* pIn the absence of any such method, the object is inspected for a
@@ -152,7 +155,7 @@
*
* @param throwable The exception to introspect for a cause.
* @return The cause of the codeThrowable/code.
- * @throws NullPointerException if the throwable is null
+ * @throws NullPointerException if the throwable is codenull/code
*/
public static Throwable getCause(Throwable throwable) {
return getCause(throwable, CAUSE_METHOD_NAMES);
@@ -164,8 +167,9 @@
*
* @param throwable The exception to introspect for a cause.
* @return The cause of the codeThrowable/code.
- * @throws NullPointerException if the method names array is null or contains
null
- * @throws NullPointerException if the throwable is null
+ * @throws NullPointerException if the method names array is codenull/code
+ * or contains
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang StringUtilsTrimEmptyTest.java
scolebourne2003/07/14 15:26:22
Modified:lang/src/test/org/apache/commons/lang
StringUtilsTrimEmptyTest.java
Log:
Add and rework isEmpty, isNotEmpty, isEmptyTrimmed, isNotEmptyTrimmed
Revision ChangesPath
1.8 +25 -7
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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StringUtilsTrimEmptyTest.java 24 Mar 2003 00:47:02 - 1.7
+++ StringUtilsTrimEmptyTest.java 14 Jul 2003 22:26:22 - 1.8
@@ -132,18 +132,36 @@
assertEquals(, StringUtils.trimToEmpty(null));
}
+public void testIsEmpty() {
+assertEquals(false, StringUtils.isEmpty(foo));
+assertEquals(false, StringUtils.isEmpty( foo ));
+assertEquals(false, StringUtils.isEmpty( ));
+assertEquals(true, StringUtils.isEmpty());
+assertEquals(true, StringUtils.isEmpty(null));
+}
+
public void testIsNotEmpty() {
-assertEquals(true, StringUtils.isNotEmpty(FOO));
+assertEquals(true, StringUtils.isNotEmpty(foo));
+assertEquals(true, StringUtils.isNotEmpty( foo ));
assertEquals(true, StringUtils.isNotEmpty( ));
assertEquals(false, StringUtils.isNotEmpty());
assertEquals(false, StringUtils.isNotEmpty(null));
}
-public void testIsEmpty() {
-assertEquals(false, StringUtils.isEmpty(FOO));
-assertEquals(true, StringUtils.isEmpty( ));
-assertEquals(true, StringUtils.isEmpty());
-assertEquals(true, StringUtils.isEmpty(null));
+public void testIsEmptyTrimmed() {
+assertEquals(false, StringUtils.isEmptyTrimmed(foo));
+assertEquals(false, StringUtils.isEmptyTrimmed( foo ));
+assertEquals(true, StringUtils.isEmptyTrimmed( ));
+assertEquals(true, StringUtils.isEmptyTrimmed());
+assertEquals(true, StringUtils.isEmptyTrimmed(null));
+}
+
+public void testIsNotEmptyTrimmed() {
+assertEquals(true, StringUtils.isNotEmptyTrimmed(foo));
+assertEquals(true, StringUtils.isNotEmptyTrimmed( foo ));
+assertEquals(false, StringUtils.isNotEmptyTrimmed( ));
+assertEquals(false, StringUtils.isNotEmptyTrimmed());
+assertEquals(false, StringUtils.isNotEmptyTrimmed(null));
}
public void testDeleteSpace() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Javadocfixes and minor changes
On Sun, 13 Jul 2003, Alex Chaffee wrote: I also discovered some other issues while fixing the javadoc: - Several classes does test Strings on it own instead of using StringUtils.isEmpty() or StringUtils.isNotEmpty(), is that a deliberate design decision? Nope. The code could well use some refactoring to use StringUtils methods. Am applying these fixes. Enum.java and ExceptionUtils.java received these. A change was made to ReflectionUtils.java, which will not go in 2.0 but I've commited. - Alot of @parameter and @return javadoc is missing. Personally, I prefer JavaDoc tags to remain missing *unless* they add something relevant to the documentation. Since the JavaDoc utility automatically displays the name and type of all parameters and the return type, JavaDoc comments like this: * @param amt the amount are just documentation bugs waiting to happen. Since JavaDoc does not get compiled or refactored or unit tested, if someone changes the name of 'amt' to 'amount' without changing the comment then there's no way to tell. Better to just name your parameters meaningfully and skip the redundant comments. I agree quite a bit with Alex, I dislike javadoc for javadoc's sake. However, I'm also not adverse to someone putting in the work if they want and I'd hate to see Fredrik's patches go out of date and waste his time. As I've already pushed one batch in, finishing the job with the 2nd batch doesn't seem to make a lot of difference, so I've gone ahead and pushed in Fredrik's patch. Case in point: you used @parameter -- isn't the proper tag @param? :-) Only in conversation :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces
+1 from me too. I've mailed the Todd privately to see what he thinks [just in case he's not on the list anymore]. As we have the 3 +1's though, I've gone ahead and committed the change. Hen On Sat, 12 Jul 2003, Gary Gregory wrote: This seems like a good change at the 2.0 level. Obviously, this should be Javadoc'ed carefully and precisely. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, July 12, 2003 02:20 To: Jakarta Commons Developers List Subject: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces This got raised on the users list. Since this is a major version release, now would be the time to correct this problem. (ie. for 2.0) I propose: isEmpty() - CHANGE to not trim isNotEmpty() - no change isEmptyTrimmed - NEW, does what isEmpty used to isNotEmptyTrimmed - NEW This is an incompatable change for isEmpty(), but seems the best solution, as we appear to define 'empty' as elsewhere and refer to trimming explicitly. Stephen - Original Message - From: Todd Jonker [EMAIL PROTECTED] To: Jakarta Commons Users List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:10 AM Subject: Re: StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces In general, StringUtils seems to munge up the distinctions between null, zero-length, and whitespace-only strings. Obviously there is no concrete definition of what empty means. This makes the whole suite of related methods hard to learn, IMO. Personally, I think empty should mean zero-length or whitespace-only, but should not include null. You can't really say that your box is empty if you have no box at all. Another appropriate term would be blank. Perhaps a way to fix all this would be to deprecate the poorly-defined empty methods and replace them with well-defined blank methods. .T. On 6/25/03 8:13 AM, [EMAIL PROTECTED] wrote: I would tend to agree that it is inconsistent. I can't remember if isNotEmpty() was in release 1.0. If it was then changing it makes me uncomfortable. Stephen from:=?ISO-8859-1?Q?Reinhard_N=E4gele?= [EMAIL PROTECTED] date:Wed, 25 Jun 2003 11:02:57 to: [EMAIL PROTECTED] subject: Re: StringUtils.isEmpty(), isNotEmpty() and stringsa with some spaces This behavior is specified in the JavaDocs. However, I also think this is not really consistent. Any thoughts? Reinhard Dmitri Ilyin wrote: Hi, if is use isEmpty() method of StringUtils with (string with some spaces) and isNotEmpty() with the same string i get true from both methods, becouse isEmpty trims the parameter string and isNotEmpty doesn't. I think it is not OK. regards Dmitri - 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] -- A patriot must always be ready to defend his country against its government. -Edward Abbey, naturalist and author (1927-1989) Defend our country! Vote Howard Dean 2004 http://www.DeanForAmerica.com/ http://www.MoveOn.org/ - 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 stringsa with somespaces
*blush* So I was reading a blog while the test was running! I just got said conflict, then checked email. Will kill my code and update with yours. Hen On Mon, 14 Jul 2003, Stephen Colebourne wrote: No, you haven't committed this change, I have Did neither of us get a conflict? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, July 14, 2003 11:37 PM Subject: RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces +1 from me too. I've mailed the Todd privately to see what he thinks [just in case he's not on the list anymore]. As we have the 3 +1's though, I've gone ahead and committed the change. Hen On Sat, 12 Jul 2003, Gary Gregory wrote: This seems like a good change at the 2.0 level. Obviously, this should be Javadoc'ed carefully and precisely. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, July 12, 2003 02:20 To: Jakarta Commons Developers List Subject: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces This got raised on the users list. Since this is a major version release, now would be the time to correct this problem. (ie. for 2.0) I propose: isEmpty() - CHANGE to not trim isNotEmpty() - no change isEmptyTrimmed - NEW, does what isEmpty used to isNotEmptyTrimmed - NEW This is an incompatable change for isEmpty(), but seems the best solution, as we appear to define 'empty' as elsewhere and refer to trimming explicitly. Stephen - Original Message - From: Todd Jonker [EMAIL PROTECTED] To: Jakarta Commons Users List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:10 AM Subject: Re: StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces In general, StringUtils seems to munge up the distinctions between null, zero-length, and whitespace-only strings. Obviously there is no concrete definition of what empty means. This makes the whole suite of related methods hard to learn, IMO. Personally, I think empty should mean zero-length or whitespace-only, but should not include null. You can't really say that your box is empty if you have no box at all. Another appropriate term would be blank. Perhaps a way to fix all this would be to deprecate the poorly-defined empty methods and replace them with well-defined blank methods. .T. On 6/25/03 8:13 AM, [EMAIL PROTECTED] wrote: I would tend to agree that it is inconsistent. I can't remember if isNotEmpty() was in release 1.0. If it was then changing it makes me uncomfortable. Stephen from:=?ISO-8859-1?Q?Reinhard_N=E4gele?= [EMAIL PROTECTED] date:Wed, 25 Jun 2003 11:02:57 to: [EMAIL PROTECTED] subject: Re: StringUtils.isEmpty(), isNotEmpty() and stringsa with some spaces This behavior is specified in the JavaDocs. However, I also think this is not really consistent. Any thoughts? Reinhard Dmitri Ilyin wrote: Hi, if is use isEmpty() method of StringUtils with (string with some spaces) and isNotEmpty() with the same string i get true from both methods, becouse isEmpty trims the parameter string and isNotEmpty doesn't. I think it is not OK. regards Dmitri - 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] -- A patriot must always be ready to defend his country against its government. -Edward Abbey, naturalist and author (1927-1989) Defend our country! Vote Howard Dean 2004 http://www.DeanForAmerica.com/ http://www.MoveOn.org/ - 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
[lang] branching for a release
Any reason why I shouldn't go ahead and make the release branch so that development things can open up again in HEAD? I can't think of anything off-hand. The xdocs live in a different place, so aren't affected. Hen - 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/14 16:02:08 Modified:lang/src/java/org/apache/commons/lang StringUtils.java Log: Unify format of NOTE comments Revision ChangesPath 1.55 +7 -7 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.54 retrieving revision 1.55 diff -u -r1.54 -r1.55 --- StringUtils.java 14 Jul 2003 22:26:51 - 1.54 +++ StringUtils.java 14 Jul 2003 23:02:08 - 1.55 @@ -1005,9 +1005,9 @@ * otherwise leave it alone. A newline is quot;code\n/codequot;, * quot;code\r/codequot;, or quot;code\r\n/codequot;./p * - * pNote that this behavior has changed from 1.0. It - * now more closely matches Perl chomp. For the previous behavior, - * use [EMAIL PROTECTED] #slice(String)}./p + * pNOTE: This method changed in 2.0. + * It now more closely matches Perl chomp. + * For the previous behavior, use [EMAIL PROTECTED] #slice(String)}./p * * @param str String to chomp a newline from * @return String without newline @@ -1046,9 +1046,9 @@ * pRemove codeseparator/code from the end of * codestr/code if it's there, otherwise leave it alone./p * - * pNote that this behavior has changed from 1.0. It - * now more closely matches Perl chomp. For the previous behavior, - * use [EMAIL PROTECTED] #slice(String,String)}./p + * pNOTE: This method changed in version 2.0. + * It now more closely matches Perl chomp. + * For the previous behavior, use [EMAIL PROTECTED] #slice(String,String)}./p * * @param str string to chomp from * @param separator separator string - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/builder ReflectionToStringBuilder.java
scolebourne2003/07/14 16:02:27
Modified:lang/src/java/org/apache/commons/lang/builder
ReflectionToStringBuilder.java
Log:
Javadoc fix
Revision ChangesPath
1.3 +5 -5
jakarta-commons/lang/src/java/org/apache/commons/lang/builder/ReflectionToStringBuilder.java
Index: ReflectionToStringBuilder.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/builder/ReflectionToStringBuilder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ReflectionToStringBuilder.java14 Jul 2003 22:25:03 - 1.2
+++ ReflectionToStringBuilder.java14 Jul 2003 23:02:27 - 1.3
@@ -46,8 +46,8 @@
public class ReflectionToStringBuilder extends ToStringBuilder {
/**
- * A registry of objects used by codereflectionToString/code methods to
detect
- * cyclical object references and avoid infinite loops.
+ * pA registry of objects used by codereflectionToString/code methods
+ * to detect cyclical object references and avoid infinite loops./p
*/
private static ThreadLocal registry = new ThreadLocal() {
protected synchronized Object initialValue() {
@@ -79,8 +79,8 @@
}
/**
- * Registers the given object.
- * Used by the reflection methods to avoid infinite loops.
+ * pRegisters the given object.
+ * Used by the reflection methods to avoid infinite loops./p
*
* @param value The object to register.
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang STATUS.html
scolebourne2003/07/14 16:02:53 Modified:lang STATUS.html Log: Update task list Revision ChangesPath 1.42 +3 -2 jakarta-commons/lang/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/lang/STATUS.html,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- STATUS.html 8 Jul 2003 22:05:14 - 1.41 +++ STATUS.html 14 Jul 2003 23:02:53 - 1.42 @@ -136,12 +136,13 @@ liDateRange/Duration class/li liDurationFormatUtils to be completed and made public/li liCloneUtils - utility class to enable cloning via various different mechanisms. This code exists in [pattern] at present./li -liStringUtils unescape method - String Taglib has shown that this method is missing from StringUtils. It would take a String with \n in and convert it to the Java character. unescape and escape should be symmetric - [DONE. Test symmetry] /li liStringUtils.reverseSplit(String, String delim, int count). Should basically be a 'reverseArray(reverseDelimitedString(split(txt, delim, count)))/li liCharUtils - Utilities to work on a char[] in the same way as a String liAStringBuffer - A StringBuffer implementation with additional methods from StringUtils liO(n) - Document all algorithm-implementing methods with the order. Possibly with an O(n) on the end of each parameterm or with an @order tag./li liMoney and Currency/li +liCode examples - Document as many static methods as possible with example usage./li +liFaster StringTokeniser - Is Java's slow?/li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang RELEASE-NOTES.txt
scolebourne2003/07/14 16:03:27 Modified:lang RELEASE-NOTES.txt Log: Updated with isEmptyTrimmed/isNotEmptyTrimmed Revision ChangesPath 1.10 +11 -7 jakarta-commons/lang/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- RELEASE-NOTES.txt 12 Jul 2003 03:37:24 - 1.9 +++ RELEASE-NOTES.txt 14 Jul 2003 23:03:27 - 1.10 @@ -57,24 +57,26 @@ lang: CharSetUtils: - added: -keep method: keep any characters specified in the CharSet string +added keep method: keep any characters specified in the CharSet string RandomStringUtils: random method: overloaded to allow passing in of a Random class SerializationUtils: added empty constructor StringUtils: -defaultString method removed. -Nineteen new methods. Eight methods deprecated. +defaultString(String) method changed to defaultString(Object). +isEmpty() changed to not trim. +chomp() changed to be more like Perl. +Twenty-one new methods. +Eight methods deprecated. SystemUtils: -isJavaVersionAtLeast added. getJavaVersion deprecated. +isJavaVersionAtLeast(int) added. getJavaVersion() deprecated. host of new constants. enum: Enum: getEnumClass(Class) added EnumUtils: -Removed Comparable/Serializable interfaces. +Removed irrelevant Comparable/Serializable interfaces. exception: NestableDelegate: @@ -247,6 +249,8 @@ public static java.lang.String trimToNull(java.lang.String); public static java.lang.String trimToEmpty(java.lang.String); + public static boolean isEmptyTrimmed(java.lang.String); + public static boolean isNotEmptyTrimmed(java.lang.String); public static java.lang.String join(java.lang.Object[], char); public static java.lang.String join(java.util.Iterator, char); public static java.lang.String slice(java.lang.String); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] branching for a release
Do we need a release branch? Or is that just how things are done. Anyway, as far as I know all is ready for release. (You might just want to check the isEmpty changes I made tonight) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, July 14, 2003 11:58 PM Subject: [lang] branching for a release Any reason why I shouldn't go ahead and make the release branch so that development things can open up again in HEAD? I can't think of anything off-hand. The xdocs live in a different place, so aren't affected. 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]
Re: [lang] branching for a release
On Tue, 15 Jul 2003, Stephen Colebourne wrote: Do we need a release branch? Or is that just how things are done. It's how things are done. I'll go ahead and branch now and create a test-build from the branch. Anyway, as far as I know all is ready for release. (You might just want to check the isEmpty changes I made tonight) Have done already. You javadoc'd much more nicely than I :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie MalformedCookieException.java
mbecke 2003/07/14 19:19:59
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java HttpRecoverableException.java
MultiThreadedHttpConnectionManager.java
StatusLine.java HttpParser.java HttpException.java
httpclient/src/java/org/apache/commons/httpclient/methods
HeadMethod.java EntityEnclosingMethod.java
httpclient/src/java/org/apache/commons/httpclient/auth
NTLMScheme.java MalformedChallengeException.java
AuthenticationException.java NTLM.java
httpclient/src/java/org/apache/commons/httpclient/cookie
MalformedCookieException.java
Added: httpclient/src/java/org/apache/commons/httpclient
HttpTimeoutException.java TransportException.java
ProtocolException.java ConnectTimeoutException.java
IOTimeoutException.java
httpclient/src/test/org/apache/commons/httpclient
TestExceptions.java
Log:
Initial redesign of Exception framework.
PR: 19868
Submitted by: Laura Werner
Reviewed by: Oleg Kalnichevski, Adrian Sutton and Michael Becke
Revision ChangesPath
1.166 +14 -13
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.165
retrieving revision 1.166
diff -u -r1.165 -r1.166
--- HttpMethodBase.java 13 Jul 2003 13:54:50 - 1.165
+++ HttpMethodBase.java 15 Jul 2003 02:19:58 - 1.166
@@ -131,7 +131,7 @@
* @author a href=mailto:[EMAIL PROTECTED]dIon Gillard/a
* @author a href=mailto:[EMAIL PROTECTED]Jeff Dever/a
* @author a href=mailto:[EMAIL PROTECTED]Davanum Srinivas/a
- * @author Ortwin Glück
+ * @author Ortwin Gl�ck
* @author Eric Johnson
* @author Michael Becke
* @author a href=mailto:[EMAIL PROTECTED]Oleg Kalnichevski/a
@@ -984,10 +984,10 @@
throw new NullPointerException(HttpConnection parameter);
}
if (hasBeenUsed()) {
-throw new HttpException(Already used, but not recycled.);
+throw new IllegalStateException(Already used, but not recycled.);
}
if (!validate()) {
-throw new HttpException(Not valid);
+throw new ProtocolException(HttpMethodBase object not valid);
}
if (inExecute) {
throw new IllegalStateException(Execute invoked recursively, or exited
abnormally.);
@@ -1204,7 +1204,7 @@
String oldProtocol = currentUri.getScheme();
String newProtocol = redirectUri.getScheme();
if (!oldProtocol.equals(newProtocol)) {
-throw new HttpException(Redirect from protocol + oldProtocol
+throw new ProtocolException(Redirect from protocol + oldProtocol
+ to + newProtocol + is not supported);
}
@@ -1212,12 +1212,13 @@
String oldHost = currentUri.getHost();
String newHost = redirectUri.getHost();
if (!oldHost.equalsIgnoreCase(newHost)) {
-throw new HttpException(Redirect from host + oldHost
+// TODO: Add an HttpNotImplementedException or some such?
+throw new ProtocolException(Redirect from host + oldHost
+ to + newHost + is not supported);
}
} catch (URIException e) {
LOG.warn(Error getting URI host, e);
-throw new HttpException(Invalid Redirect URI from:
+throw new ProtocolException(Invalid Redirect URI from:
+ currentUri.getEscapedURI() + to: + redirectUri.getEscapedURI()
);
}
@@ -1231,7 +1232,7 @@
newPort = getDefaultPort(newProtocol);
}
if (oldPort != newPort) {
-throw new HttpException(Redirect from port + oldPort
+throw new ProtocolException(Redirect from port + oldPort
+ to + newPort + is not supported);
}
}
@@ -2064,7 +2065,7 @@
result = new ChunkedInputStream(is, this);
} else {
if (isStrictMode()) {
-throw new HttpException(Chunk-encoded body declared but
not sent);
+throw new ProtocolException(Chunk-encoded body declared
but not sent);
} else {
LOG.warn(Chunk-encoded body missing);
}
@@
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 Index: STATUS.html === RCS file: /home/cvspublic/jakarta-commons/lang/STATUS.html,v retrieving revision 1.42 diff -u -r1.42 STATUS.html --- STATUS.html 14 Jul 2003 23:02:53 - 1.42 +++ STATUS.html 15 Jul 2003 02:48:15 - @@ -68,7 +68,7 @@ listrongFraction/strong - A fraction./li listrongJVMRandom/strong - An implementation of Random that does its best to appear to sit on top of java.lang.Math's private Random class./li listrongNumberUtils/strong - Helper for java.lang.Number and its subclasses./li - listrongRange/strong - A range of numbers, of which there are classes representing Numbers, ints, doubles, longs and floats./li + listrongRange/strong - A range of numbers, of which there are classes representing Numbers, ints, doubles, longs and floats./li listrongRandomUtils/strong - A utility class for working with random numbers./li /ul/li @@ -133,14 +133,14 @@ pWant to help? Here's some to do items the team has identified as possibly being in scope for Lang. Note that all are still under discussion, so please mail the list before actioning./p ul liReflection utilities - work underway in reflect package./li -liDateRange/Duration class/li -liDurationFormatUtils to be completed and made public/li +liDateRange/Duration class./li +liDurationFormatUtils to be completed and made public./li liCloneUtils - utility class to enable cloning via various different mechanisms. This code exists in [pattern] at present./li -liStringUtils.reverseSplit(String, String delim, int count). Should basically be a 'reverseArray(reverseDelimitedString(split(txt, delim, count)))/li -liCharUtils - Utilities to work on a char[] in the same way as a String -liAStringBuffer - A StringBuffer implementation with additional methods from StringUtils +liStringUtils.reverseSplit(String, String delim, int count). Should basically be a 'reverseArray(reverseDelimitedString(split(txt, delim, count)))'./li +liCharUtils - Utilities to work on a char[] in the same way as a String./li +liAStringBuffer - A StringBuffer implementation with additional methods from StringUtils./li liO(n) - Document all algorithm-implementing methods with the order. Possibly with an O(n) on the end of each parameterm or with an @order tag./li -liMoney and Currency/li +liMoney and Currency./li liCode examples - Document as many static methods as possible with example usage./li liFaster StringTokeniser - Is Java's slow?/li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment Variance.java Mean.java FirstMoment.java
mdiggory2003/07/14 20:36:36
Modified:math/src/java/org/apache/commons/math/stat/univariate/moment
Variance.java Mean.java FirstMoment.java
Log:
minor javadoc cleanup
Revision ChangesPath
1.7 +10 -13
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/Variance.java
Index: Variance.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/Variance.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Variance.java 9 Jul 2003 20:04:10 - 1.6
+++ Variance.java 15 Jul 2003 03:36:36 - 1.7
@@ -53,13 +53,7 @@
*/
package org.apache.commons.math.stat.univariate.moment;
-import org
-.apache
-.commons
-.math
-.stat
-.univariate
-.AbstractStorelessUnivariateStatistic;
+import org.apache.commons.math.stat.univariate.AbstractStorelessUnivariateStatistic;
/**
*
@@ -84,7 +78,8 @@
this.moment = m2;
}
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#increment(double)
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#increment(double)
*/
public void increment(double d) {
if (incMoment) {
@@ -93,7 +88,8 @@
}
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#getValue()
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#getValue()
*/
public double getResult() {
if (n moment.n) {
@@ -111,7 +107,8 @@
}
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#clear()
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#clear()
*/
public void clear() {
if (incMoment) {
@@ -122,7 +119,6 @@
}
/*UnvariateStatistic Approach */
-
Mean mean = new Mean();
/**
@@ -140,7 +136,8 @@
* @param length processing at this point in the array
* @return the result, Double.NaN if no values for an empty array
* or 0.0 for a single value set.
- * @see
org.apache.commons.math.stat.univariate.UnivariateStatistic#evaluate(double[], int,
int)
+ * @see org.apache.commons.math.stat.univariate.
+ * UnivariateStatistic#evaluate(double[], int, int)
*/
public double evaluate(double[] values, int begin, int length) {
1.7 +7 -4
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/Mean.java
Index: Mean.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/Mean.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Mean.java 9 Jul 2003 20:04:10 - 1.6
+++ Mean.java 15 Jul 2003 03:36:36 - 1.7
@@ -53,6 +53,7 @@
*/
package org.apache.commons.math.stat.univariate.moment;
+import org.apache.commons.math.stat.univariate.AbstractStorelessUnivariateStatistic;
import org.apache.commons.math.stat.univariate.summary.Sum;
/**
@@ -60,7 +61,7 @@
* arithmetic mean /a of the available values.
* @version $Revision$ $Date$
*/
-public class Mean extends Sum {
+public class Mean extends AbstractStorelessUnivariateStatistic {
/** first moment of values that have been added */
protected FirstMoment moment = null;
@@ -100,6 +101,9 @@
public double getResult() {
return moment.m1;
}
+
+/*UnvariateStatistic Approach */
+Sum sum = new Sum();
/**
* Returns the a href=http://www.xycoon.com/arithmetic_mean.htm;
@@ -112,9 +116,8 @@
*/
public double evaluate(double[] values, int begin, int length) {
if (test(values, begin, length)) {
-return super.evaluate(values, begin, length) / ((double) length);
+return sum.evaluate(values) / ((double) length);
}
return Double.NaN;
}
-
}
1.5 +30 -18
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FirstMoment.java
Index: FirstMoment.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FirstMoment.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FirstMoment.java 9 Jul 2003 20:04:10 - 1.4
+++ FirstMoment.java 15 Jul 2003 03:36:36 - 1.5
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/summary Sum.java
mdiggory2003/07/14 20:37:11
Modified:math/src/java/org/apache/commons/math/stat/univariate
UnivariateStatistic.java
StorelessUnivariateStatistic.java
AbstractUnivariateStatistic.java
AbstractStorelessUnivariateStatistic.java
math/src/java/org/apache/commons/math/stat/univariate/summary
Sum.java
Added: math/src/java/org/apache/commons/math/stat/univariate
package.html
Log:
minor javadoc cleanup
Revision ChangesPath
1.5 +8 -5
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/UnivariateStatistic.java
Index: UnivariateStatistic.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/UnivariateStatistic.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- UnivariateStatistic.java 9 Jul 2003 20:04:13 - 1.4
+++ UnivariateStatistic.java 15 Jul 2003 03:37:10 - 1.5
@@ -55,7 +55,9 @@
/**
* UnivariateStatistic interface provides methods to evaluate
- * double[] based content using a particular algorithm.
+ * double[] based content using an implemented statistical approach.
+ * The interface provides two stateless simple methods to calculate
+ * a statistic from a double[] based parameter.
* @version $Revision$ $Date$
*/
public interface UnivariateStatistic {
@@ -66,16 +68,17 @@
* @return the result of the evaluation or Double.NaN
* if the array is empty
*/
-public double evaluate(double[] values);
+double evaluate(double[] values);
/**
- * Evaluates part of a double[] returning the result of the evaluation.
+ * Evaluates part of a double[] returning the result
+ * of the evaluation.
* @param values Is a double[] containing the values
* @param begin processing at this point in the array
* @param length processing at this point in the array
* @return the result of the evaluation or Double.NaN
* if the array is empty
*/
-public double evaluate(double[] values, int begin, int length);
+double evaluate(double[] values, int begin, int length);
}
1.6 +12 -10
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/StorelessUnivariateStatistic.java
Index: StorelessUnivariateStatistic.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/StorelessUnivariateStatistic.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- StorelessUnivariateStatistic.java 9 Jul 2003 20:04:13 - 1.5
+++ StorelessUnivariateStatistic.java 15 Jul 2003 03:37:10 - 1.6
@@ -54,12 +54,14 @@
package org.apache.commons.math.stat.univariate;
/**
- * StorelessUnivariate interface provides methods to increment and access
- * the internal state of the Statistic. A StorelessUnivariateStatistic does
- * not require that a double[] storage structure be maintained with the values
- * in it. As such only a subset of known statistics can actually be implmented
- * using it. If a Statistic cannot be implemented in a Storeless approach it
- * should implement the UnivariateStatistic interface directly instead.
+ * Extends the capabilities of UnivariateStatistic with a statefull incremental
+ * strategy through three methods for calculating a statistic without having to
+ * maintain a double[] of the values. Because a StorelessUnivariateStatistic
+ * does not require that a double[] storage structure be maintained with the
+ * values in it, there are only a subset of known statistics can actually be
+ * implemented using it. If a Statistic cannot be implemented in a Storeless
+ * approach it should implement the UnivariateStatistic interface directly
+ * instead.
* @version $Revision$ $Date$
*/
public interface StorelessUnivariateStatistic extends UnivariateStatistic {
@@ -69,7 +71,7 @@
* Implementation.
* @param d is the value to increment the state by.
*/
-public void increment(double d);
+void increment(double d);
/**
* Returns the current state of the statistic after the
@@ -77,12 +79,12 @@
* @return value of the statistic, Double.NaN if it
* has been cleared or just instantiated.
*/
-public double getResult();
+double getResult();
/**
* Clears all the internal state of the Statistic
*/
-public void clear();
+void clear();
}
1.5 +13 -7
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/summary Sum.java
mdiggory2003/07/14 20:38:50
Modified:math/src/java/org/apache/commons/math/stat/univariate/summary
Sum.java
Log:
minor javadoc cleanup
Revision ChangesPath
1.8 +10 -13
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/summary/Sum.java
Index: Sum.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/summary/Sum.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Sum.java 15 Jul 2003 03:37:11 - 1.7
+++ Sum.java 15 Jul 2003 03:38:50 - 1.8
@@ -53,14 +53,7 @@
*/
package org.apache.commons.math.stat.univariate.summary;
-import org.apache.commons.collections.primitives.DoubleIterator;
-import org
-.apache
-.commons
-.math
-.stat
-.univariate
-.AbstractStorelessUnivariateStatistic;
+import org.apache.commons.math.stat.univariate.AbstractStorelessUnivariateStatistic;
/**
* @version $Revision$ $Date$
@@ -73,7 +66,8 @@
private double value = Double.NaN;
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#increment(double)
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#increment(double)
*/
public void increment(double d) {
if (Double.isNaN(value)) {
@@ -84,14 +78,16 @@
}
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#getValue()
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#getValue()
*/
public double getResult() {
return value;
}
/**
- * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#clear()
+ * @see org.apache.commons.math.stat.univariate.
+ * StorelessUnivariateStatistic#clear()
*/
public void clear() {
value = Double.NaN;
@@ -103,7 +99,8 @@
* @param begin processing at this point in the array
* @param length processing at this point in the array
* @return the sum of the values or Double.NaN if the array is empty
- * @see
org.apache.commons.math.stat.univariate.UnivariateStatistic#evaluate(double[], int,
int)
+ * @see org.apache.commons.math.stat.univariate.
+ * UnivariateStatistic#evaluate(double[], int, int)
*/
public double evaluate(double[] values, int begin, int length) {
double sum = Double.NaN;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 09:27 --- We do not have to make it more complex than it needs to be. Looks good to me. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 12:42 --- Roland, you are right. UTF-8 is not backward compatible with Latin-1. Sorry about my misleading statement. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 12:51 --- HttpMethod.setQueryString(String) is definitely the way to use an encoding besides UTF-8. Oleg, perhaps we should try to expose HttpMethodBase.formUrlEncode(). This would make it quite easy for someone to use another encoding if necessary. If we decide to do this I think formUrlEncode() should probably be moved. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 18:48 --- I agree. How about URIUtil#formUrlEncode? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 19:10 --- Possibly. It's not really URI related, but it's our only real choice unless we want to add a new class. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 19:16 --- Actually, a completely new utility class does not seem to be such a bad idea at all. Anyways, I leave it to your discretion. 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-14 19:19 --- Adrian, I do not why, but I LOVE nested exceptions. Probably it is due to the stigma of having dealt a lot with EJBs. I remember those days of misery when Websphere App Server 4.0.x used to print a completely useless stack trace of EJBException without giving me even a hint at what had caused the EJBException in the first place. The day the problem was fixed with one of the WAS service releases was one of the happiest days in my life. Regardless of what one may think of nestable exceptions, Laura's patch is a step in the right direction. I think we should apply the patch and address remaining concerned through a series of incremental patches - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 19:35 --- Okay, I think we should opt for a new class. Any thoughts on a name? I would like to pick something that we can actually reuse for other utility methods in the future. Something really generic like HttpClientUtil perhaps? We could go more specific and have an EncodingUtil. What do you like? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 19:40 --- HttpClientUtil is too close to being AllSortsOfStuffUtil IMO. I like EncodingUtil better. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-14 20:21 --- EncodingUtil it is. I will take care of it tonight. Mike - 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-14 23:00 --- Oleg, Agreed there are definitely times where nested exceptions are better. I guess my main question has come down to: how is HttpTransportException() different and better than IOException? My understanding of IOException is that it's thrown when communication goes wrong, which is the same as my understanding of HttpTransportException. For the record I definitely agree we should nest exceptions like JSSE and crypto exceptions as well as other exceptions that are very much internal to how HttpClient works. I'm just not sure that TransportException either shields the user from the internals of HttpClient or provides additional information that may be useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
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=20481. 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=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-07-15 01:36 --- Okay. Here it is. Please take a look and let me know what you think. - 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-15 02:22 --- Patch committed. Nice work Laura. Mike - 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-15 04:06 --- I just noticed that my patch mangled some comments in HeadMethod.java. They had a long of row non-ASCII characters (a bullet, I think), which got messed up because I had Eclipse set to Cp1252 instead of Latin-1. Here's a patch - 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-15 04:06 --- Created an attachment (id=7298) Fix mangled comments in HeadMethod.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
