DO NOT REPLY [Bug 33873] New: - Named stacks are not popped at end of processing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33873 Summary: Named stacks are not popped at end of processing Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P4 Component: Digester AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The method org.apache.commons.digester.Digester.endDocument() pops the main stack in a loop, but does not perform the same operation on stacksByName. This is inconsistent, and may result in an ever-growing stack if a Digester instance is cached and reused (notwithstanding documentation that Digester instances should not be reused anyway). An alternative to clearing stacksByName in endDocument() would be to do so in clear(). It also would be more consistent (and useful) to have a method public Object peek(String stackName, int n); -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r156409 - jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java
Author: skitching
Date: Mon Mar 7 00:59:28 2005
New Revision: 156409
URL: http://svn.apache.org/viewcvs?view=revrev=156409
Log:
* Add facility for user to override the default set of true and false string
definitions.
* provide NO_DEFAULT object that can be passed to constructors to indicate that
no default
object is desired.
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java?view=diffr1=156408r2=156409
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanConverter.java
Mon Mar 7 00:59:28 2005
@@ -1,5 +1,5 @@
/*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -17,7 +17,6 @@
package org.apache.commons.beanutils.converters;
-
import org.apache.commons.beanutils.ConversionException;
import org.apache.commons.beanutils.Converter;
@@ -28,6 +27,27 @@
* default value or throwing a [EMAIL PROTECTED] ConversionException} if a
conversion
* error occurs./p
*
+ * pBy default any object whose string representation is one of the values
+ * {yes, y, true, on, 1} is converted to Boolean.TRUE, and
+ * string representations {no, n, false, off, 0} are converted
+ * to Boolean.FALSE. The recognised true/false strings can be changed by:
+ * pre
+ * String[] trueStrings = {oui, o, 1};
+ * String[] falseStrings = {non, n, 0};
+ * Converter bc = new BooleanConverter(trueStrings, falseStrings);
+ * ConvertUtils.register(bc, Boolean.class);
+ * ConvertUtils.register(bc, Boolean.TYPE);
+ * /pre
+ * In addition, it is recommended that the BooleanArrayConverter also be
+ * modified to recognise the same set of values:
+ * pre
+ * Converter bac = new BooleanArrayConverter(bc,
BooleanArrayConverter.NO_DEFAULT);
+ * ConvertUtils.register(bac, bac.MODEL);
+ * /pre
+ * /p
+ *
+ * pCase is ignored when converting values to true or false./p
+ *
* @author Craig R. McClanahan
* @version $Revision$ $Date$
* @since 1.3
@@ -41,11 +61,11 @@
/**
* Create a [EMAIL PROTECTED] Converter} that will throw a [EMAIL
PROTECTED] ConversionException}
- * if a conversion error occurs.
+ * if a conversion error occurs, ie the string value being converted is
+ * not one of the known true strings, nor one of the known false strings.
*/
public BooleanConverter() {
-this.defaultValue = null;
this.useDefault = false;
}
@@ -53,45 +73,121 @@
/**
* Create a [EMAIL PROTECTED] Converter} that will return the specified
default value
- * if a conversion error occurs.
+ * if a conversion error occurs, ie the string value being converted is
+ * not one of the known true strings, nor one of the known false strings.
*
- * @param defaultValue The default value to be returned
+ * @param defaultValue The default value to be returned if the value
+ * being converted is not recognised. This value may be null, in which
+ * case null will be returned on conversion failure. When non-null, it is
+ * expected that this value will be either Boolean.TRUE or Boolean.FALSE.
+ * The special value BooleanConverter.NO_DEFAULT can also be passed here,
+ * in which case this constructor acts like the no-argument one.
*/
public BooleanConverter(Object defaultValue) {
-this.defaultValue = defaultValue;
-this.useDefault = true;
+if (defaultValue == NO_DEFAULT) {
+this.useDefault = false;
+} else {
+this.defaultValue = defaultValue;
+this.useDefault = true;
+}
+
+}
+
+/**
+ * Create a [EMAIL PROTECTED] Converter} that will return the specified
default value
+ * if a conversion error occurs.
+ * p
+ * The provided string arrays are copied, so that changes to the elements
+ * of the array after this call is made do not affect this object.
+ *
+ * @param trueStrings is the set of strings which should convert to the
+ * value Boolean.TRUE. The value null must not be present. Case is
+ * ignored.
+ *
+ * @param falseStrings is the set of strings which should convert to the
+ * value Boolean.TRUE. The value null must not be present. Case is
+ * ignored.
+ *
+ * @param defaultValue The
svn commit: r156410 - jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
Author: skitching
Date: Mon Mar 7 01:07:52 2005
New Revision: 156410
URL: http://svn.apache.org/viewcvs?view=revrev=156410
Log:
* Use new AbstractArrayConverter constructors rather than manually
setting inherited members.
* Convert strings to booleans by invoking a BooleanConverter rather
than hard-wiring the conversion in this class. Together with a
new constructor that takes a BooleanConverter instance, this
allows users to take advantage of the new configurability of the
BooleanConverter class.
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java?view=diffr1=156409r2=156410
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
Mon Mar 7 01:07:52 2005
@@ -29,6 +29,11 @@
* a specified default value or throws a [EMAIL PROTECTED]
ConversionException} depending
* on how this instance is constructed./p
*
+ * pBy default, the values to be converted are expected to be those
+ * recognised by a default instance of BooleanConverter. A customised
+ * BooleanConverter can be provided in order to recognise alternative values
+ * as true/false. /p
+ *
* @author Craig R. McClanahan
* @version $Revision$ $Date$
* @since 1.4
@@ -43,11 +48,14 @@
/**
* Create a [EMAIL PROTECTED] Converter} that will throw a [EMAIL
PROTECTED] ConversionException}
* if a conversion error occurs.
+ *
+ * pConversion of strings to boolean values will be done via a default
+ * instance of class BooleanConverter./p
*/
public BooleanArrayConverter() {
-this.defaultValue = null;
-this.useDefault = false;
+super();
+this.booleanConverter = dfltBooleanConverter;
}
@@ -56,37 +64,118 @@
* Create a [EMAIL PROTECTED] Converter} that will return the specified
default value
* if a conversion error occurs.
*
+ * pConversion of strings to boolean values will be done via a default
+ * instance of class BooleanConverter./p
+ *
* @param defaultValue The default value to be returned
*/
public BooleanArrayConverter(Object defaultValue) {
-this.defaultValue = defaultValue;
-this.useDefault = true;
+super(defaultValue);
+this.booleanConverter = dfltBooleanConverter;
}
+/**
+ * Create a [EMAIL PROTECTED] Converter} that will return the specified
default value
+ * if a conversion error occurs.
+ *
+ * pConversion of strings to boolean values will be done via the
+ * specified converter./p
+ *
+ * @param converter is the converter object that will be used to
+ * convert each input string-value into a boolean.
+ *
+ * @param defaultValue is the default value to be returned by method
+ * convert if conversion fails; null is a valid default value. See the
+ * documentation for method convert for more information.
+ * The value BooleanArrayConverter.NO_DEFAULT may be passed here to
+ * specify that an exception should be thrown on conversion failure.
+ *
+ */
+public BooleanArrayConverter(BooleanConverter converter, Object
defaultValue) {
+
+super(defaultValue);
+this.booleanConverter = converter;
+
+}
+
// --- Static Variables
+/**
+ * Type which this class converts its input to. This value can be
+ * used as a parameter to the ConvertUtils.register method.
+ */
+public static final Class MODEL = new boolean[0].getClass();
/**
- * pModel object for type comparisons./p
+ * The converter that all instances of this class will use to
+ * do individual string-boolean conversions, unless overridden
+ * in the constructor.
*/
-private static boolean model[] = new boolean[0];
+private static final BooleanConverter dfltBooleanConverter
+= new BooleanConverter();
+
+// Instance Variables
+/**
+ * This object is used to perform the conversion of individual strings
+ * into Boolean/boolean values.
+ */
+protected final BooleanConverter booleanConverter;
// - Public Methods
/**
- * Convert the specified input object into an output object of the
- * specified type.
+ * Convert the
svn commit: r156411 - jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanConverterTestCase.java
Author: skitching
Date: Mon Mar 7 01:12:37 2005
New Revision: 156411
URL: http://svn.apache.org/viewcvs?view=revrev=156411
Log:
Test cases. Much of this code (and the recent changes to make BooleanConverter
configurable)
were provided by Eric Rizzo.
Added:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java
(with props)
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanConverterTestCase.java
(with props)
Added:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java?view=autorev=156411
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java
(added)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java
Mon Mar 7 01:12:37 2005
@@ -0,0 +1,271 @@
+/*
+ * Copyright 2005 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.beanutils.converters;
+
+import org.apache.commons.beanutils.ConvertUtils;
+import org.apache.commons.beanutils.ConversionException;
+
+import junit.framework.TestCase;
+
+/**
+ * Test conversions of String[]-boolean[] and String-boolean[].
+ *
+ * pNote that the tests here don't rigorously test conversions of individual
+ * strings to booleans, as the BooleanArrayConverter class uses a
+ * BooleanConverter instance to do those conversions, and the BooleanConverter
+ * class has its own unit tests. Here, the tests focus on the array-related
+ * behaviour./p
+ */
+public class BooleanArrayConverterTestCase extends TestCase {
+
+public static final String[] STANDARD_TRUES = new String[] {
+yes, y, true, on, 1
+};
+
+public static final String[] STANDARD_FALSES = new String[] {
+no, n, false, off, 0
+};
+
+
+public BooleanArrayConverterTestCase(String name) {
+super(name);
+}
+
+/**
+ * Check that an object of type String[] with valid boolean string
+ * values gets converted nicely.
+ */
+public void testStandardStringArrayConversion() {
+String[] values = {
+true, false,
+yes, no,
+y, n,
+1, 0,
+};
+
+BooleanArrayConverter converter = new BooleanArrayConverter();
+boolean[] results = (boolean[]) converter.convert(null, values);
+
+assertNotNull(results);
+assertEquals(8, results.length);
+assertTrue(results[0]);
+assertFalse(results[1]);
+assertTrue(results[2]);
+assertFalse(results[3]);
+assertTrue(results[4]);
+assertFalse(results[5]);
+assertTrue(results[6]);
+assertFalse(results[7]);
+}
+
+/**
+ * Check that an object whose toString method returns a list of boolean
+ * values gets converted nicely.
+ */
+public void testStandardStringConversion() {
+BooleanArrayConverter converter = new BooleanArrayConverter();
+
+StringBuffer input = new StringBuffer();
+boolean[] results;
+
+// string has {}
+input.setLength(0);
+input.append({true, 'yes', Y, 1, 'FALSE', \no\, 'n', 0});
+results = (boolean[]) converter.convert(null, input);
+
+assertNotNull(results);
+assertEquals(8, results.length);
+assertTrue(results[0]);
+assertTrue(results[1]);
+assertTrue(results[2]);
+assertTrue(results[3]);
+assertFalse(results[4]);
+assertFalse(results[5]);
+assertFalse(results[6]);
+assertFalse(results[7]);
+
+// string does not have {}
+input.setLength(0);
+input.append('falsE', 'no', 'N', 0, \truE\, yeS, 'y', '1');
+results = (boolean[]) converter.convert(null, input);
+
+assertNotNull(results);
+assertEquals(8, results.length);
+assertFalse(results[0]);
+assertFalse(results[1]);
+assertFalse(results[2]);
+assertFalse(results[3]);
+assertTrue(results[4]);
+
DO NOT REPLY [Bug 18942] - [beanutils] Add t/f to BooleanConverter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18942 --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 10:26 --- Hi All, I've just committed some code based on the patch I attached earlier. I would appreciate it if you could have a look and let me know whether it meets your requirements. Thanks, Simon PS: Matthias, o.a.c.collections.FastHashMap is flawed. The javadoc contains this comment: quoteThis class is not cross-platform. Using it may cause unexpected failures on some architectures./quote -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33872] - [configuration] API Javadoc not in sync with jar nor with source code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33872. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33872 [EMAIL PROTECTED] changed: What|Removed |Added Summary|API Javadoc not in sync with|[configuration] API Javadoc |jar nor with source code|not in sync with jar nor ||with source code -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33873] - [digester] Named stacks are not popped at end of processing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33873 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Named stacks are not popped |[digester] Named stacks are |at end of processing|not popped at end of ||processing -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r156414 - in jakarta/commons/proper/digester/trunk/src: java/org/apache/commons/digester/Digester.java test/org/apache/commons/digester/DigesterTestCase.java
Author: skitching
Date: Mon Mar 7 02:12:40 2005
New Revision: 156414
URL: http://svn.apache.org/viewcvs?view=revrev=156414
Log:
* remove redundant code to clear object stack (this is done again in clear
method)
* ensure named stacks are cleared too.
* add method peek(StackName, int n) for consistency
Thanks to Brian Hanafee for the suggestion (bugzilla #33873)
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/DigesterTestCase.java
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java?view=diffr1=156413r2=156414
==
---
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
Mon Mar 7 02:12:40 2005
@@ -962,10 +962,6 @@
}
}
-while (getCount() 1) {
-pop();
-}
-
// Fire finish events for all defined rules
Iterator rules = getRules().rules().iterator();
while (rules.hasNext()) {
@@ -2419,6 +2415,7 @@
params.clear();
publicId = null;
stack.clear();
+stacksByName.clear();
}
@@ -2550,6 +2547,25 @@
* @since 1.6
*/
public Object peek(String stackName) {
+return peek(stackName, 0);
+}
+
+/**
+ * pGets the top object from the stack with the given name.
+ * This method does not remove the object from the stack.
+ * /p
+ * pstrongNote:/strong a stack is considered empty
+ * if no objects have been pushed onto it yet./p
+ *
+ * @param stackName the name of the stack to be peeked
+ * @param n Index of the desired element, where 0 is the top of the stack,
+ * 1 is the next element down, and so on.
+ * @return the specified codeObject/code on the stack.
+ * @throws EmptyStackException if the named stack is empty
+ *
+ * @since 1.6
+ */
+public Object peek(String stackName, int n) {
Object result = null;
ArrayStack namedStack = (ArrayStack) stacksByName.get(stackName);
if (namedStack == null ) {
@@ -2560,7 +2576,7 @@
} else {
-result = namedStack.peek();
+result = namedStack.peek(n);
}
return result;
}
Modified:
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/DigesterTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/DigesterTestCase.java?view=diffr1=156413r2=156414
==
---
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/DigesterTestCase.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/DigesterTestCase.java
Mon Mar 7 02:12:40 2005
@@ -393,6 +393,31 @@
assertEquals(Peeked value:, archimedesAveragePi,
digester.peek(testStackName));
assertEquals(Popped value:, archimedesAveragePi,
digester.pop(testStackName));
assertTrue(Stack ends empty:, digester.isEmpty(testStackName));
+
+digester.push(testStackName, 1);
+digester.push(testStackName, 2);
+digester.push(testStackName, 3);
+
+assertEquals(Peek#1, 1, digester.peek(testStackName, 2));
+assertEquals(Peek#2, 2, digester.peek(testStackName, 1));
+assertEquals(Peek#3, 3, digester.peek(testStackName, 0));
+assertEquals(Peek#3a, 3, digester.peek(testStackName));
+
+try {
+// peek beyond stack
+digester.peek(testStackName, 3);
+fail(Peek#4 failed to throw an exception.);
+} catch(EmptyStackException ex) {
+// ok, expected
+}
+
+try {
+// peek a nonexistent named stack
+digester.peek(no.such.stack, 0);
+fail(Peeking a non-existent stack failed to throw an exception.);
+} catch(EmptyStackException ex) {
+// ok, expected
+}
}
/** Tests that values are stored independently */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33873] - [digester] Named stacks are not popped at end of processing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33873 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 11:13 --- Thanks for the suggestion Brian. The change has been committed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 12 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-07032005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07032005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07032005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07032005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-07032005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to
Re: [lang] 2.1 rc (practice)
I am not sure if we've laid out how we are going to build the release versions of [lang], but here is my recommendation: For other projects I do, I build the jar file, source and binary dists using ant. I do this using an old JDK (1.3, although perhaps it should even be 1.2). I also use this same jar file to upload to ibiblio. I do NOT use maven - it uses the wrong JDK and I don't trust it enough. I DO use maven for building the website, which I do with JDK 1.4/1.5. After doing maven site, I copy the javadoc to a new directory api-2.1. Only then do I do maven site:sshdeploy. On the server, I manually link api-release to api-2.1. The navigation.xml file contains hyperlinks to api-release to refer to the release docs, and apidocs to refer to the latest CVS javadoc (which will be the same just after a release). Thus the server contains: root - apidocs - CVS latest javadoc - api-2.0 - javadoc of 2.0 (copy on server before upload) - api-2.1 - javadoc of 2.1 (upload with maven in release) - api-release - link to api-2.1 And ALL jar files are produced by ant under JDK1.3 (or 1.2) Stephen --- Henri Yandell [EMAIL PROTECTED] wrote: 3) the binary dist is fat. The 2.0 binary tarball was under 500k and the 2.1 candidate is over 2MB. This is all due to the site stuff. Might be better to turn off some / most of the maven project reports (esp. the xref reports) and drop some of the maven image / logo cruft. For the latter, have a look at the maven.xml for directory-naming. Could be this (ability to prevent unused images/logos from being copied out) is now available in the latest maven xdoc plugin. Nasty. I'm -0 to the whole placing of the site in the dists. Seems like a waste of bandwidth. Documentation should be in there, but a site != documentation (maven's fault, though other non-maven places do exactly the same thing) and much of the documentation is hardly pertinent (source xref's?). I can see some argument for it being in th src dists, but we don't even have it there. Is there anything other than javadoc that should be there? The userguide is the only thing that jumps to mind, but it's incomplete. Only -0 because I'll never have to download the dists. I'll be using the ibiblio .jar file and the online javadoc (until they get overwritten by the latest from HEAD, which is a well known grumble for another time). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1 rc (practice)
On Mon, 7 Mar 2005 14:08:48 + (GMT), Stephen Colebourne [EMAIL PROTECTED] wrote: I am not sure if we've laid out how we are going to build the release versions of [lang], but here is my recommendation: For other projects I do, I build the jar file, source and binary dists using ant. I do this using an old JDK (1.3, although perhaps it should even be 1.2). I also use this same jar file to upload to ibiblio. I do NOT use maven - it uses the wrong JDK and I don't trust it enough. How can it use the wrong JDK? Is Maven 1.4+ nowadays or something? I've always used Maven on Commons projects (when mavenized) because I don't have to worry about whether the custom Ant script is sufficiently customised (or evne up to date as most are generated from Maven). Afaik, only Collections still used a custom Ant file. I DO use maven for building the website, which I do with JDK 1.4/1.5. After doing maven site, I copy the javadoc to a new directory api-2.1. Only then do I do maven site:sshdeploy. Interesting :) I distrust the site:sshdeploy and instead I zip the docs up and scp them manually to the server. I'll let maven create binaries, but I'm loathe to generate docs to production from any system, be it Ant or Maven. The main reason why I've not deployed the site in recent times, goes against the grain. On the server, I manually link api-release to api-2.1. The navigation.xml file contains hyperlinks to api-release to refer to the release docs, and apidocs to refer to the latest CVS javadoc (which will be the same just after a release). I'd prefer to separate this concept completely. Have a completely seperate way of storing and managing the javadoc, maybe even go as far as to check said javadoc into the repository (not necessarily inside Lang), or just copying the docs/apidocs over to an official place, rather than inside Lang. But that's an idea I've not tried out before, an unzipped javadoc repository, in the same way we have a java repository, which will make it easy to ensure we keep released javadoc available. Thus the server contains: root - apidocs - CVS latest javadoc - api-2.0 - javadoc of 2.0 (copy on server before upload) - api-2.1 - javadoc of 2.1 (upload with maven in release) - api-release - link to api-2.1 And ALL jar files are produced by ant under JDK1.3 (or 1.2) No great difference on the result, just completely different path on how to get there :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
On Mon, March 7, 2005 2:21 am, Henri Yandell said:
Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)
I can certainly appreciate that :)
On the larger ideas (DateRange class), I'd imagine an API of:
// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }
Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.
To me, the part about mimicing the API makes some sense (so long as there
is an overload version that accepts a Calendar so that my use case is
handled too!). The part about extending math.Range (which I realize you
say you aren't sure about) I wouldn't like. It doesn't feel like it
really applies properly, a bit of a square peg in a round hole if you
will. I think the API is the part that really matters though.
I'm not entirely clear on why there are three parameters when constucting
the DateRange though... Seems like a range by definition should only
require two items, no? :)
Given the criteria above, at least an API of:
DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)
It's the 2,358 number I dislike :)
I can live with that :)
We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.
Also not a problem for me. However, I would think it would be better to
create another overloaded version to accept a Date rather than replacing
it. I still think there are cases where the base int-only version will
come in handy, and I'd hate to see if removed. I think all overloaded
versions callind on the int-only version is the most flexible model
anyway... I can't imagine an overloaded version I'd rally against :)
Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.
Not a bad thought, but I would make an argument that as an application
developer, I'm not sure I'd be thrilled with having to use something other
than JDK standard classes (even though, to me anyway, its a bit bizarre in
the first place to have to use a Date or Calendar when I'm just dealing
with times). I suppose as long as it was easy to get a Time instance
based off of any of these, i.e., Time t = new Time(calendar); Time t = new
Time(date); ... and so on... then I'd be happy with that. I could see
using that myself.
The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.
That's a good thought, I didn't think of doing it that way. Certainly, if
I could let the standard JDK classes handle the conversion, then cool.
Plus, it should be able to handle just about any format one throws at it,
so that's certainly worth doing. In any case, I can't imagine it would
effect performance any more than the current implementation probably does
:)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18942] - [beanutils] Add t/f to BooleanConverter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18942 --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 15:57 --- (In reply to comment #24) Hi All, I've just committed some code based on the patch I attached earlier. I would appreciate it if you could have a look and let me know whether it meets your requirements. Don't see it on HEAD - did you commit it on a branch? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] questions about various servlet/*Mapper classes
Thanks for the info about Digester. This makes life easier. The Mapper's just need to get the catalog from the CatalogFactory. I'll send in patches. Howard On Sun, 6 Mar 2005 12:02:32 -0600, Joe Germuska [EMAIL PROTECTED] wrote: Command methods like setCatalogKey are generally intended to be set during configuration bootstrap time, for example, by the Digester process that reads in an XML file... command className=...ServletPathMapper catalogKey=catalog / As for your other comments... to be honest, I've been too busy to consider them very carefully, and I think part of my problem is that I have never even considered using the ChainServlet classes. Do you have a suggestion for a fix for the code base so that in the next release, it will be more practically usable? Thanks, Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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]
[net] NTP + Time test code not in CVS branch
In the latest build of Net commons it appears that the contributed Ntp + Time junit tests got dropped. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 Test classes in question: Directory of C:\net\src\test\org\apache\commons\net\ntp 10/08/2003 09:56 AM 5,876 TimeStampTest.java Directory of C:\net\src\test\org\apache\commons\net\time 10/08/2003 09:57 AM 6,021 TimeTCPClientTest.java 09/26/2003 08:35 AM 6,332 TimeTestSimpleServer.java -- Jason Mathews [EMAIL PROTECTED] The MITRE Corporation http://www.mitre.org/ Bedford, MA 01730-1407 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] PATCH: Add CollectionContainsPredicate...
All,
This patch adds a class called CollectionContainsPredicate to the functors
package and adds a method to PredicateUtils for constructing one. A
CollectionContains predicate takes a Collection in its constructor and
returns true if the input object is in the collection. I thought this might
be a nice addition. I couldn't find anything like this in the API, so I had
to write it today for something I was doing at work.
James
Index: src/java/org/apache/commons/collections/PredicateUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/PredicateUtils.java,v
retrieving revision 1.19
diff -u -r1.19 PredicateUtils.java
--- src/java/org/apache/commons/collections/PredicateUtils.java 26 May 2004
21:50:52 - 1.19
+++ src/java/org/apache/commons/collections/PredicateUtils.java 7 Mar 2005
20:12:50 -
@@ -20,6 +20,7 @@
import org.apache.commons.collections.functors.AllPredicate;
import org.apache.commons.collections.functors.AndPredicate;
import org.apache.commons.collections.functors.AnyPredicate;
+import org.apache.commons.collections.functors.CollectionContainsPredicate;
import org.apache.commons.collections.functors.EqualPredicate;
import org.apache.commons.collections.functors.ExceptionPredicate;
import org.apache.commons.collections.functors.FalsePredicate;
@@ -62,6 +63,7 @@
* liException - always throws an exception
* liNullIsException/NullIsFalse/NullIsTrue - check for null input
* liTransformed - transforms the input before calling the predicate
+ * liCollection Contains - true if the input is in a collection
* /ul
* All the supplied predicates are Serializable.
*
@@ -532,4 +534,12 @@
return TransformedPredicate.getInstance(transformer, predicate);
}
+/**
+ * Creates a predicate that returns true if the input object is in
codecollection/code.
+ * @param collection the collection
+ * @return the predicate
+ */
+public static Predicate collectionContainsPredicate( Collection collection
) {
+return new CollectionContainsPredicate( collection );
+}
}
Index:
src/java/org/apache/commons/collections/functors/CollectionContainsPredicate.java
===
RCS file:
src/java/org/apache/commons/collections/functors/CollectionContainsPredicate.java
diff -N
src/java/org/apache/commons/collections/functors/CollectionContainsPredicate.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++
src/java/org/apache/commons/collections/functors/CollectionContainsPredicate.java
7 Mar 2005 20:12:50 -
@@ -0,0 +1,49 @@
+/*
+ * Copyright 2001-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.collections.functors;
+
+import java.util.Collection;
+import java.util.Collections;
+
+import org.apache.commons.collections.Predicate;
+
+/**
+ * Predicate implementation that returns true if the input is contained in a
collection.
+ * @author James Carman
+ */
+public class CollectionContainsPredicate implements Predicate
+{
+private final Collection collection;
+
+/**
+ * Creates a codeCollectionContainsPredicate/code for the
+ * supplied collection.
+ * @param collection the collection
+ */
+public CollectionContainsPredicate(final Collection collection)
+{
+this.collection = collection == null ? Collections.EMPTY_SET :
collection;
+}
+
+/**
+ * Returns true if the collection contains the object.
+ * @param object the object
+ */
+public boolean evaluate(Object object)
+{
+return collection.contains( object );
+}
+}
Index: src/test/org/apache/commons/collections/TestPredicateUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestPredicateUtils.java,v
retrieving revision 1.8
diff -u -r1.8 TestPredicateUtils.java
--- src/test/org/apache/commons/collections/TestPredicateUtils.java 13 Mar
2004 16:34:46 - 1.8
+++ src/test/org/apache/commons/collections/TestPredicateUtils.java 7 Mar
2005 20:12:51 -
@@ -19,6 +19,7 @@
import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
+import java.util.HashSet;
import java.util.List;
import java.util.Map;
@@
Re: [ANN][configuration]Release candidate 1.1RC2
Phil, thanks for your feedback. Some comments inline. Phil Steitz wrote: Looks good to me. I checked the sigs (using http://www.apache.org/dist/jakarta/commons/configuration/KEYS) and hashes and all worked, though the md5 files include trailing cr/lf that caused my script to choke. Next time I will generate the md5s on Cygwin or linux. One small nit: NOTICE.txt is missing from source and binary distros and jar. Not sure about this. I used maven dist to build the distros. Do I have to tweak the maven.xml so that this file gets included? Some test cases generate error messages to standard error when I run ant clean test though the build succeeds. Don't know if this is a problem or not. It does not look like any test cases actually fail. I suppose those tests check if exceptions are thrown and then log the message to stderr. It would surely be better to get rid off this output, it might be confusing. But the tests definitely pass. Phil Thanks again. Oliver Oliver Heger wrote: In preparation for a 1.1 release of commons-configuration I have created the second release candidate. The files are available for inspection at http://www.apache.org/~oheger/commons-configuration-1.1rc2 The name of the tag is CONFIGURATION_1_1RC2. The release notes (in form of the changes report) can be found at http://jakarta.apache.org/commons/configuration/changes-report.html Comments are welcome! Thanks, Oliver - 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]
[vfs] parsing uri
In DefaultLocalFileProvider is a method findLocalFile.
It's idea is to convert File object into FileObject object.
public FileObject findLocalFile(final File file)
throws FileSystemException
{
// TODO - tidy this up, should build file object straight from the file
return findFile(null, file: + file.getAbsolutePath(), null);
}
It calls findFile that is in AbstractOriginatingFileProvider
The signature of the method is
findFile(final FileObject baseFile, final String uri, final
FileSystemOptions fileSystemOptions) throws FileSystemException
Notice the name of the second argument: 'uri'
Here's the problem:
Let's say I have file whose absolute path is
/foo/%bar
It's uri should be file:/foo/%25bar but now it just is file:/foo/%bar
which is not a correct uri
leading to an exception later when the system tries to decode the uri
and complains that
Invalid URI escape sequence %ba
So the method should be
public FileObject findLocalFile(final File file)
throws FileSystemException
{
// TODO - tidy this up, should build file object straight from the file
return findFile(null, file: +
ENCODE_URI_SOMEHOW(file.getAbsolutePath()), null);
}
the same remark applies to
public FileObject findLocalFile(final String name)
throws FileSystemException
{
// TODO - tidy this up, no need to turn the name into an absolute URI,
// and then straight back again
return findFile(null, file: + name, null);
}
- Rami Ojares
Ps. I hope this remark is valid since I haven't updated the sources for
a long time.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Rami Ojares wrote:
public FileObject findLocalFile(final File file)
throws FileSystemException
{
// TODO - tidy this up, should build file object straight from the file
return findFile(null, file: +
ENCODE_URI_SOMEHOW(file.getAbsolutePath()), null);
}
I would do even less work than that (being as lazy as I am):
public FileObject findLocalFile(final File file)
throws FileSystemException {
return findFile(null, file.toURI().toString(), null);
}
java.io.File is handy that way. :-)
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Here is my proposal using idea from binkley
/**
* Finds a local file, from its local name.
*/
public FileObject findLocalFile(final String name)
throws FileSystemException
{
// TODO - tidy this up, no need to turn the name into an
absolute URI,
// and then straight back again
return findFile(null, (new File(name)).toURI().toString(), null);
}
/**
* Finds a local file.
*/
public FileObject findLocalFile(final File file)
throws FileSystemException
{
// TODO - tidy this up, should build file object straight from
the file
return findFile(null, file.getAbsoluteFile().toURI().toString(),
null);
}
I tried it and it worked.
- rami
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] NTP + Time test code not in CVS branch
Jason, Thanks for the heads-up. I will have a look and restore them. Cheers, Rory Jason Mathews wrote: In the latest build of Net commons it appears that the contributed Ntp + Time junit tests got dropped. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 Test classes in question: Directory of C:\net\src\test\org\apache\commons\net\ntp 10/08/2003 09:56 AM 5,876 TimeStampTest.java Directory of C:\net\src\test\org\apache\commons\net\time 10/08/2003 09:57 AM 6,021 TimeTCPClientTest.java 09/26/2003 08:35 AM 6,332 TimeTestSimpleServer.java -- Jason Mathews [EMAIL PROTECTED] The MITRE Corporation http://www.mitre.org/ Bedford, MA 01730-1407 - 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: [logging] discovery error handling
thanks to you both for your investigations i'm not sure that examples 5 and 6 support the conclusions as strongly as they might. log4jlogger contains a symbolic link to class distributed as part of log4j. it must therefore be placed in a classloader that can load log4j. therefore the NoClassDefFoundError is required. probably better to use the api jar in the parent and main jar in the child. some of the rest of ceki's are interesting :) the behaviour in brian's example 10 seems a little unexpected... i've mainly been going through the code by eye so far. i'd really like to get some proper unit test to try to nail down whether some of ceki's points are down to simple implementation flaws. i'd like to address brian's comments about packaging separately (since it relates to JCL2, in my mind if nowhere else) - robert On Thu, 2005-03-03 at 18:05, Ceki Gülcü wrote: Brian, Thank you for your analysis which is very much appreciated. I think it deserves further investigation. Unfortunately, I can't spare the time to study it right away, but promise to do so as soon as my schedule clears up. On 2005-03-03 5:34:50, Brian Stansberry wrote: What I've found is documented at http://xnet.wanconcepts.com/jcl/furtherAnalysis.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] discovery error handling
On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip I know there has been a lot of discussion on this list of these issues, far more than I have had a chance to digest fully, so I apologize if I'm stating the obvious or missing the obvious. very little to do with JCL is obvious :) one of the problems is that richard and i come with JCL with our own preconceptions. we've also talked these issues through in the past. so But, in any case I thought others might find it useful to have the relevant issues summarized in one document; I know I found Ceki's document very helpful. thanks - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33887] New: - [betwixt][Patch] Can't output bean's class property when using dot-betwixt file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33887 Summary: [betwixt][Patch] Can't output bean's class property when using dot-betwixt file Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Betwixt AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] hi, quite a while ago I asked about a feature to output a bean's class property in XML. This was implemented in cocoon by addind the PropertySuppressionStrategy. This worked fine until yesterday, when I wanted a bean's XML output to be configured by a dot-betwixt file AND to output it's class property. This was not possible caused by three lines of code in ElementRule class that where marked with a TODO. I think these three lines could be removed, because (hope I'm right) they are only called if the class property is explicitly specified in a dot-betiwxt file, and then it should never be supressed. An alternative would be to call the PropertySupressionStrategy here instead, but then perheaps a property specified in a dot-betwixt file would be supressed for the user's surprise. I'll attach a patch to this bugreport containing a TestCase that fails without my patch to ElementRule applied, and returns without error with the bugfix applied to this class. Hope somebody will commit it. regards, Christoph [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33887] - [betwixt][Patch] Can't output bean's class property when using dot-betwixt file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33887 --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 23:54 --- Created an attachment (id=14425) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14425action=view) patch with a test case and the bugfix. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] distribution packaging [WAS Re: [logging] discovery error handling]
(new thread on packaging) On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip What I've found is documented at http://xnet.wanconcepts.com/jcl/furtherAnalysis.html. we need to take a longer look into repackaging. i didn't expect that altering the distributions would work so well. i'd definitely be willing to review patches if someone wants to volunteer to alter the build, create some good test cases and write up some documentation. i'd always suspected that static binding was the only solution for several difficult cases (but using byte code engineering rather than selective compilation as used in UGLI). the sticking point for this (and many other cases i'd like to be able to address) is that LogFactory is too complex and too tightly coupled to a container environment. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient]contrib
I was looking for a jar containing the contrib classes for SSL. Can some tell me what the intention is for this stuff will it be packaged as part of the distribution? If you want to use it do you need to check it out of CVS and build it yourself? Thanks Derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH][commons-daemon]Setting the process name
Has anyone had a chance to look at this? Also did anyone get the patch file attached to the email? I'm sure I attached it, but I just noticed that the attachment I got with the email was a file containing this - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks -Original Message- From: Derek Lohnes [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 11:46 AM To: commons-dev@jakarta.apache.org Subject: [PATCH][commons-daemonSetting the process name I'm using the JSVC to run multiple java processes. I would like to be able to tell them apart when viewing the process list. Currently they all display as jsvc-exec. The patch contains a new command line argument called procname. If procname is passed as an argument to jsvc it is as the process name instead of the hardcoded 'jsvc.exec'. Also could you tell me when the next release would be available I'd prefer to use a released version of jsvc then a locally modified version, assuming this patch is accepted. Thanks Derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18942] - [beanutils] Add t/f to BooleanConverter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18942 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 00:51 --- (In reply to comment #25) Don't see it on HEAD - did you commit it on a branch? Nope, it was committed to trunk. Are you looking at the subversion repository? The CVS repository is no longer used for commons projects. Info on accessing subversion is available by following the Access CVS Repositories link on the BeanUtils page (this link name will be fixed sometime; the correct page is linked *to*, however). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] NTP + Time test code not in CVS branch
Rory Winston wrote: Jason, Thanks for the heads-up. I will have a look and restore them. Cheers, Rory Jason Mathews wrote: In the latest build of Net commons it appears that the contributed Ntp + Time junit tests got dropped. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 Test classes in question: Directory of C:\net\src\test\org\apache\commons\net\ntp 10/08/2003 09:56 AM 5,876 TimeStampTest.java Directory of C:\net\src\test\org\apache\commons\net\time 10/08/2003 09:57 AM 6,021 TimeTCPClientTest.java 09/26/2003 08:35 AM 6,332 TimeTestSimpleServer.java -- Jason Mathews [EMAIL PROTECTED] The MITRE Corporation http://www.mitre.org/ Bedford, MA 01730-1407 - 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] SVN conversion the culprit, perhaps? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
file.toURI().toString() is not the way to go.
The reason is simple. It does not work.
I don't know why. So I think we should use
ParseUtil.encode(..) which does work and decide
which characters to include as special ones.
I did this and it works (last time I said this I was wrong
because a jar did not get updated ..)
But now I'm home so I will
submit it tomorrow. Anyway there is nothing to it so mario can
probably make the fix right away. But the list of
special characters needs still to be addressed.
I think at least {'#', ' '}
- rami
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1 rc (practice)
From: Henri Yandell [EMAIL PROTECTED] For other projects I do, I build the jar file, source and binary dists using ant. I do this using an old JDK (1.3, although perhaps it should even be 1.2). I also use this same jar file to upload to ibiblio. I do NOT use maven - it uses the wrong JDK and I don't trust it enough. How can it use the wrong JDK? Is Maven 1.4+ nowadays or something? Last time I tried, it only worked on 1.4. For something as important as compiling code I want to be able to see and understand what it is doing, not cross my fingers and leave it up to a magic black box. I've always used Maven on Commons projects (when mavenized) because I don't have to worry about whether the custom Ant script is sufficiently customised (or evne up to date as most are generated from Maven). Afaik, only Collections still used a custom Ant file. If true, then thats unfortunate. I'd prefer to separate this concept completely. Have a completely seperate way of storing and managing the javadoc, maybe even go as far as to check said javadoc into the repository (not necessarily inside Lang), or just copying the docs/apidocs over to an official place, rather than inside Lang. Well, all I know is that for Joda-Time it works very neatly, and its just a variation on what we have for [collections]. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33889] New: - split camel case strings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33889. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33889 Summary: split camel case strings Product: Commons Version: unspecified Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P2 Component: Lang AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Have the ability to split up any entered camel cased string. example: entering stepListFirst would return step List First. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33889] - [lang] split camel case strings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33889. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33889 [EMAIL PROTECTED] changed: What|Removed |Added Summary|split camel case strings|[lang] split camel case ||strings -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33889] - [lang] split camel case strings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33889. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33889 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement OS/Version|Mac OS X 10.3 |All Platform|Macintosh |All -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN][configuration]Release candidate 1.1RC2
Oliver Heger wrote:
NOTICE.txt is missing from source and binary distros and jar.
Not sure about this. I used maven dist to build the distros. Do I have
to tweak the maven.xml so that this file gets included?
To get it into the jar, add it as a build resource in project.xml:
resources
resource
directory${basedir}/directory
includes
includeNOTICE.txt/include
/includes
targetPathMETA-INF/targetPath
/resource
/resources
To get it into the top-level directories, you need to tweak maven.xml.
Here is one way to do it:
preGoal name=dist:build-bin
copy todir=${maven.dist.bin.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
preGoal name=dist:build-src
copy todir=${maven.dist.src.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
hth,
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1 rc (practice)
On Tue, 8 Mar 2005 00:57:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] For other projects I do, I build the jar file, source and binary dists using ant. I do this using an old JDK (1.3, although perhaps it should even be 1.2). I also use this same jar file to upload to ibiblio. I do NOT use maven - it uses the wrong JDK and I don't trust it enough. How can it use the wrong JDK? Is Maven 1.4+ nowadays or something? Last time I tried, it only worked on 1.4. For something as important as Erk. You're absolutely right. Under 1.2 it fails due to the lack of Collections.EMPTY_MAP (introduced in 1.3). A new install of 1.3 is giving me libstdc++ errors, which makes it too painful to try with, but I bet that dies for some reason or other too. Sorry for arguing about it. compiling code I want to be able to see and understand what it is doing, not cross my fingers and leave it up to a magic black box. It's a trust thing for both of us. The difference being, I've got trust in the standard Maven process that I use every day, and surprise at seeing a custom written build.xml; while you trust your custom build.xml over Maven's black box. I've always used Maven on Commons projects (when mavenized) because I don't have to worry about whether the custom Ant script is sufficiently customised (or evne up to date as most are generated from Maven). Afaik, only Collections still used a custom Ant file. If true, then thats unfortunate. grep 'generated by maven' */build.xml gives me 14 hits out of 34, so nowhere near as much as I thought. I'd prefer to separate this concept completely. Have a completely seperate way of storing and managing the javadoc, maybe even go as far as to check said javadoc into the repository (not necessarily inside Lang), or just copying the docs/apidocs over to an official place, rather than inside Lang. Well, all I know is that for Joda-Time it works very neatly, and its just a variation on what we have for [collections]. I'll redo it with Ant and see if things get better. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33891] New: - [cli] MissingArgumentException is thrown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33891. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33891 Summary: [cli] MissingArgumentException is thrown Product: Commons Version: 1.0 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: CLI AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] For the options: -22 p -23 -22 for the option -22, I'd like to get the value p and for the option -23 , I want to get the value -22. When I run the program, the exception is thrown. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] 1.0.5: WeakHashtable
Hi,
Here are a few comments on logging-1.0.5-alpha1. More to come..
===
Should the WeakHashtable class be rolled into commons-logging.jar?
It seems easier for users than remembering to deploy the extra jar, and
should be feasable by having something like this in
Hashtable foo;
String version = System.getProperty(java.vm.specification.version);
if (versionLessThan(version, 1.3)) {
foo = new Hashtable();
} else {
// use reflection to create instance
foo = createWeakHashtable();
}
Or is the reason for having it separate because there is a performance
hit when using it? If that is so, then file guide.xml should document
that rather than saying always deploy it when using java 1.3 or later.
===
The current javadoc for the WeakHashtable class doesn't include a
description of the general problem it's trying to solve (though this is
well described in the guide.xml).
I found it rather difficult to understand the description of the
remaining issue that this class still doesn't handle.
So attached is a proposed patch to the javadoc for the WeakHashtable
class.
BTW, is there a maven command that will actually generate the javadoc
for the optional classes?
Regards,
Simon
Index: WeakHashtable.java
===
--- WeakHashtable.java (revision 156470)
+++ WeakHashtable.java (working copy)
@@ -22,47 +22,68 @@
import java.util.*;
/**
- * pImplementation of codeHashtable/code that uses codeWeakReference/code's
- * to hold it's keys thus allowing them to be reclaimed by the garbage collector.
- * This class follows the symantics of codeHashtable/code as closely as possible.
- * It therefore does not accept null values or keys.
- * p
- * This implementation is also tuned towards a particular purpose: for use as a replacement
- * for codeHashtable/code in codeLogFactory/code. This application requires
- * good liveliness for codeget/code and codeput/code. Various tradeoffs
- * have been made with this in mind.
- * /p
- * p
- * strongUsage:/strong typical use case is as a drop-in replacement
- * for the codeHashtable/code use in codeLogFactory/code for J2EE enviroments
- * running 1.3+ JVMs. Use of this class iin most cases/i (see below) will
- * allow classloaders to be collected by the garbage collector without the need
- * to call [EMAIL PROTECTED] org.apache.commons.logging.LogFactory#release(ClassLoader) LogFactory.release(ClassLoader)}.
- * /p
- * p
- * In a particular usage scenario, use of codeWeakHashtable/code alone will
- * be insufficent to allow garbage collection of a classloader without a call to
- * coderelease/code. If the abstract class codeLogFactory/code is
- * loaded by a parent classloader and a concrete subclass implementation of
- * codeLogFactory/code is loaded by a child classloader, the concrete
- * implementation will have a strong reference to the child classloader via the
- * chain codegetClass().getClassLoader()/code. The codeWeakHashtable/code
- * will have a strong reference to the codeLogFactory/code implementation as
- * one of the values in its map. This chain of references will prevent
- * collection of the child classloader.
- * /p
- * p
- * Such a situation would typically only occur if commons-logging.jar were
- * loaded by a parent classloader (e.g. a server level classloader in a
- * servlet container) and a custom codeLogFactory/code implementation were
- * loaded by a child classloader (e.g. a web app classloader). If use of
- * a custom codeLogFactory/code subclass is desired, ensuring that the
- * custom subclass is loaded by the same classloader as codeLogFactory/code
- * will prevent problems. In normal deployments, the standard implementations
- * of codeLogFactory/code found in package codeorg.apache.commons.logging.impl/code
- * will be loaded by the same classloader that loads codeLogFactory/code
- * itself, so use of the standard codeLogFactory/code implementations
- * should not pose problems.
+ * pImplementation of codeHashtable/code that uses codeWeakReference/codes
+ * to hold its keys thus allowing them to be reclaimed by the garbage collector.
+ * The associated values are retained using strong references./p
+ *
+ * pThis class follows the symantics of codeHashtable/code as closely as
+ * possible. It therefore does not accept null values or keys./p
+ *
+ * pClass org.apache.commons.logging.LogFactory looks to see whether this
+ * class is present in the classpath, and if so then uses it to store
+ * references to the LogFactory classes it loads, rather than using a standard
+ * Hashtable instance. Having this class used instead of Hashtable solves
+ * certain issues related to dynamic reloading of applications in J2EE-style
+ * environments. However this class requires java 1.3 or later, due to its use
+ * of java.lang.ref.WeakReference and related class, and therefore cannot be
+ * included in the main logging distribution which
Re: [logging] distribution packaging
--- robert burrell donkin [EMAIL PROTECTED] wrote: (new thread on packaging) On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote: What I've found is documented at http://xnet.wanconcepts.com/jcl/furtherAnalysis.html. we need to take a longer look into repackaging. i didn't expect that altering the distributions would work so well. I was a little surprised myself, which is why I wanted to follow Ceki's good example and publish test cases that could easily be verified (or debunked) by others. i'd definitely be willing to review patches if someone wants to volunteer to alter the build, create some good test cases and write up some documentation. I'd be happy to take that on if a consensus is reached that repackaging is the way to go. Might take me a bit of time though, as I'm fairly swamped. i'd always suspected that static binding was the only solution for several difficult cases (but using byte code engineering rather than selective compilation as used in UGLI). the sticking point for this (and many other cases i'd like to be able to address) is that LogFactory is too complex and too tightly coupled to a container environment. Yep, all the tests cases basically simulate different types of containers. But hopefully we're close to getting the container use cases clean. Brian - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r156508 - in jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider: AbstractOriginatingFileProvider.java local/DefaultLocalFileProvider.java local/LocalFileName.java
Author: imario
Date: Mon Mar 7 23:47:22 2005
New Revision: 156508
URL: http://svn.apache.org/viewcvs?view=revrev=156508
Log:
directly create the LocalFileName from an java.io.File (or its path) to avoid
uri-encoding/decoding back and forth.
Modified:
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/AbstractOriginatingFileProvider.java
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java
Modified:
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/AbstractOriginatingFileProvider.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/AbstractOriginatingFileProvider.java?view=diffr1=156507r2=156508
==
---
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/AbstractOriginatingFileProvider.java
(original)
+++
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/AbstractOriginatingFileProvider.java
Mon Mar 7 23:47:22 2005
@@ -1,12 +1,12 @@
/*
* Copyright 2002, 2003,2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -64,7 +64,7 @@
/**
* Locates a file from its parsed URI.
*/
-private synchronized FileObject findFile(final FileName name, final
FileSystemOptions fileSystemOptions)
+protected synchronized FileObject findFile(final FileName name, final
FileSystemOptions fileSystemOptions)
throws FileSystemException
{
// Check in the cache for the file system
Modified:
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java?view=diffr1=156507r2=156508
==
---
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
(original)
+++
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/DefaultLocalFileProvider.java
Mon Mar 7 23:47:22 2005
@@ -88,9 +88,11 @@
public FileObject findLocalFile(final String name)
throws FileSystemException
{
-// TODO - tidy this up, no need to turn the name into an absolute URI,
-// and then straight back again
-return findFile(null, file: + name, null);
+StringBuffer uri = new StringBuffer(name.length() + 5);
+uri.append(file:);
+uri.append(name);
+FileName filename = parseUri(uri.toString(), false);
+return findFile(filename, null);
}
/**
@@ -99,8 +101,16 @@
public FileObject findLocalFile(final File file)
throws FileSystemException
{
-// TODO - tidy this up, should build file object straight from the file
-return findFile(null, file: + file.getAbsolutePath(), null);
+return findLocalFile(file.getAbsolutePath());
+}
+
+/**
+ * Parses a URI.
+ */
+protected FileName parseUri(final String uri, final boolean uriEncoded)
+throws FileSystemException
+{
+return LocalFileName.parseUri(uri, uriEncoded, parser);
}
/**
@@ -109,7 +119,7 @@
protected FileName parseUri(final String uri)
throws FileSystemException
{
-return LocalFileName.parseUri(uri, parser);
+return parseUri(uri, true);
}
/**
Modified:
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java?view=diffr1=156507r2=156508
==
---
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java
(original)
+++
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java
Mon Mar 7 23:47:22 2005
@@ -1,12 +1,12 @@
/*
* Copyright 2002, 2003,2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with
