RE: [Configuration] Issue with subset and substitution
Jörg Schaible wrote on Tuesday, March 30, 2004 12:37 AM: Eric Pugh wrote: If you have a closer look, it is quite obvious, why it does not work, since subset will mask now anything including the system properties. It seems that the values were resolved first in the previous version ... Comments? I think you are right.. I update scarab (scarab.tigris.org) to use the latest, and am having subset issues there as well... I did not want to create an issue in first place, since I was not sure, if such a resolving is really the right thing to do, but we should have a look at the old implementation. Basically I like the SubsetConfiguration a lot more than the old stuff. The (solved) problem with the HierarchicalConfiguration is also just because of a design flaw there and primilary not becasue of Subset itself. Well, I had a look at the old implementation of AbstractConfiguration.subset. Originally it created a new BasicConfiguration and copied all matching keys into it and ... explicitly called interpolate for the values. So we have definately a compatibility problem. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Issue with subset and substitution
Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Emmanuel Bourg wrote on Tuesday, March 30, 2004 10:40 AM: Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. :) Ahhh, I didn't had a look at the history of the test. Meanwhile I got also the impression, that this could have never worked with simple-jndi. Maybe we should switch to another implementtaion, since all what we want is to test the general JNDI interface and not that specific implementation. I had a look at JNDIKit from spice now located at codehaus.org. It provides a MemoryContext that could probably easily used. Even more, since this implementation supports also right-to-left namings and arbitrary delimiters so we could also mimic LDAP. I believe JNDIConfiguration would fail badly in this scenario. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:40 AM To: Jakarta Commons Developers List Subject: Re: [Configuration] Issue with subset and substitution Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. Emmanuel Bourg - 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: [Configuration] Issue with subset and substitution
So, does that suggest that SubsetConfiguration needs to also call the interpolate? Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:39 AM To: Jakarta Commons Developers List Subject: RE: [Configuration] Issue with subset and substitution Jörg Schaible wrote on Tuesday, March 30, 2004 12:37 AM: Eric Pugh wrote: If you have a closer look, it is quite obvious, why it does not work, since subset will mask now anything including the system properties. It seems that the values were resolved first in the previous version ... Comments? I think you are right.. I update scarab (scarab.tigris.org) to use the latest, and am having subset issues there as well... I did not want to create an issue in first place, since I was not sure, if such a resolving is really the right thing to do, but we should have a look at the old implementation. Basically I like the SubsetConfiguration a lot more than the old stuff. The (solved) problem with the HierarchicalConfiguration is also just because of a design flaw there and primilary not becasue of Subset itself. Well, I had a look at the old implementation of AbstractConfiguration.subset. Originally it created a new BasicConfiguration and copied all matching keys into it and ... explicitly called interpolate for the values. So we have definately a compatibility problem. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] New: - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore Summary: [Configuration] Property substituation does not work for subsets anymore Product: Commons Version: 1.0 Beta 1 Platform: All OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Configuration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The last refactoring of the subsets eliminated the previously working property substitution by chance. Patches follow. CAUTION: The patches revert a workaround for HierarchicalConfiguration, which makes 'illegal' internal assuptions about the implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 09:08 --- Created an attachment (id=11043) TestCompositeConfiguration.java.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 09:08 --- Created an attachment (id=11044) SubsetConfiguration.java.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 09:09 --- Created an attachment (id=11045) CompositeConfiguration.java.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: So, does that suggest that SubsetConfiguration needs to also call the interpolate? Well, see my patch. Works fine again ... but now we have the HierachicalConfiguration problem back. IMHO it would be better to resolve this in a cleaner solution. The current implementation is ... well, a bad hack ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. No wonder if you look at the implementation. Did you also test with a LDAP context ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] AbstractConfiguration based SubsetConfiguration
Jörg's patch made me realize that SubsetConfiguration could be much
shorter by extending AbstractConfiguration, the key translation just
happens in the add/getPropertyDirect methods, there is no need to
overwrite all the getters of the Configuration interface. I'm attaching
the modified implementation, let me know how it works for you. It
doesn't contain the interpolation changes, I'm still working on it.
Emmanuel Bourg
/*
* Copyright 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.configuration;
import org.apache.commons.collections.Transformer;
import org.apache.commons.collections.iterators.TransformIterator;
import java.util.Iterator;
/**
* A subset of another configuration. The new Configuration object contains
* every key from the parent Configuration that starts with prefix. The prefix
* is removed from the keys in the subset.
*
* @author Emmanuel Bourg
* @version $Revision: 1.1 $, $Date: 2004/03/09 10:31:31 $
*/
public class SubsetConfiguration extends AbstractConfiguration {
protected Configuration parent;
protected String prefix;
protected String delimiter;
/**
* Create a subset of the specified configuration
*
* @param parent The parent configuration
* @param prefix The prefix used to select the properties.
*/
public SubsetConfiguration(Configuration parent, String prefix) {
this.parent = parent;
this.prefix = prefix;
}
/**
* Create a subset of the specified configuration
*
* @param parentThe parent configuration
* @param prefixThe prefix used to select the properties.
* @param delimiter The prefix delimiter
*/
public SubsetConfiguration(Configuration parent, String prefix, String delimiter) {
this.parent = parent;
this.prefix = prefix;
this.delimiter = delimiter;
}
/**
* Return the key in the parent configuration associated to the specified
* key in this subset.
*
* @param key The key in the subset.
*/
protected String getParentKey(String key) {
if (.equals(key) || key == null) {
return prefix;
} else {
return delimiter == null ? prefix + key : prefix + delimiter + key;
}
}
/**
* Return the key in the subset configuration associated to the specified
* key in the parent configuration.
*
* @param key The key in the parent configuration.
*/
protected String getChildKey(String key) {
if (!key.startsWith(prefix)) {
throw new IllegalArgumentException(The parent key ' + key + ' is not in
the subset.);
} else {
String modifiedKey = null;
if (key.length() == prefix.length()) {
modifiedKey = ;
} else {
int i = prefix.length() + (delimiter != null ? delimiter.length() : 0);
modifiedKey = key.substring(i);
}
return modifiedKey;
}
}
/**
* Return the parent configuation for this subset.
*/
public Configuration getParent() {
return parent;
}
/**
* Return the prefix used to select the properties in the parent configuration.
*/
public String getPrefix() {
return prefix;
}
/**
* Set the prefix used to select the properties in the parent configuration.
*/
public void setPrefix(String prefix) {
this.prefix = prefix;
}
public Configuration subset(String prefix) {
return parent.subset(getParentKey(prefix));
}
public boolean isEmpty() {
return !getKeys().hasNext();
}
public boolean containsKey(String key) {
return parent.containsKey(getParentKey(key));
}
public void addPropertyDirect(String key, Object value) {
parent.addProperty(getParentKey(key), value);
}
public void clearProperty(String key) {
parent.clearProperty(getParentKey(key));
}
public Object getPropertyDirect(String key) {
return parent.getProperty(getParentKey(key));
}
public Iterator getKeys(String prefix) {
return new TransformIterator(parent.getKeys(getParentKey(prefix)), new
Transformer() {
public Object transform(Object obj) {
return getChildKey((String) obj);
}
});
}
public Iterator getKeys() {
RE: [Configuration] Issue with subset and substitution
No.. Haven't tested it at all with LDAP.. I understand that JNDI is an implementation based on LDAP? but haven't worked with LDAP in java world before.. Need to... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 10:13 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [Configuration] Issue with subset and substitution Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. No wonder if you look at the implementation. Did you also test with a LDAP context ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 11:48 AM: No.. Haven't tested it at all with LDAP.. I understand that JNDI is an implementation based on LDAP? No, I mean the JDK comes walso with an LDAP provider for JNDI. The specification even contains nestes keys, but I did not grok that part fully. So basically such an JNDI key (or similar) could be valid: my.prop.to.ldap:cn=me,cn=user,dc=company,dc=org notice the change of the direction for the hierarchy ... but haven't worked with LDAP in java world before.. Need to... Eric Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Closing opened input streams
Eric Pugh wrote: I don't know, it seems though that if we can't close the stream, should we keep going? Yes I think so, the configuration is usable even if the stream cannot be closed. It's not a fatal error, but the user has to be notified to take the necessary measures. We may prefer using commons-logging here instead of a raw stacktrace though. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] AbstractConfiguration based SubsetConfiguration
Emmanuel Bourg wrote on Tuesday, March 30, 2004 11:39 AM: Jörg's patch made me realize that SubsetConfiguration could be much shorter by extending AbstractConfiguration, the key translation just happens in the add/getPropertyDirect methods, there is no need to overwrite all the getters of the Configuration interface. I'm attaching the modified implementation, let me know how it works for you. It doesn't contain the interpolation changes, I'm still working on it. Emmanuel Bourg Works perfectly. I'll update the patch. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 10:02 --- Created an attachment (id=11046) SubsetConfiguration.java.2.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] ListOrdereMap vs LinkedMap
Edelson, Justin wrote: ListOrderedMap cannot be instantiated directly. Per the Javadocs, it's a decorator, not a Map implementation. You get an instance of ListOrderedMap by passing an existing Map to ListOrderedMap.decorate(Map). LinkedMap, however, can be instantiated directly and has similar constructors to java.util.HashMap. Hope this helps. Thanks, Justin, that's exactly the only differnce I can see. (plus the implementation of the Serializable interface) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042.
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=28042
[Configuration] Property substituation does not work for subsets anymore
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 11:10 ---
I have another interpolation test that doesn't seem to work with this patch, I
haven't investigated why yet.
public void testSubsetInterpolation() {
BaseConfiguration conf1 = new BaseConfiguration();
conf1.setProperty(conf1.key, test);
BaseConfiguration conf2 = new BaseConfiguration();
conf1.setProperty(conf2.key, ${conf1.key}/test);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration(conf1);
cc.addConfiguration(conf2);
Configuration subset = cc.subset(conf2);
assertEquals('key' value in the 'conf2' subset, test/test,
subset.getProperty(key));
}
And the failure is :
'key' value in the 'conf2' subset expected:test/test but was:${conf1.key}/test
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 11:43 --- You get what you've asked for. A general property can be any object, interpolation is only done requesting Strings or a StringList. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [Configuration] Property substituation does not work for subsets anymore
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=28042. 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=28042 [Configuration] Property substituation does not work for subsets anymore [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 11:49 --- Oops you are right sorry :) It works fine with getString - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [vote] Release Commons-Net 1.2
While on the subject of nits, here's one from the background section: However, no updates have been made since version 1.3.8, released in 1998. Probably true when it was written but no longer. On Monday 29 March 2004 10:45 pm, Gary Gregory wrote: Looks much better! Now I might be nit picking here but here it goes anyway. (1) IMHO, the 1st sentence (This is an Internet protocol suite Java library originally developed by ORO, Inc.) should be moved to the Background section. The first sentence should tell you something very important, this isn't it. To me, this is like with a Javadoc comment, the 1st sentence is extracted as a summary, so the 1st sentence should tell you in a nutshell what commons-net is all about. (2) In the Features, section, I would replace Supported protocols include: with The supported protocols are: and list them all. (3) Spelling errors/typos: protocal - protocol accesible - accessible e.g - e.g. NetComponents - Jakarta commons-net the The Apache Software License - the Apache Software License Nitpickin', Gary -Original Message- From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 20:31 To: Jakarta Commons Developers List Subject: Re: [net] [vote] Release Commons-Net 1.2 On Mon, 29 Mar 2004 00:25:59 -0500, Gary Gregory [EMAIL PROTECTED] said: WRT http://jakarta.apache.org/commons/net/ Shouldn't the heading Jakarta Commons/Net probably just be Jakarta Commons Net? Also that whole paragraph could use some formatting, for example a bullet list of features. Agreed. I took a stab at reformatting the index. No new information, just broke up a little more. http://jakarta.apache.org/commons/net/ -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28042] - [configuration] Property substitution doesn't work for subsets anymore
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=28042. 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=28042 [configuration] Property substitution doesn't work for subsets anymore [EMAIL PROTECTED] changed: What|Removed |Added Summary|[Configuration] Property|[configuration] Property |substituation does not work |substitution doesn't work |for subsets anymore |for subsets anymore - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] @author tag tidyup
Simon Kitching wrote: Hi, We had a discussion about author tags a while ago. The general consensus was that individuals should no longer be listed in these tags [NB: not an official vote]. I think this is now also apache policy? It's a recommendation of the ASF Board. Robert Donkin suggested using them to credit the commons team, with the benefit that a link would lead back to apache. I see that these tags have started appearing in Betwixt: * @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a I'm happy with this; the line length is 73 chars, so it fits nicely within an 80-char line without wrapping and seems useful. Does anyone have any objections if I replace all the existing @author tags in digester with this? I have already copied all author info into the project.xml file... [NB: I might make it The Jakarta Commons Team for grammatical reasons :-] I'd actually prefer to just get rid of the @author line entirely. If we're going to keep it, though, the link should really point at something useful, like perhaps the home page of the Digester website. Regards, Simon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] @author tag tidyup
I'd actually prefer to just get rid of the @author line entirely. If we're going to keep it, though, the link should really point at something useful, like perhaps the home page of the Digester website. For projects that choose to follow the Board recommendation of not using personal @author tags, it would be nice to have a consistent format across Jakarta. For codec, we now use: * @author Apache Software Foundation I am not sure why this string and not something project specific with an href. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2 DocumentationTest.java
roxspring2004/03/30 11:15:22
Modified:cli/src/java/org/apache/commons/cli2/impl Tag:
RESEARCH_CLI_2_ROXSPRING GroupImpl.java
ParentImpl.java ArgumentImpl.java
PropertyOption.java Switch.java DefaultOption.java
Command.java OptionImpl.java
cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING HelpFormatter.java
OptionException.java
cli/src/test/org/apache/commons/cli2/impl Tag:
RESEARCH_CLI_2_ROXSPRING PropertyOptionTest.java
GroupTest.java ArgumentTest.java ParentTest.java
CommandTest.java SwitchTest.java
DefaultOptionTest.java
cli/src/test/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING DocumentationTest.java
Added: cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING DisplaySetting.java
Removed: cli/src/java/org/apache/commons/cli2 Tag:
RESEARCH_CLI_2_ROXSPRING HelpSetting.java
Log:
Renamed HelpSetting to DisplaySetting so that the name better matches the use
Revision ChangesPath
No revision
No revision
1.1.2.17 +13 -13
jakarta-commons/cli/src/java/org/apache/commons/cli2/impl/Attic/GroupImpl.java
Index: GroupImpl.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/impl/Attic/GroupImpl.java,v
retrieving revision 1.1.2.16
retrieving revision 1.1.2.17
diff -u -r1.1.2.16 -r1.1.2.17
--- GroupImpl.java30 Mar 2004 01:43:09 - 1.1.2.16
+++ GroupImpl.java30 Mar 2004 19:15:21 - 1.1.2.17
@@ -31,7 +31,7 @@
import org.apache.commons.cli2.Argument;
import org.apache.commons.cli2.Group;
import org.apache.commons.cli2.HelpLine;
-import org.apache.commons.cli2.HelpSetting;
+import org.apache.commons.cli2.DisplaySetting;
import org.apache.commons.cli2.Option;
import org.apache.commons.cli2.OptionException;
import org.apache.commons.cli2.WriteableCommandLine;
@@ -301,24 +301,24 @@
final boolean optional =
minimum == 0
- helpSettingsCopy.contains(HelpSetting.DISPLAY_OPTIONAL);
+ helpSettingsCopy.contains(DisplaySetting.DISPLAY_OPTIONAL);
final boolean expanded =
name == null
-|| helpSettingsCopy.contains(HelpSetting.DISPLAY_GROUP_EXPANDED);
+|| helpSettingsCopy.contains(DisplaySetting.DISPLAY_GROUP_EXPANDED);
final boolean named =
!expanded
|| (name != null
- helpSettingsCopy.contains(HelpSetting.DISPLAY_GROUP_NAME));
+
helpSettingsCopy.contains(DisplaySetting.DISPLAY_GROUP_NAME));
final boolean arguments =
-helpSettingsCopy.contains(HelpSetting.DISPLAY_GROUP_ARGUMENT);
+helpSettingsCopy.contains(DisplaySetting.DISPLAY_GROUP_ARGUMENT);
final boolean outer =
-helpSettingsCopy.contains(HelpSetting.DISPLAY_GROUP_OUTER);
+helpSettingsCopy.contains(DisplaySetting.DISPLAY_GROUP_OUTER);
-helpSettingsCopy.remove(HelpSetting.DISPLAY_GROUP_OUTER);
+helpSettingsCopy.remove(DisplaySetting.DISPLAY_GROUP_OUTER);
final boolean both = named expanded;
@@ -335,12 +335,12 @@
if (expanded) {
final Set childSettings;
if (!helpSettingsCopy
-.contains(HelpSetting.DISPLAY_GROUP_EXPANDED)) {
-childSettings = HelpSetting.NONE;
+.contains(DisplaySetting.DISPLAY_GROUP_EXPANDED)) {
+childSettings = DisplaySetting.NONE;
}
else {
childSettings = new HashSet(helpSettingsCopy);
-childSettings.remove(HelpSetting.DISPLAY_OPTIONAL);
+childSettings.remove(DisplaySetting.DISPLAY_OPTIONAL);
}
// grab a list of the group's options.
@@ -398,11 +398,11 @@
final Set helpSettings,
final Comparator comp) {
final List helpLines = new ArrayList();
-if (helpSettings.contains(HelpSetting.DISPLAY_GROUP_NAME)) {
+if (helpSettings.contains(DisplaySetting.DISPLAY_GROUP_NAME)) {
final HelpLine helpLine = new HelpLineImpl(this, depth);
helpLines.add(helpLine);
}
-if (helpSettings.contains(HelpSetting.DISPLAY_GROUP_EXPANDED)) {
+if (helpSettings.contains(DisplaySetting.DISPLAY_GROUP_EXPANDED)) {
// grab a list of the group's options.
Re: [configuration] Flattening trees
Jörg Schaible wrote: Emmanuel Bourg wrote on Tuesday, March 30, 2004 4:44 PM: Hi, last week I started playing with the Preferences API and a Windows configuration manipulating the registry through JNI. I had not experimented with hierarchical configurations before, this led me to a dumb question : what are we supposed to do when a key contains a dot ? Should we search the value in the sub nodes or get the first property in the current node matching the key ? This issue can be illustrated with the following XML configuration: a b cvalue1/c /b b.cvalue2/b.c /a What's the key a.b.c supposed to return ? value1 ? value2 ? Or an array with both ? A lot of configurations have a hierarchical structure : LDAP, JNDI, the windows registry, INI files (a tree a depth 1), XML files, the Avalon configuration API, the JDK 1.4 Preferences API. That makes me wonder if we aren't on the wrong track for a generic configuration API, [configuration] is Properties centric for historical reasons, should we keep trying to flatten hierarchical structures and make them look like a .properties file ? Should we change the Configuration interface to support hierarchical structures directly (and turn PropertiesConfiguration into a tree) ? To clean-up the resurrected HierarchicalConfiguration problem, you will have to do this anyway. And IMHO you're right and I already mensioned that e.g. JDNI's nature *is* hierarchical. Even the java properties are. The flat structure is just a special case of a more generic hierarchical structure. The flat accessor a.b.c is a shortcut for a(0).b(0).c(0). Should we support both separately with an XPath like syntax to unify the keys ? Definately, but post 1.0. I think you will be able to remove a lot of code with a real generic solution. For 1.0 we will have to modify the Configuration interface at least in a way, we can solve the problem with HierarchicalConfiguration and Oliver had a solution for this (making Configuration hierarchical arware). Regards, Jörg Unfortunately I won't have time prior to Thursday evening. Can you tell me which unit tests are failing? If it's only the test for ConfigurationXMLDocument, I would suggest to drop this class in the 1.0 release and add it later again (I think it is unlikely that this class is already used; it was lost after the move from sandbox and nobody noticed). Other tests should not fail because they still worked after the SubConfiguration refactoring. If we start thinking about more support for hierarchical configurations (an approach I really welcome), I now don't want to come up with a quick solution for the actual problem. It would be much better to do it right in the next release. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Graph Project
Rowan Christmas wrote: It seems to be under the Gump project, and I was unable to find a formal page that had things like contact/api information on it. See also the graph2 subproject in the jakarta commons sandbox. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/binary BinaryCodec.java
ggregory2004/03/30 13:34:28 Modified:codec/src/java/org/apache/commons/codec/binary BinaryCodec.java Log: Javadoc. Revision ChangesPath 1.2 +1 -1 jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java Index: BinaryCodec.java === RCS file: /home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- BinaryCodec.java 29 Mar 2004 23:04:41 - 1.1 +++ BinaryCodec.java 30 Mar 2004 21:34:28 - 1.2 @@ -22,7 +22,7 @@ import org.apache.commons.codec.EncoderException; /** - * Encodes and decodes byte arrays to and from ASCII bit Strings. + * Translates between byte arrays and strings of 0s and 1s. * * @todo may want to add more bit vector functions like and/or/xor/nand * @todo also might be good to generate boolean[] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] @author tag tidyup
Gary Gregory wrote: I'd actually prefer to just get rid of the @author line entirely. If we're going to keep it, though, the link should really point at something useful, like perhaps the home page of the Digester website. For projects that choose to follow the Board recommendation of not using personal @author tags, it would be nice to have a consistent format across Jakarta. For codec, we now use: * @author Apache Software Foundation I am not sure why this string and not something project specific with an href. If the @author tag doesn't refer to an individual, I think the easiest bet would be to just remove them. @author Apache Software Foundation -- this is restating the obvious. Unless incubator projects would refer to the original author, and not Apache? In that case, it may make sense. (example) @author Jakarta Commons Codec Team -- also very redundant. Who else would have written it? Anyone who commits or submits patches to the project already knows who the official author is, and also the individuals who actually wrote the code behind the scenes. So, the target audience for these new @author tags seems to be people who are unfamiliar with Jakarta Commons. Now, seeing as though these people will probably be viewing the JavaDoc at: http://jakarta.apache.org/commons/codec/apidocs Isn't it redundant to include an href to: http://jakarta.apache.org/commons/codec in each file? I say let's get rid of the @author tags and save ourselves some work. I may be misunderstanding some political issues here, maybe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28066] New: - Error parsing NT FTP Listing when Server lists in Unix Format
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=28066. 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=28066 Error parsing NT FTP Listing when Server lists in Unix Format Summary: Error parsing NT FTP Listing when Server lists in Unix Format Product: Commons Version: 1.1.0 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When listing file in an NT FTP Server, which is set to list in UNIX format, there is a little problem with the UNIXFTPEntryParser regular expression. For files created between 0:00 AM and 9:59 AM, the list returned from an UNIX FTP Server and from a NT FTP Server (set to list in the UNIX format) diverge. The hour in the UNIX System is always shown with to digits (00, 01, 02, ... 10, 11, 12, ... 23). Nevertheless the hour in the NT System varies (0, 1, 2 ,... 10, 11, 12 , ... 23). Example: UNIX: -rw-rw-r-- 1 mqmmqm 17707 Mar 12 03:33 killmq.sh.log NT: -rw-rw-r-- 1 mqmmqm 17707 Mar 12 3:33 killmq.sh.log As the UNIXFTPEntryParser regular expression is not prepared to this kind of listing, the program hangs, for some unknown reason. I substituted the regular expression from private static final String REGEX = ([bcdlf-]) + (((r|-)(w|-)(x|-))((r|-)(w|-)(x|-))((r|-)(w|-)(x|-)))\\s+ + (\\d+)\\s+ + (\\S+)\\s+ + (?:(\\S+)\\s+)? + (\\d+)\\s+ + MONTHS + \\s+ + ((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))\\s+ + ((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])):([012345]\\d))\\s + (\\S+)(\\s*.*); to private static final String REGEX = ([bcdlf-]) + (((r|-)(w|-)(x|-))((r|-)(w|-)(x|-))((r|-)(w|-)(x|-)))\\s+ + (\\d+)\\s+ + (\\S+)\\s+ + (?:(\\S+)\\s+)? + (\\d+)\\s+ + MONTHS + \\s+ + ((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))\\s+ + ((\\d\\d\\d\\d)|((?:[01]\\d??)|(?:2[0123])|(?:[3-9])):([012345]\\d)) \\s + (\\S+)(\\s*.*); and it worked fine. Best Regards, Gastão - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] Status of 1.3 Release
Hello, I think we are pretty close. To do: - Get 100% Clover unit test coverage on the new classes BCodec and QCodec. - Scan the Bugzilla database for unresolved issues and if any issues exist, discuss if they should be addressed now or later. - Complete the RELEASE-NOTES.txt file, in particular note new features and bugs fixed. - Add a JDiff report to the build. Gary -Original Message- From: Alex Karasulu [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 11:51 To: 'Jakarta Commons Developers List' Subject: [codec] Status of 1.3 Release Gary, When do you think the 1.3 release will be ready? Is there anything I can give you a hand with? Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/xdocs index.xml
ggregory2004/03/30 14:33:56 Modified:codec/xdocs index.xml Log: Renamed Binary to BinaryCodec. Revision ChangesPath 1.16 +9 -10 jakarta-commons/codec/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/codec/xdocs/index.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- index.xml 29 Mar 2004 23:04:41 - 1.15 +++ index.xml 30 Mar 2004 22:33:56 - 1.16 @@ -97,16 +97,6 @@ /td /tr tr - td width=150 - a href=apidocs/org/apache/commons/codec/binary/BinaryCodec.html - BinaryCodec/a - /td - td - Binary translates between byte arrays and strings of binary digits - 1 and 0. - /td - /tr - tr td a href=apidocs/org/apache/commons/codec/binary/Hex.html Hex/a @@ -114,6 +104,15 @@ td Converts an array of bytes into an array of characters representing the hexadecimal values of each byte in order + /td + /tr + tr + td width=150 + a href=apidocs/org/apache/commons/codec/binary/BinaryCodec.html + BinaryCodec/a + /td + td + Translates between byte arrays and strings of 0s and 1s. /td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28068] New: - mixed content handling
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=28068. 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=28068 mixed content handling Summary: mixed content handling Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Discussion ongoing on dev list about actual implementation, but I wanted to put out a test case that illustrates the problem. Basically, the current Digester implementation concatenates all the body text together in a particular element, without care for the separation of the text parts by XML elements. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28068] - mixed content handling
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=28068. 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=28068 mixed content handling --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 22:47 --- Created an attachment (id=11065) adds some value objects and a test case to org.apache.commons.digester.mixed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven][codec] Maven RC-2 Clover problem
Hello, I installed Maven RC-2 and when I now run a [codec] build with maven clean site:generate, the build works once, but not twice. During the 2nd (last) invocation of: java:jar-resources: Copying 264 files to C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes Some kind of loop or self reference takes place such that a deep nested and undeletable dir structure is created: C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\clover Etc... On and on for a couple hundre C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\clover d entries. Help! Thank you, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/xdocs/images logo.jpg
ggregory2004/03/30 14:52:19 Removed: codec/xdocs/images logo.jpg Log: Misc files refer to logo.png, not logo.jpg. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] mixed content update
Simon - Sorry I haven't had a chance to respond to your email. I was actually more concentrating on answering your question about use-cases, but it sounds like I don't need to sell this need as much as I thought I did (at least for now). If someone (eg Justin) is keen to work on this now, we could potentially get it in the next release. Otherwise I suggest this could go on the to-do list for post-1.6. I don't know if keen is the right word, but I'm committed to digesting mixed content XML for an application now, i.e. I need to solve this problem one way or another (or use some other XML ingesting mechanism, which I don't want to do for purely selfish reasons). At this point, I'm planning on an implementation as a subclass. Whether this subclass is accepted and put into the Digester release is dependent upon a variety of factors, but my intention is to develop a solution either way. I have sign-off on contributing modifications back to Apache, so that's not an issue. Of course, I have a high level of respect for the members of this list (not blowing smoke, I swear) so I'm very interested in crafting the mixed content solution based on any feedback Commons developers may have. Just to be clear, is there a timeframe for 1.6? Justin, if you have any arguments to back your original design, please speak up! Or if you are willing to try implementing some other approach that doesn't involve @text patterns, please speak up too. Let's separate the two issues in my original design - Using a special text designator and the specific designator used. To be honest, @text was really just a placeholder on my end. The only requirement I have for this designator is that it be an illegal XML element name so as to ensure that there's no conflict (i.e. if the designator was just text, that would pose an issue if you had an element named text). My core argument in favor of using a specific designator is that it explicitly indicates that the pattern (i.e. /element/@text) uses different functionality then the traditional Digester method. This is a pretty weak argument, I'll admit. I also feel (and can't prove yet) that this method is better performance-wise because the extra iterations over the list of rules is over a smaller list. As indicated above, I'm very willing to try alternate implementations, including the interface solution you suggested. How do people feel about my initial proposed solution to this (as follows)? My only concern about the interface solution (for lack of a better name) is when you wrote 'for each rule matched by the last call to startElement' - In my original subclassed-version, I had a call to super.startElement(), but in order to do what you've described, I think you'd need to replicate all the code in Digester.startElement() in the subclasses startElement() method. Otherwise, the overridden startElement() in the subclass would have to make an extra call to Rules.match(). I was originally worried about having to maintain the subclass's startElement method to reflect changes in the Digester implementation, thus the call to super.startElement(). Is this too dogmatic? I'm not looking to rehash the cut-and-paste vs. eating our own dog food discussion recently seen in the context of [lang]. I'll have some time later in the week to take a crack at implementing the interface solution. Yet a third implementation that I've been thinking about would be to take the new interface and create some additional interfaces around it - MixedContentRules and MixedContentRuleSet. These object would basically parallel the Rule/Rules/RuleSet interfaces. Within the MixedContentDigester subclass, there'd be a new instance variable called mixedContentRules. In short, the concept is that the classes that implement MixedContentRule would be segregated from the traditional Digester rules. The core reason for this is that I'm concerned about the performance impact of both my original and Simon's solutions. By segregating the rules, I've ensured that a match() call to a MixedContentRules object only searches within MixedContentRules which should lead to better performance. And if you think there are other features that could be added to digester using @-style patterns then that would also be good to mention. I had worked up a use-case for @comment that would allow for comments to be digested (imagine a JavaDoc/Xdoclet-style application that read comments out of a struts config XML file). But then I remembered that SAX ignores comments, so this is a bigger can of worms. I've gone ahead and submitted my test case to Bugzilla (#28068). I can never remember how Bugzilla reacts to XML submitted in it's forms, so I kept that out. I assume that we're all on the same page as to what mixed content means, but I can easily add an example. Thanks for the interest. I was a bit surprised at first that some were so willing to write off Digester as just for configuration files. Justin
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/validation messages.properties ClassValidator.java
jkeyes 2004/03/30 15:48:04
Modified:cli/src/java/org/apache/commons/cli2/validation Tag:
RESEARCH_CLI_2_ROXSPRING messages.properties
ClassValidator.java
Log:
- renamed xxxLoader methods to xxxClassLoader
- changed getClassLoader to return the validators class loader by default
- fixed exception message
Revision ChangesPath
No revision
No revision
1.1.2.2 +1 -1
jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/messages.properties,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- messages.properties 23 Jan 2004 00:17:34 - 1.1.2.1
+++ messages.properties 30 Mar 2004 23:48:04 - 1.1.2.2
@@ -1,4 +1,4 @@
ClassValidator.error.bad.classname = The class name {0} is invalid.
ClassValidator.error.class.notfound = The class {0} could not be found.
ClassValidator.error.class.access = The class {0} could not be accessed. Reason:
{1}.
-ClassValidator.error.class.create = The class {0} could not be created. Reason:
{1}.
+ClassValidator.error.class.create = The class {0} could not be created.
1.1.2.5 +9 -8
jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/ClassValidator.java
Index: ClassValidator.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/ClassValidator.java,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- ClassValidator.java 8 Feb 2004 13:09:00 - 1.1.2.4
+++ ClassValidator.java 30 Mar 2004 23:48:04 - 1.1.2.5
@@ -47,9 +47,7 @@
}
if (loadable || instance) {
-if (loader == null) {
-loader = getClass().getClassLoader();
-}
+final ClassLoader loader = getClassLoader();
try {
final Class clazz = loader.loadClass(name);
if (instance) {
@@ -75,9 +73,8 @@
catch (final InstantiationException exp) {
throw new InvalidArgumentException(
resources.getMessage(
-ClassValidator.error.class.access,
-name,
-exp.getMessage()));
+ClassValidator.error.class.create,
+name));
}
}
}
@@ -118,11 +115,15 @@
this.loadable = loadable;
}
-public ClassLoader getLoader() {
+public ClassLoader getClassLoader() {
+if (loader == null) {
+loader = getClass().getClassLoader();
+}
+
return loader;
}
-public void setLoader(ClassLoader loader) {
+public void setClassLoader(ClassLoader loader) {
this.loader = loader;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/validation/protect - New directory
jkeyes 2004/03/30 15:50:02 jakarta-commons/cli/src/test/org/apache/commons/cli2/validation/protect - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/validation ClassValidatorTest.java
jkeyes 2004/03/30 15:50:07
Modified:cli/src/test/org/apache/commons/cli2/validation Tag:
RESEARCH_CLI_2_ROXSPRING ClassValidatorTest.java
Added: cli/src/test/org/apache/commons/cli2/validation/protect Tag:
RESEARCH_CLI_2_ROXSPRING ProtectedClass.java
Log:
- small reorg of code
- added tests for 100% code coverage
Revision ChangesPath
No revision
No revision
1.1.2.1 +21 -0
jakarta-commons/cli/src/test/org/apache/commons/cli2/validation/protect/Attic/ProtectedClass.java
No revision
No revision
1.1.2.6 +136 -31
jakarta-commons/cli/src/test/org/apache/commons/cli2/validation/Attic/ClassValidatorTest.java
Index: ClassValidatorTest.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/validation/Attic/ClassValidatorTest.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- ClassValidatorTest.java 8 Feb 2004 13:09:00 - 1.1.2.5
+++ ClassValidatorTest.java 30 Mar 2004 23:50:07 - 1.1.2.6
@@ -15,43 +15,46 @@
*/
package org.apache.commons.cli2.validation;
+import java.net.URL;
+import java.net.URLClassLoader;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
-import org.apache.commons.cli2.resources.ResourceHelper;
-
import junit.framework.TestCase;
+import org.apache.commons.cli2.resources.ResourceHelper;
+
public class ClassValidatorTest extends TestCase {
private final static ResourceHelper resources =
ResourceHelper.getResourceHelper(ClassValidatorTest.class);
-public void testValidate_NameValid() throws InvalidArgumentException {
+private ClassValidator validator;
+
+protected void setUp() {
+validator = new ClassValidator();
+}
+
+public void testValidName() throws InvalidArgumentException {
final Object[] array = new Object[] { MyApp, org.apache.ant.Main };
final List list = Arrays.asList(array);
-final Validator validator = new ClassValidator();
validator.validate(list);
-final Iterator i = list.iterator();
-assertEquals(MyApp, i.next());
-assertEquals(org.apache.ant.Main, i.next());
-assertFalse(i.hasNext());
+assertEquals(Name is incorrect, MyApp, list.get(0));
+assertEquals(Name is incorrect, org.apache.ant.Main, list.get(1));
}
-public void testValidate_NameBadStart() {
+public void testNameBadStart() {
final String className = 1stClass;
final Object[] array = new Object[] { className };
final List list = Arrays.asList(array);
-final Validator validator = new ClassValidator();
try {
validator.validate(list);
-fail(BadStart!);
-}
-catch (InvalidArgumentException ive) {
+fail(Class name cannot start with a number.);
+} catch (InvalidArgumentException ive) {
assertEquals(
resources.getMessage(
ClassValidator.error.bad.classname,
@@ -60,18 +63,16 @@
}
}
-public void testValidate_NameBadEnd() {
+public void testNameBadEnd() {
final String className = My.Class.;
final Object[] array = new Object[] { className };
final List list = Arrays.asList(array);
-final Validator validator = new ClassValidator();
try {
validator.validate(list);
-fail(BadEnd!);
-}
-catch (InvalidArgumentException ive) {
+fail(Trailing period not permitted.);
+} catch (InvalidArgumentException ive) {
assertEquals(
resources.getMessage(
ClassValidator.error.bad.classname,
@@ -80,18 +81,34 @@
}
}
-public void testValidate_NameBadMiddle() {
+public void testNameBadMiddle() {
final String className = My..Class;
final Object[] array = new Object[] { className };
final List list = Arrays.asList(array);
-final Validator validator = new ClassValidator();
try {
validator.validate(list);
-fail(BadMiddle!);
+fail(Two consecutive periods is not permitted.);
+} catch (InvalidArgumentException ive) {
+assertEquals(
+resources.getMessage(
+ClassValidator.error.bad.classname,
+className),
+ive.getMessage());
}
-catch (InvalidArgumentException ive) {
+
cvs commit: jakarta-commons/net/xdocs index.xml
dfs 2004/03/30 16:37:30 Modified:net/xdocs index.xml Log: Reordered protocol list with most popular protocols at top. Revision ChangesPath 1.4 +8 -7 jakarta-commons/net/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/net/xdocs/index.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.xml 30 Mar 2004 16:04:57 - 1.3 +++ index.xml 31 Mar 2004 00:37:30 - 1.4 @@ -43,17 +43,18 @@ p Supported protocols are: ul - liFinger/li - liWhois/li - liTFTP/li - liTelnet/li - liPOP3/li liFTP/li liNNTP/li liSMTP/li - liTime/li + liPOP3/li + liTelnet/li + liTFTP/li + liFinger/li + liWhois/li + lirlogin, BSD R commands/li + liTime (rdate) and Daytime/li liEcho/li - liBSD R command support/li + liDiscard/li /ul /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net/xdocs index.xml
dfs 2004/03/30 16:39:34 Modified:net/xdocs index.xml Log: Corrected last commit. Replaced BSD R command support with names of actual commands. Revision ChangesPath 1.5 +1 -1 jakarta-commons/net/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/net/xdocs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 31 Mar 2004 00:37:30 - 1.4 +++ index.xml 31 Mar 2004 00:39:34 - 1.5 @@ -51,7 +51,7 @@ liTFTP/li liFinger/li liWhois/li - lirlogin, BSD R commands/li + lirexec/rcmd/rlogin/li liTime (rdate) and Daytime/li liEcho/li liDiscard/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/util - New directory
roxspring2004/03/30 16:50:36 jakarta-commons/cli/src/test/org/apache/commons/cli2/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/util - New directory
roxspring2004/03/30 16:50:36 jakarta-commons/cli/src/java/org/apache/commons/cli2/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/impl ComparatorsTest.java
roxspring2004/03/30 16:50:46 Modified:cli/src/test/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING DocumentationTest.java cli/src/java/org/apache/commons/cli2/commandline Tag: RESEARCH_CLI_2_ROXSPRING Parser.java cli/src/test/org/apache/commons/cli2/apps Tag: RESEARCH_CLI_2_ROXSPRING CpTest.java cli/src/java/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING Option.java Added: cli/src/java/org/apache/commons/cli2/util Tag: RESEARCH_CLI_2_ROXSPRING Comparators.java HelpFormatter.java cli/src/test/org/apache/commons/cli2/util Tag: RESEARCH_CLI_2_ROXSPRING HelpFormatterTest.java ComparatorsTest.java Removed: cli/src/test/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING HelpFormatterTest.java cli/src/java/org/apache/commons/cli2/impl Tag: RESEARCH_CLI_2_ROXSPRING Comparators.java cli/src/java/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING HelpFormatter.java cli/src/test/org/apache/commons/cli2/impl Tag: RESEARCH_CLI_2_ROXSPRING ComparatorsTest.java Log: Moved HelpFormatter and Comparators to new .util package Revision ChangesPath No revision No revision 1.1.2.1 +426 -0 jakarta-commons/cli/src/java/org/apache/commons/cli2/util/Attic/Comparators.java 1.1.2.1 +505 -0 jakarta-commons/cli/src/java/org/apache/commons/cli2/util/Attic/HelpFormatter.java No revision No revision 1.1.2.1 +337 -0 jakarta-commons/cli/src/test/org/apache/commons/cli2/util/Attic/HelpFormatterTest.java 1.1.2.1 +191 -0 jakarta-commons/cli/src/test/org/apache/commons/cli2/util/Attic/ComparatorsTest.java No revision No revision 1.1.2.8 +1 -0 jakarta-commons/cli/src/test/org/apache/commons/cli2/Attic/DocumentationTest.java Index: DocumentationTest.java === RCS file: /home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/Attic/DocumentationTest.java,v retrieving revision 1.1.2.7 retrieving revision 1.1.2.8 diff -u -r1.1.2.7 -r1.1.2.8 --- DocumentationTest.java30 Mar 2004 19:15:22 - 1.1.2.7 +++ DocumentationTest.java31 Mar 2004 00:50:45 - 1.1.2.8 @@ -26,6 +26,7 @@ import org.apache.commons.cli2.builders.GroupBuilder; import org.apache.commons.cli2.commandline.Parser; import org.apache.commons.cli2.impl.PropertyOption; +import org.apache.commons.cli2.util.*; /** * @author Rob No revision No revision 1.1.2.7 +1 -1 jakarta-commons/cli/src/java/org/apache/commons/cli2/commandline/Attic/Parser.java Index: Parser.java === RCS file: /home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/commandline/Attic/Parser.java,v retrieving revision 1.1.2.6 retrieving revision 1.1.2.7 diff -u -r1.1.2.6 -r1.1.2.7 --- Parser.java 24 Feb 2004 02:01:40 - 1.1.2.6 +++ Parser.java 31 Mar 2004 00:50:45 - 1.1.2.7 @@ -24,10 +24,10 @@ import org.apache.commons.cli2.CommandLine; import org.apache.commons.cli2.Group; -import org.apache.commons.cli2.HelpFormatter; import org.apache.commons.cli2.Option; import org.apache.commons.cli2.OptionException; import org.apache.commons.cli2.WriteableCommandLine; +import org.apache.commons.cli2.util.HelpFormatter; /** * A class that implements the codeParser/code interface can parse a No revision No revision 1.1.2.8 +1 -1 jakarta-commons/cli/src/test/org/apache/commons/cli2/apps/Attic/CpTest.java Index: CpTest.java === RCS file: /home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/apps/Attic/CpTest.java,v retrieving revision 1.1.2.7 retrieving revision 1.1.2.8 diff -u -r1.1.2.7 -r1.1.2.8 --- CpTest.java 24 Feb 2004 02:01:40 - 1.1.2.7 +++ CpTest.java 31 Mar 2004 00:50:46 - 1.1.2.8 @@ -28,7 +28,6 @@ import org.apache.commons.cli2.Argument; import org.apache.commons.cli2.CommandLine; import org.apache.commons.cli2.Group; -import org.apache.commons.cli2.HelpFormatter; import org.apache.commons.cli2.Option; import org.apache.commons.cli2.OptionException; import org.apache.commons.cli2.builders.ArgumentBuilder; @@ -37,6 +36,7 @@ import
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/jdepend JDependTest.java
roxspring2004/03/30 16:53:18
Modified:cli/src/test/org/apache/commons/cli2/jdepend Tag:
RESEARCH_CLI_2_ROXSPRING JDependTest.java
Log:
Distance threshold raised from 0.2 to 0.21 to cover current packaging structure
Revision ChangesPath
No revision
No revision
1.1.2.6 +3 -2
jakarta-commons/cli/src/test/org/apache/commons/cli2/jdepend/Attic/JDependTest.java
Index: JDependTest.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/jdepend/Attic/JDependTest.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- JDependTest.java 24 Feb 2004 02:01:40 - 1.1.2.5
+++ JDependTest.java 31 Mar 2004 00:53:18 - 1.1.2.6
@@ -65,9 +65,10 @@
for (final Iterator i = packages.iterator(); i.hasNext();) {
final JavaPackage pkg = (JavaPackage)i.next();
final float distance = pkg.distance();
+final String message = pkg.getName() + too far from line: +
distance;
assertTrue(
-pkg.getName() + too far from line: + distance,
-distance 0.20d);
+message,
+distance 0.21d);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [vote] Release Commons-Net 1.2
On Tuesday 30 March 2004 9:46 am, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Ga ry Gregory writes: the The Apache Software License - the Apache Software License Apache Software License should be just Apache License All the nits have been picked :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Now that all the nits have been fixed and the vote is in, I will plan to get the release out early next week, when I'll have some free time. The only other remaining issue I see is getting something into the docs as Jeff suggests about autodection not working in the case of an NT server with DIRSTYLE set to unix and how to work around this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [vote] Release Commons-Net 1.2
Maybe we're wrong to rely exclusively on the SYST command. Jeff, since you
evidently have admin access to an NT FTP server, maybe you can find a quick
way to distinguish between an NT server in Unix DIRSTYLE mode and one in NT
mode. LIke maybe the header information uses different text or something.
Maybe we could have something like this:
if Windows == syst() result {
// do a list command just to look at the header
if header is unix style return unix
else return windows.
}
If not, we can always go the FAQ route.
Steve
On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
Here on a Windows2003 server toggling the DIRSTYLE doesn't change the
output of the SYS command. It still reports Windows NT 5.0, so if the
MSDOS dirstyle is off, then the wrong parser will get autoselected. I
guess we could put this in the FAQ or something with some examples
maybe.
On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen
[EMAIL PROTECTED] said:
I think you may be referring to something said by a user last week,
in which he solved the problem by configuring his NT FTP server to
use the Unix display format. I didn't know before that that was
an option. What I still don't know is if one takes that option,
does the SYST command return Windows or Unix? If it's the
former, then we have a problem. It's not an unsolvable problem
because you can always use the form of listFiles() that takes a
parser class name or a different SYST value (e.g. listFiles(UNIX)
) as a parameter, although you can't at present do this from Ant.
(But adding this capability to Ant is what I'm striving towards.)
A little investigation would be good here. But we need to remember
the point of autodetection. It's not foolproof, can't be foolproof,
since it depends on SYST identification which is not necessarily
cast in stone. It is an attempt to raise the default success rate
of using listFiles() out of the box from maybe 90% to 98%, by
autodetecting other cases, the most common of which is Windows but
also OS2, VMS, OS400, etc. So while we need to strive to become as
good as possible, I don't think we'll ever hit 100%. FTP is too
loosely specced for that to happen.
Default falling back to unix if other methods fail would involve a
much more complex mechanism in which the program would have to
decide (this isn't working) and try something else. While I
wouldn't totally rule that out, I don't at present feel there is
enough solid information to justify that effort.
On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
+1
2. Autodetection of system type - a BIG feature for the Ant user
community and others. We missed the last Ant release and I'd
like not to miss another.
There is a littly thing whe should try to enhance in the future.
Using Windows for the NTFTPEntryParser is too strict as it might
depend on a directory listing format which is configureable.
Maybe a automatic fallback to UnixFTPEntryParser might help here?
-- Mario
-
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]
[all] Maven RC-2 Clover problem
I'm resending this message with a broader than [codec] subject since it is more about Maven and Clover (I suppose) in the hope that this has been noticed and resolved by someone else. Thank you, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 14:51 To: Jakarta Commons Developers List Subject: [maven][codec] Maven RC-2 Clover problem Hello, I installed Maven RC-2 and when I now run a [codec] build with maven clean site:generate, the build works once, but not twice. During the 2nd (last) invocation of: java:jar-resources: Copying 264 files to C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes Some kind of loop or self reference takes place such that a deep nested and undeletable dir structure is created: C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\clover Etc... On and on for a couple hundre C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target\clover\classes\target\classes\target\clover\classes\targe t\clover d entries. Help! Thank you, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] Status of 1.3 Release
Also: resolve the Maven RC2 and Clover problem I just encountered. Can anyone else duplicate this? Alex, feel free to help in any and all areas. Unfortunately, I cannot take the time to complete the new Codec unit tests. Thank you, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 14:26 To: Jakarta Commons Developers List Subject: RE: [codec] Status of 1.3 Release Hello, I think we are pretty close. To do: - Get 100% Clover unit test coverage on the new classes BCodec and QCodec. - Scan the Bugzilla database for unresolved issues and if any issues exist, discuss if they should be addressed now or later. - Complete the RELEASE-NOTES.txt file, in particular note new features and bugs fixed. - Add a JDiff report to the build. Gary -Original Message- From: Alex Karasulu [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 11:51 To: 'Jakarta Commons Developers List' Subject: [codec] Status of 1.3 Release Gary, When do you think the 1.3 release will be ready? Is there anything I can give you a hand with? Alex - 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: [VOTE] [Validator] Validator 1.1.2 release
Martin Cooper wrote: --- Vote: Commons Validator 1.1.2 Release [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason) --- Here is my +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Some changes to Polynomial
0. To help debug the SplineInterpolater (PR #28019 et al), I need to
expose the coefficients in o.a.c.m.analysis.Polynomial as a read-only
property (returning an array copy). Any objections to adding this?
While reviewing the code, I also noticed that the current impl uses
naive evaluation (using Math.pow, etc.). I would like to change this to
use Horner's Method. Here is what I have ready to commit:
1. Add protected static double evaluate(double[] coefficients, double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
2. Add protected static double[] differentiate(double[] coefficients) to
return the coefficients of the derivative of the polynomial with
coefficients equal to the actual parameter. Then change
firstDerivative(x) to just return
evaluate(differentiate(coefficients), x). Similar for secondDerivative.
I could adapt Horner for the derivatives, but that seems messy to me and
the slight memory cost to create the temp arrays seems worth it.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Any objections to this?
Interestingly, while Horner's method should give better numerics, it
actually fails to get within 1E-15 for one of the quintic test cases,
performing worse than the naive impl. The error is in the 16th
significant digit, which is not surprising. I would like to change the
tolerance to 1E-12 (current tests actually succeed at 1E-14).
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/conf/share validator_1_1_2.dtd
rleland 2004/03/30 20:45:51
Modified:validator/conf/share validator_1_1_2.dtd
Log:
Remove unused/unimplemented disable attribute.
Revision ChangesPath
1.2 +1 -7 jakarta-commons/validator/conf/share/validator_1_1_2.dtd
Index: validator_1_1_2.dtd
===
RCS file: /home/cvs/jakarta-commons/validator/conf/share/validator_1_1_2.dtd,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- validator_1_1_2.dtd 3 Feb 2004 00:38:16 - 1.1
+++ validator_1_1_2.dtd 31 Mar 2004 04:45:51 - 1.2
@@ -44,11 +44,6 @@
It can be overridden by the 'msg' element for a specific
field.
depends The comma-delimited list of validator that are called
before this validator.
For this validation to succeed, all the listed validators
must succeed.
- disable Disable validation on client, server, or both. possible
values: {|client|server}.
- The default is for validation to occur on both the client
and server.
- A comma must be used to separate the list e.g.
client,server if both client
- and server validation is disabled. If this validation is
listed in the depends
- of another validation the disabled validation will be
treated as if it passed.
jsFunctionName The name of the javascript function which returns all
fields of a certain type.
jsFunction The name of the javascript function which is passed the
form for validation.
@@ -60,7 +55,6 @@
!ATTLIST validator methodParams CDATA #REQUIRED
!ATTLIST validator msg CDATA #REQUIRED
!ATTLIST validator depends CDATA #IMPLIED
-!ATTLIST validator disable CDATA #IMPLIED
!ATTLIST validator jsFunctionName CDATA #IMPLIED
!ATTLIST validator jsFunction CDATA #IMPLIED
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
On Tue, 30 Mar 2004 21:29:42 -0700, Phil Steitz wrote:
0. To help debug the SplineInterpolater (PR #28019 et al), I need to
expose the coefficients in o.a.c.m.analysis.Polynomial as a
read-only
property (returning an array copy). Any objections to adding this?
1. Add protected static double evaluate(double[] coefficients,
double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
+1
2. Add protected static double[] differentiate(double[] coefficients)
to
return the coefficients of the derivative of the polynomial with
coefficients equal to the actual parameter. Then change
firstDerivative(x) to just return
evaluate(differentiate(coefficients), x). Similar for
secondDerivative.
I could adapt Horner for the derivatives, but that seems messy to me
and
the slight memory cost to create the temp arrays seems worth it.
+1 on the differntiate method.
Are the firstDerivate and secondDerivative methods needed anymore with
the addition of your derivative method below? I would favor removing
the prior two methods if possible.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
Counter thoughts?
Brent Worden
http://www.brent.worden.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven][codec] Maven RC-2 Clover problem
Gary Gregory [EMAIL PROTECTED] wrote on 31/03/2004 08:51:23 AM: Hello, I installed Maven RC-2 and when I now run a [codec] build with maven clean site:generate, the build works once, but not twice. During the 2nd (last) invocation of: java:jar-resources: Copying 264 files to C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes Some kind of loop or self reference takes place such that a deep nested and undeletable dir structure is created: C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ classes\target C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes\src\ Somewhere in your resources or another definition, you're including ** in a list of files to be copied. This copies everything, including target/ into target/ which will eventually die horribly. -- dIon Gillard, Multitask Consulting
Re: [math] Some changes to Polynomial
--- Phil Steitz [EMAIL PROTECTED] wrote:
0. To help debug the SplineInterpolater (PR #28019 et al), I need to
expose the coefficients in o.a.c.m.analysis.Polynomial as a read-only
property (returning an array copy). Any objections to adding this?
+1 if you do it by adding a package-level-accessible (i.e., no access modifier
keyword; the JUnit test would be able to access it by being in the same
package) getter method -- which sounds like what you're proposing.
While reviewing the code, I also noticed that the current impl uses
naive evaluation (using Math.pow, etc.). I would like to change this to
use Horner's Method. Here is what I have ready to commit:
1. Add protected static double evaluate(double[] coefficients, double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
2. Add protected static double[] differentiate(double[] coefficients) to
return the coefficients of the derivative of the polynomial with
coefficients equal to the actual parameter. Then change
firstDerivative(x) to just return
evaluate(differentiate(coefficients), x). Similar for secondDerivative.
I could adapt Horner for the derivatives, but that seems messy to me and
the slight memory cost to create the temp arrays seems worth it.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Any objections to this?
+1, these sound reasonable.
Interestingly, while Horner's method should give better numerics, it
actually fails to get within 1E-15 for one of the quintic test cases,
performing worse than the naive impl. The error is in the 16th
significant digit, which is not surprising. I would like to change the
tolerance to 1E-12 (current tests actually succeed at 1E-14).
Phil
I wonder why that is? Does Math.pow() use higher-than-double precision and
then cast down to double? I think we should consider carefully what is implied
by the fact that Horner's method has worse precision. Also, I would in
principle like to leave the tolerance as tight as possible, 1E-14 in this case.
Al
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Flattening trees
Oliver Heger wrote on Tuesday, March 30, 2004 9:25 PM: Definately, but post 1.0. I think you will be able to remove a lot of code with a real generic solution. For 1.0 we will have to modify the Configuration interface at least in a way, we can solve the problem with HierarchicalConfiguration and Oliver had a solution for this (making Configuration hierarchical arware). Regards, Jörg Unfortunately I won't have time prior to Thursday evening. Can you tell me which unit tests are failing? If it's only the test for ConfigurationXMLDocument, I would suggest to drop this class in the 1.0 release and add it later again (I think it is unlikely that this class is already used; it was lost after the move from sandbox and nobody noticed). Other tests should not fail because they still worked after the SubConfiguration refactoring. Yes. It is the same old story. If we start thinking about more support for hierarchical configurations (an approach I really welcome), I now don't want to come up with a quick solution for the actual problem. It would be much better to do it right in the next release. Fine with me. I would be glad to get 1.0 out of the door and do the hierarchy refactoring/integration for 1.1 Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
--- [EMAIL PROTECTED] wrote:
On Tue, 30 Mar 2004 21:29:42 -0700, Phil Steitz wrote:
0. To help debug the SplineInterpolater (PR #28019 et al), I need to
expose the coefficients in o.a.c.m.analysis.Polynomial as a
read-only
property (returning an array copy). Any objections to adding this?
1. Add protected static double evaluate(double[] coefficients,
double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
+1
2. Add protected static double[] differentiate(double[] coefficients)
to
return the coefficients of the derivative of the polynomial with
coefficients equal to the actual parameter. Then change
firstDerivative(x) to just return
evaluate(differentiate(coefficients), x). Similar for
secondDerivative.
I could adapt Horner for the derivatives, but that seems messy to me
and
the slight memory cost to create the temp arrays seems worth it.
+1 on the differntiate method.
Are the firstDerivate and secondDerivative methods needed anymore with
the addition of your derivative method below? I would favor removing
the prior two methods if possible.
+1 to Brent's suggestion. These methods seem very redundant now, and I never
really liked naming these explicitly, as they seem to beg for derivatives of
all orders to then be named explicitly as well.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
Counter thoughts?
Brent Worden
http://www.brent.worden.org/
That seems pretty reasonable. Should we at least briefly explore what
multivariable differentiation would look like and see if that makes it clearer
what it should look like with a single variable?
For instance, a UnivariateRealFunction can be considered a special case of a
ScalarRealFunction (I thought about writing MultivariateRealFunction there, but
semantically it seems wrong to call Univariate... a special case of
Multivariate...). For a RealFunction of n variables, the quintessential
derivatives are the first partial derivatives with respect to each of the n
variables, from which the gradient and other del-operator-based vector
functions spring. For second derivatives we quickly generate the matrix of all
mixed partial derivatives.
Where is this leading? I guess one direction might be an interface containing
a differentiate() method that calculates a first derivative, which in n
dimensions would require the user to specify which of the n variables to
differentiate with respect to, but in one dimension would not, for obvious
reasons. So I guess the Brent's suggestion holds, and the generalization to
more dimensions would be
public ScalarRealFunction derivative(Variable x) {
// implementation of first derivative with respect to x
}
I don't care to tackle vector functions of any number of variables at the
moment. g
Al
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Encountering problems with httpclient
Dear all, Need some help here. I am sending many xml to a IIS webserver using the same Httpclient object same PostMethod object to sent. Wheneven I sent xmls within intervals of less than 2 secs, the following exceptions occurred : = Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase readResponse INFO: Discarding unexpected response: HTTP/1.1 100 Continue Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase processRequest WARNING: Recoverable exception caught but MethodRetryHandler.retryMethod() returned false, rethrowing exception org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketTimeoutException: Read timed out at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1965) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2659) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) = Pls help. Thanks Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encountering problems with httpclient
Hi Paul, Sounds like you are using an older version of HttpClient. I suggest upgrading to 2.0. Mike On Mar 30, 2004, at 9:52 PM, paul wrote: Dear all, Need some help here. I am sending many xml to a IIS webserver using the same Httpclient object same PostMethod object to sent. Wheneven I sent xmls within intervals of less than 2 secs, the following exceptions occurred : = Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase readResponse INFO: Discarding unexpected response: HTTP/1.1 100 Continue Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request Mar 31, 2004 10:19:36 AM org.apache.commons.httpclient.HttpMethodBase processRequest WARNING: Recoverable exception caught but MethodRetryHandler.retryMethod() returned false, rethrowing exception org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketTimeoutException: Read timed out at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBas e.java:1965) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodB ase.java:2659) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.jav a:1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 529) = Pls help. Thanks Paul - 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]
