RE: [VOTE][EMAIL] Release Commons-Email 1.0
--- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 6:09 PM To: Commons-Dev Subject: [VOTE][EMAIL] Release Commons-Email 1.0 Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/ ~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - 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 32530] New: - Expressions with conditionals and unprefixed functions do not alway parse
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=32530.
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=32530
Summary: Expressions with conditionals and unprefixed functions
do not alway parse
Product: Commons
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: major
Priority: P2
Component: EL
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If you take a el expression of the form :
${true ? a : reverse(Foo)}
The commons el parser will fail to parse this.
The ambiguity between the Conditional rule and the Function rule (both using :
as a token) seems to cause the parser problems.
Here is a jsp that can be used to easily verify this :
[EMAIL PROTECTED] contentType=text/html%
html
body
%
String expr = ${true ? a : reverse(\Foo\)};
try {
pageContext.getExpressionEvaluator().parseExpression(expr,
java.lang.String.class,
null);
out.println(Parsed + expr);
}
catch (javax.servlet.jsp.el.ELException e) {
out.println(Failed to parsed + expr + : + e.getMessage());
}
%
/body
/html
Just by adding a prefix to the function or changing the true condition to
something other than a value will make it parse.
--
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] Push for 1.3.0 release
Hi Steve, I'm just going from memory here, but I believe that there was a small issue in 1.2.2 where files with a timestamp of 00:xx or 0:x weren't being picked up properly. This issue is fixed in HEAD, I think you committed a fix some while back. Cheers, Rory Steve Cohen wrote: I, too, am inclined to be +1 on this, but I have one question I'd like you to answer first, Rory. What are the minor date handling issues fixed in FTPClient as opposed to the major enhancement which I suppose is the design issue I started here a couple of months ago? (And haven't continued because I didn't have the time). I may be available to help a little on the release but I am glad to see you take the lead on this because I don't have that kind of time these days. If there's anything you'd like me to help you with, let me know and I'll see what I can do. On Friday 03 December 2004 10:15 am, Rory Winston wrote: I started a thread re: this a few weeks back, but didn't get any replies, so here goes again... I think we should push out a 1.3.0 release pre-xmas. There are many, many enhancements and fixes, and also a new component in HEAD. Some of the highlights: * Many javadoc fixes (mostly courtesy of Daniel) * A new SNTP/NTP component * Some minor date handling issues in FTPClient * Configurable buffer size for FTP data transfers * The addition of message threading to NNTPClient * Consistency in the way we handle encoding in FTP * Some fixes to build.xml * Minor fixes to TFTP * A suite of POP3 tests * Some changes to facilitate compilation under Java 5.0 * Fix for TelnetClient zombie thread issue And there are more, but this is mainly it. I think this is more than enough to qualify for a release - the major outstanding enhancement (date handling functionality in FTPClient), we should save till the next release - its going to take a good deal of time. Let's get this one out! Cheers, Rory _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - 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: [beanutils] PropertyUtils DynaBeans
Niall, What looks pretty clear is that YOU do not know what he is talking about. On caching: he is only talking about caching introspection information, not the actual beans. Go and study what the DynaBean/DynaClass implementations are all about. Do your home work if you really care about them. Regards, Paulo Gaspar Niall Pemberton wrote: Maybe you could spell out the issues with PropertyUtils and DynaBeans and the methods involved and what you're trying to do because its not clear what your trying to resolve. I'm don't see much value in the getDynaProperties() method being in PropertyUtils - all you need to do is make eveything a DynaBean then you can get the DynaProperties and do whatever you want using the existing DynaBean/DynaClass methods - no need for PropertyUtils at all. DynaBean dynaBean = (bean instanceof DynaBean) ? (DynaBean)bean : new WrapDynaBean(bean); For caching to work people are going to have to change how they create DynaBeans and I believe its better left up to the environment they're being used in to implement a caching mechanism - Struts does this for its DynaActionForm implementation. Niall - Original Message - From: Kris Nuttycombe [EMAIL PROTECTED] To: Commons Developers Jakarta [EMAIL PROTECTED] Sent: Saturday, December 04, 2004 12:55 AM Subject: [beanutils] PropertyUtils DynaBeans Hi, all, As it currently stands, PropertyUtils doesn't support DynaBeans for a number of its methods. It doesn't make much sense to return PropertyDescriptors for DynaBeans, but it's no great pain to use WrapDynaClass on an ordinary class and thereby be able to introspect either regular beans or DynaBeans using the same interface. To support this, I'd like to add a method with the signature: DynaProperty[] getDynaProperties(Object bean) to PropertyUtilsBean, with a corresponding static method in PropertyUtils. Now, one of the other advantages of using PropertyUtilsBean is that it caches the introspected data. Conceivably, this would also be a useful feature for the getDynaProperties method. However, here we have a problem: since DynaClass doesn't have any way to enforce that its implementations implement HashCode, there's no way to use the same map caching strategy as is used for the PropertyDescriptors. This illustrates a larger issue, which is that DynaClass objects aren't singletons like Class objects are. To resolve this, I propose adding an AbstractDynaClass base class that implements hashCode() and equals() based upon the public methods available in DynaClass. This way, even if DynaClasses aren't singletons, they can be used for hash keys. It might be also useful to implement a registry for DynaClasses in this abstract class to provide singleton-like functionality. Existing DynaClass implementations would be modified to extend AbstractDynaClass. Any thoughts? Kris - 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/configuration/src/test/org/apache/commons/configuration/reloading TestFileChangedReloadingStrategy.java
oheger 2004/12/04 07:45:40
Modified:configuration/src/test/org/apache/commons/configuration
TestPropertiesConfiguration.java
TestConfigurationUtils.java
TestFileConfiguration.java
configuration/src/java/org/apache/commons/configuration
PropertiesConfiguration.java
ConfigurationUtils.java
AbstractFileConfiguration.java
configuration/src/java/org/apache/commons/configuration/reloading
FileChangedReloadingStrategy.java
configuration/src/test/org/apache/commons/configuration/reloading
TestFileChangedReloadingStrategy.java
Log:
Fix for Bug 30858, including some cleanup for file based configurations
Revision ChangesPath
1.17 +20 -1
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java
Index: TestPropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- TestPropertiesConfiguration.java 14 Nov 2004 18:29:02 - 1.16
+++ TestPropertiesConfiguration.java 4 Dec 2004 15:45:39 - 1.17
@@ -152,6 +152,25 @@
//good
}
}
+
+/**
+ * Tests if the base path is taken into account by the save() method.
+ * @throws Exception if an error occurs
+ */
+public void testSaveWithBasePath() throws Exception
+{
+// remove the file previously saved if necessary
+if (testSavePropertiesFile.exists())
+{
+assertTrue(testSavePropertiesFile.delete());
+}
+
+conf.setProperty(test, true);
+
conf.setBasePath(testSavePropertiesFile.getParentFile().toURL().toString());
+conf.setFileName(testSavePropertiesFile.getName());
+conf.save();
+assertTrue(testSavePropertiesFile.exists());
+}
public void testLoadViaProperty() throws Exception
{
1.9 +13 -1
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
Index: TestConfigurationUtils.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationUtils.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestConfigurationUtils.java 19 Oct 2004 13:41:44 - 1.8
+++ TestConfigurationUtils.java 4 Dec 2004 15:45:39 - 1.9
@@ -171,4 +171,16 @@
expected.add(value2);
ListAssert.assertEquals('key2' property, expected,
conf2.getList(key2));
}
+
+public void testGetFile() throws Exception
+{
+File directory = new File(target);
+File reference = new File(directory, test.txt).getAbsoluteFile();
+
+assertEquals(reference, ConfigurationUtils.getFile(null,
reference.getAbsolutePath()));
+assertEquals(reference,
ConfigurationUtils.getFile(directory.getAbsolutePath(),
reference.getAbsolutePath()));
+assertEquals(reference,
ConfigurationUtils.getFile(directory.getAbsolutePath(), reference.getName()));
+assertEquals(reference,
ConfigurationUtils.getFile(directory.toURL().toString(), reference.getName()));
+assertEquals(reference, ConfigurationUtils.getFile(invalid,
reference.toURL().toString()));
+}
}
1.3 +77 -4
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestFileConfiguration.java
Index: TestFileConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestFileConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestFileConfiguration.java19 Nov 2004 13:19:50 - 1.2
+++ TestFileConfiguration.java4 Dec 2004 15:45:39 - 1.3
@@ -33,15 +33,39 @@
FileConfiguration config = new PropertiesConfiguration();
config.setURL(new
URL(http://jakarta.apache.org/commons/configuration/index.html;));
-assertEquals(base path,
http://jakarta.apache.org/commons/configuration/;, config.getBasePath());
+assertEquals(base path,
http://jakarta.apache.org/commons/configuration/;, config
+.getBasePath());
assertEquals(file name, index.html, config.getFileName());
// file URL
cvs commit: jakarta-commons/configuration/xdocs changes.xml
oheger 2004/12/04 07:54:07 Modified:configuration/xdocs changes.xml Log: Fix for Bug 30858, including some cleanup for file based configurations Revision ChangesPath 1.75 +4 -0 jakarta-commons/configuration/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- changes.xml 3 Dec 2004 02:07:18 - 1.74 +++ changes.xml 4 Dec 2004 15:54:07 - 1.75 @@ -8,6 +8,10 @@ body release version=1.1-dev date=in CVS + action dev=oheger type=fix issue=30858 + Some cleanup of the handling of the base path in file based configurations. + The base path is now always taken into account. + /action action dev=ebourg type=fix Calling getProperties on a JNDIConfiguration no longer throws an UnsupportedOperationException. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration JNDIConfiguration.java
oheger 2004/12/04 07:54:55 Modified:configuration/src/java/org/apache/commons/configuration JNDIConfiguration.java Log: Fixed an Eclipse warning about a non used import Revision ChangesPath 1.24 +1 -2 jakarta-commons/configuration/src/java/org/apache/commons/configuration/JNDIConfiguration.java Index: JNDIConfiguration.java === RCS file: /home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/JNDIConfiguration.java,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- JNDIConfiguration.java3 Dec 2004 02:07:18 - 1.23 +++ JNDIConfiguration.java4 Dec 2004 15:54:55 - 1.24 @@ -20,7 +20,6 @@ import java.util.HashSet; import java.util.Iterator; import java.util.List; -import java.util.Properties; import java.util.Set; import javax.naming.Context; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration/reloading TestFileChangedReloadingStrategy.java
Argh my URL, I would have prefered to keep it :(
/**
* Return the URL where the configuration is stored.
+ *
+ * @return the configuration's location as URL
*/
public URL getURL()
{
-return url;
+return ConfigurationUtils.locate(getBasePath(),
getFileName());
}
I'm not sure it's a good thing to locate the ressource on every call to
getURL, that means the URL returned may not match the actual URL used to
load the configuration (if the file is removed for example).
Emmanuel Bourg
[EMAIL PROTECTED] wrote:
oheger 2004/12/04 07:45:40
Modified:configuration/src/test/org/apache/commons/configuration
TestPropertiesConfiguration.java
TestConfigurationUtils.java
TestFileConfiguration.java
configuration/src/java/org/apache/commons/configuration
PropertiesConfiguration.java
ConfigurationUtils.java
AbstractFileConfiguration.java
configuration/src/java/org/apache/commons/configuration/reloading
FileChangedReloadingStrategy.java
configuration/src/test/org/apache/commons/configuration/reloading
TestFileChangedReloadingStrategy.java
Log:
Fix for Bug 30858, including some cleanup for file based configurations
Revision ChangesPath
1.17 +20 -1 jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java
Index: TestPropertiesConfiguration.java
===
RCS file: /home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- TestPropertiesConfiguration.java 14 Nov 2004 18:29:02 - 1.16
+++ TestPropertiesConfiguration.java 4 Dec 2004 15:45:39 - 1.17
@@ -152,6 +152,25 @@
//good
}
}
+
+/**
+ * Tests if the base path is taken into account by the save() method.
+ * @throws Exception if an error occurs
+ */
+public void testSaveWithBasePath() throws Exception
+{
+// remove the file previously saved if necessary
+if (testSavePropertiesFile.exists())
+{
+assertTrue(testSavePropertiesFile.delete());
+}
+
+conf.setProperty(test, true);
+conf.setBasePath(testSavePropertiesFile.getParentFile().toURL().toString());
+conf.setFileName(testSavePropertiesFile.getName());
+conf.save();
+assertTrue(testSavePropertiesFile.exists());
+}
public void testLoadViaProperty() throws Exception
{
1.9 +13 -1 jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
Index: TestConfigurationUtils.java
===
RCS file: /home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationUtils.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestConfigurationUtils.java 19 Oct 2004 13:41:44 - 1.8
+++ TestConfigurationUtils.java 4 Dec 2004 15:45:39 - 1.9
@@ -171,4 +171,16 @@
expected.add(value2);
ListAssert.assertEquals('key2' property, expected, conf2.getList(key2));
}
+
+public void testGetFile() throws Exception
+{
+File directory = new File(target);
+File reference = new File(directory, test.txt).getAbsoluteFile();
+
+assertEquals(reference, ConfigurationUtils.getFile(null, reference.getAbsolutePath()));
+assertEquals(reference, ConfigurationUtils.getFile(directory.getAbsolutePath(), reference.getAbsolutePath()));
+assertEquals(reference, ConfigurationUtils.getFile(directory.getAbsolutePath(), reference.getName()));
+assertEquals(reference, ConfigurationUtils.getFile(directory.toURL().toString(), reference.getName()));
+assertEquals(reference, ConfigurationUtils.getFile(invalid, reference.toURL().toString()));
+}
}
1.3 +77 -4 jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestFileConfiguration.java
Index: TestFileConfiguration.java
===
RCS file: /home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestFileConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestFileConfiguration.java 19 Nov 2004 13:19:50 - 1.2
+++ TestFileConfiguration.java 4 Dec 2004 15:45:39 - 1.3
@@ -33,15
DO NOT REPLY [Bug 30858] - [configuration] PropertyConfiguration.save() does not take basePath into account
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=30858. 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=30858 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-04 17:07 --- I have performed a little cleanup on the way the base path was handled. The internal url field was removed. I added some more tests and improved the javadoc. The unit tests all run, but I had a problem with the test for FileChangedReloadingStrategy: To get it running after the modifications I had to increase the sleep interval in testAutomaticReloading(). Don't know why, but on my old and slow Linux box this test was also sometimes failing before the update. The tests indicate that the problem is now solved (refer to TestFileConfiguration). So I mark this bug as fixed. Feel free to reopen if there are still issues. -- 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: [Validator] Plans for Validator 1.2 and beyond
Niall, Sounds great. +1 Cheers, Rory Niall Pemberton wrote: I'd like to propose that we target a Validator 1.2 release in the next couple of months. I have three motivations for this: 1) I'd like it to include the JavaScript Extension I've proposed in Bug #32343 and along with inheritance and a couple of other features think it would make a great release. 2) Seems that over on the Struts Dev list people are chomping at the bit to start work on Struts 1.3 and IMO it would be good to get a Validator 1.2 out of the door so that Struts 1.3 can take adavantage of a released Validator 1.2 version early in its development cycle. Compared to previous experiences with Struts Validator, this would put us ahead of the game, allowing Validator to be well bedded in before a Struts 1.3 releasee. 3) Once Validator 1.2 is out of the door, we can throw the baby out with the bath water and plunge into Validator 2.0 - yeah! If people buy into this, then the next step is to agree the scope of whats going to be in a 1.2 release. My thoughts are the following 1) Inheritance (Already Implemented) === http://issues.apache.org/bugzilla/show_bug.cgi?id=27870 I believe this is currently the only major difference between Validator 1.2 and Validator 1.1.4 - I haven't yet had time to test out Validator 1.2 - but plan to do so shortly. This is a great feature though and I'm sure would be greatly appreciated in a release by the user community. 2) JavaScript Extension == http://issues.apache.org/bugzilla/show_bug.cgi?id=32343 I just posted a 1.0.8 version which I hope is pretty close to being ready for inclusion in Validator - following feedback from a few people. The one concern I have is that until recently I didn't know much about JavaScript and as well as adding the dynamic JavaScript generation I've done wholesale refactoring of the existing static JavaScript Validators. No ones posted -ve feedback yet on the JavaScript and I'm hoping that people who've had a look at it are a. know JavaScript well and b. have looked closely at what I've done. Unless people object or want more time to consider/evaluate this, I plan to add this in next week or so - although there needs to be some discussion about how it should be integrated first (I will give ample warning before I actually do anything). As a side benefit, I believe the following will also be resolved when/if this is included: http://issues.apache.org/bugzilla/show_bug.cgi?id=21043 http://issues.apache.org/bugzilla/show_bug.cgi?id=23372 http://issues.apache.org/bugzilla/show_bug.cgi?id=27414 http://issues.apache.org/bugzilla/show_bug.cgi?id=22687 3) Remove arg position= attribute = http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 I had a brain fart when I applied a patch for this and as David Graham pointed out should have been so quick off the mark at putting it in. I have attached a new patch for this a while ago, but no feedback so far. I would like to apply this - any objections? 4) Enable Variables to come From Message Resources = http://issues.apache.org/bugzilla/show_bug.cgi?id=32522 I just posted this and its probably a fairly minor change, but I believe it completes the circle for i18n applications. Currently you can have a i18n application with one formset for messages, but not for the variables. With validators such as mask and date their variables are often locale specific, so IMO this would make life alot easier for i18n. 5) Outstanding Bugs Theres currently 12 outstanding bugs - I believe the JavaScript Extension resolves the following http://issues.apache.org/bugzilla/show_bug.cgi?id=14471 http://issues.apache.org/bugzilla/show_bug.cgi?id=30872 http://issues.apache.org/bugzilla/show_bug.cgi?id=31534 http://issues.apache.org/bugzilla/show_bug.cgi?id=31790 From a quick review of the rest the ones IMO that initially look like they need to be addressed are http://issues.apache.org/bugzilla/show_bug.cgi?id=29541 http://issues.apache.org/bugzilla/show_bug.cgi?id=30686 http://issues.apache.org/bugzilla/show_bug.cgi?id=30955 http://issues.apache.org/bugzilla/show_bug.cgi?id=31644 Niall - 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: cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration/reloading TestFileChangedReloadingStrategy.java
Hmm, depents on the point of view. No the returned URL is always
consistent with the base path and file name.
As a compromise: How about storing the URL of the last successfull
load() operation and add a method like getCurrentURL() or something that
returns this URL?
Oliver
Emmanuel Bourg wrote:
Argh my URL, I would have prefered to keep it :(
/**
* Return the URL where the configuration is stored.
+ *
+ * @return the configuration's location as URL
*/
public URL getURL()
{
-return url;
+return ConfigurationUtils.locate(getBasePath(),
getFileName());
}
I'm not sure it's a good thing to locate the ressource on every call
to getURL, that means the URL returned may not match the actual URL
used to load the configuration (if the file is removed for example).
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][EMAIL] Release Commons-Email 1.0
-1 Please add NOTICE.txt to all zip files and the jar file. Then you can have a +1 ;-) Stephen - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: Commons-Dev [EMAIL PROTECTED] Sent: Friday, December 03, 2004 5:08 PM Subject: [VOTE][EMAIL] Release Commons-Email 1.0 Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - 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: [chain] add expression evaluation?
I too was unaware of this aspect of Digester (apparently it was added
in the latest release.) I agree with Joe's take that it appears to be
only helpful during the initial parsing of the rules.
I have dealt with something similar myself. Basically I had some XML
template that I wrote to convert into PDF's. We used Apache FOP to do
this but that's not really relevant. The point was that we would have
things in the template that needed to be determined at runtime (such
as a person's name and contact information.)
The way we solved this was using Jakarta's Velocity. Basically we had
a utility class with a method like this:
public static String getText(String template, Map context) throws Exception
{
StringWriter writer = new StringWriter();
// setup velocity
Velocity.init();
VelocityContext velocityContext = new VelocityContext(context);
writer = new StringWriter();
Velocity.evaluate(velocityContext, writer, , template);
return writer.toString();
}
The velocity engine did everything for you. If your text did not have
velocity markup in it, no harm done, it just ignores it. Maybe we
could use something like this. Also, VelocityContext really just
wraps a HashMap, so it might be possible to take advantage of the
chain's Context object.
sean
I hadn't seen that -- and it's very cool!
But a quick look leads me to believe that it would be evaluated only
once, at XML ingestion time, while in the context I'm thinking of,
the value of the expression would be dependent on the runtime state
of the context. With Chain, I think that would be very powerful.
Joe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32530] - [el] Expressions with conditionals and unprefixed functions do not alway parse
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=32530. 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=32530 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Expressions with|[el] Expressions with |conditionals and unprefixed |conditionals and unprefixed |functions do not alway parse|functions do not alway parse -- 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] Push for 1.3.0 release
Rory Winston writes: I think we should push out a 1.3.0 release pre-xmas. There are many, many enhancements and fixes, and also a new component in HEAD. +1 BTW, thanks for all the work you've done going through and addressing all of those issue reports. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FilenameUtils.java
scolebourne2004/12/04 11:28:40
Modified:io/src/test/org/apache/commons/io FilenameUtilsTestCase.java
io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Add equals methods, document Unix/Windows behaviour
Revision ChangesPath
1.23 +23 -1
jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java
Index: FilenameUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- FilenameUtilsTestCase.java27 Nov 2004 17:00:51 - 1.22
+++ FilenameUtilsTestCase.java4 Dec 2004 19:28:40 - 1.23
@@ -451,6 +451,28 @@
}
//---
+public void testEquals() {
+assertEquals(true, FilenameUtils.equals(null, null));
+assertEquals(false, FilenameUtils.equals(null, ));
+assertEquals(false, FilenameUtils.equals(, null));
+assertEquals(true, FilenameUtils.equals(, ));
+assertEquals(true, FilenameUtils.equals(file.txt, file.txt));
+assertEquals(WINDOWS, FilenameUtils.equals(file.txt, FILE.TXT));
+assertEquals(false, FilenameUtils.equals(a\\b\\file.txt,
a/b/file.txt));
+}
+
+public void testEqualsNormalized() {
+assertEquals(true, FilenameUtils.equalsNormalized(null, null));
+assertEquals(false, FilenameUtils.equalsNormalized(null, ));
+assertEquals(false, FilenameUtils.equalsNormalized(, null));
+assertEquals(true, FilenameUtils.equalsNormalized(, ));
+assertEquals(true, FilenameUtils.equalsNormalized(file.txt,
file.txt));
+assertEquals(WINDOWS, FilenameUtils.equalsNormalized(file.txt,
FILE.TXT));
+assertEquals(true, FilenameUtils.equalsNormalized(a\\b\\file.txt,
a/b/file.txt));
+assertEquals(true, FilenameUtils.equalsNormalized(a\\b\\, a/b));
+}
+
+//---
public void testIsExtension() {
assertEquals(false, FilenameUtils.isExtension(null, (String) null));
assertEquals(false, FilenameUtils.isExtension(file.txt, (String)
null));
1.31 +134 -26
jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java
Index: FilenameUtils.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- FilenameUtils.java27 Nov 2004 17:00:51 - 1.30
+++ FilenameUtils.java4 Dec 2004 19:28:40 - 1.31
@@ -22,6 +22,16 @@
/**
* Utility class that provides methods to manipulate filenames and filepaths.
* p
+ * When dealing with filenames you can hit problems when moving from a
Windows
+ * based development machine to a Unix based production machine.
+ * This class aims to help avoid those problems.
+ * p
+ * Most methods on this class are designed to work the same on both Unix and
Windows.
+ * Both separators (forward and back) are recognised, and both sets of
prefixes.
+ * The comparison methods do differ by machine however, comparing case
insensitive
+ * on Windows and case sensitive on Unix.
+ * See the javadoc of each method for details.
+ * p
* This class defines six components within a filename (example
C:\dev\project\file.txt):
* ul
* lithe prefix - C:\/li
@@ -31,7 +41,9 @@
* lithe base name - file/li
* lithe extension - txt/li
* /ul
- * The class only supports Unix and Windows style names. Prefixes are
matched as follows:
+ * Note that the path of a directory is the parent directory.
+ * p
+ * This class only supports Unix and Windows style names. Prefixes are
matched as follows:
* pre
* Windows style:
* a\b\c.txt -- -- relative
@@ -45,6 +57,8 @@
* ~/a/b/c.txt -- ~/-- current user relative
* ~user/a/b/c.txt -- ~user/-- named user relative
* /pre
+ * Both prefix styles are matched always, irrespective of the machine that
you are
+ * currently running on.
*
* /p
* h3Origin of code/h3
@@ -133,6 +147,9 @@
* A double dot will cause that path segment and the one before to be
removed.
* If the double dot has no parent path segment to work with,
codenull/code
* is returned.
+ * p
+ * The output will be the same on both Unix and Windows except
+ * for the separator character.
* pre
* /foo// -- /foo
* /foo/./ -- /foo
@@ -151,7 +168,7 @@
* ~/foo/../bar
Re: [io] Exact meaning of getPath, esp. on UNIX?
In the end I have just documented this. So the path of a directory is the parent directory, and the path of a filename is the directory that the file is in. I believe the path/prefix/name/normalize/concat methods are done now. Stephen From: Christoph Reck [EMAIL PROTECTED] Any file-system object (file or directory) has a name and a path to it. The simple rule is fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) := FilenameUtils.concat( FilenameUtils.getFullPath( fileNameAndPath ), FilenameUtils.getName( fileNameAndPath ) ) Is this agreable by everyone? Why compicate the matters? Notable is that a directory itself is positioned at a path location. Therefore FilenameUtils.getPath(pathToDirectory).length() pathToDirectory.length() Cheers, Christoph Regards, Paulo Gaspar Stephen Colebourne wrote: I think its best to change it. After all calling getPath() returns a path, but calling getPath() on that result doesn't return the same path, but the parent. If I add a getParent() method, that can cover the existing case of this method. And these name manipulations have to be independent of File objects I reckon. Stephen - Original Message - From: matthew.hawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, November 27, 2004 7:07 PM Subject: Re: [io] Exact meaning of getPath, esp. on UNIX? Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. This method seems to behave the same as the 'dirname' command in Unix. It returns the directory containing the item, whether the item is a file or a folder. - 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] - 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]
[io] Filename case sensitive comparisons
I have added various methods to compare two filenames - isExtension(filename) - equals(filename1, filename2) - equalsNormalized(filename1, filename2) These compare case sensitive on Unix and case insenstive on Windows. Is this OK with everyone? I will fix the Wildcard method to do the same if no-one objects. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Matthew Inger as Commons Committer Re: [Lang] Commit Karma
From: Henri Yandell [EMAIL PROTECTED] Quick vote so that Matthew can work on the code he contributed to Lang. He's a Jakarta committer already, so will just be a case of adding karma. [X] +1 - Fix it (grant him karma!) [ ] -1 - Send a patch Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Net/FrequentlyAskedQuestions
Date: 2004-12-04T11:47:20
Editor: RoryWinston [EMAIL PROTECTED]
Wiki: Jakarta Commons Wiki
Page: Net/FrequentlyAskedQuestions
URL: http://wiki.apache.org/jakarta-commons/Net/FrequentlyAskedQuestions
no comment
Change Log:
--
@@ -123,14 +123,15 @@
The summary is:
-pre
+
Since the Net project uses java.net.Socket under the covers, you have to set
up the Socket settings. If the proxy you are using is a SOCKS4 or SOCKS5
proxy, you can set the following System Properties:
+{{{
System.getProperties().put( socksProxyPort, 1080);
System.getProperties().put( socksProxyHost ,proxy.host.address);
-
+}}}
From what I can tell, 1080 is the default port for SOCKS proxies. The
following site documents many of the networking System Properties available:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Filename case sensitive comparisons
On Sat, 4 Dec 2004 19:41:38 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I have added various methods to compare two filenames - isExtension(filename) - equals(filename1, filename2) - equalsNormalized(filename1, filename2) These compare case sensitive on Unix and case insenstive on Windows. Is this OK with everyone? Looks good to me. Would it be worthwhile to add a method that answers the question are these filenames the same, but different in case?? This wouldn't be useful on Unix, of course, but sometimes in Windows you care about the case. (For example, in a web app, WEB-INF *must* be in upper case.) I will fix the Wildcard method to do the same if no-one objects. Fine with me. -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32531] New: - [math] ChiSquareTest incorrectly rejects tables containing zeros
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=32531. 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=32531 Summary: [math] ChiSquareTest incorrectly rejects tables containing zeros Product: Commons Version: 1.0 Alpha Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Math AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The isNonNegative(long[][] in) function defined in o.a.c.m.inference.ChiSquareTest incorrectly rejects 0 as well as negative counts. This causes 2-way tables containing 0 counts to be incorrectly rejected (methods throw IllegalArgumentException). -- 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: [beanutils] PropertyUtils DynaBeans
OK, you're off my Christmas Card list now Paulo. Niall - Original Message - From: Paulo Gaspar [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, December 04, 2004 3:41 PM Subject: Re: [beanutils] PropertyUtils DynaBeans Niall, What looks pretty clear is that YOU do not know what he is talking about. On caching: he is only talking about caching introspection information, not the actual beans. Go and study what the DynaBean/DynaClass implementations are all about. Do your home work if you really care about them. Regards, Paulo Gaspar Niall Pemberton wrote: Maybe you could spell out the issues with PropertyUtils and DynaBeans and the methods involved and what you're trying to do because its not clear what your trying to resolve. I'm don't see much value in the getDynaProperties() method being in PropertyUtils - all you need to do is make eveything a DynaBean then you can get the DynaProperties and do whatever you want using the existing DynaBean/DynaClass methods - no need for PropertyUtils at all. DynaBean dynaBean = (bean instanceof DynaBean) ? (DynaBean)bean : new WrapDynaBean(bean); For caching to work people are going to have to change how they create DynaBeans and I believe its better left up to the environment they're being used in to implement a caching mechanism - Struts does this for its DynaActionForm implementation. Niall - Original Message - From: Kris Nuttycombe [EMAIL PROTECTED] To: Commons Developers Jakarta [EMAIL PROTECTED] Sent: Saturday, December 04, 2004 12:55 AM Subject: [beanutils] PropertyUtils DynaBeans Hi, all, As it currently stands, PropertyUtils doesn't support DynaBeans for a number of its methods. It doesn't make much sense to return PropertyDescriptors for DynaBeans, but it's no great pain to use WrapDynaClass on an ordinary class and thereby be able to introspect either regular beans or DynaBeans using the same interface. To support this, I'd like to add a method with the signature: DynaProperty[] getDynaProperties(Object bean) to PropertyUtilsBean, with a corresponding static method in PropertyUtils. Now, one of the other advantages of using PropertyUtilsBean is that it caches the introspected data. Conceivably, this would also be a useful feature for the getDynaProperties method. However, here we have a problem: since DynaClass doesn't have any way to enforce that its implementations implement HashCode, there's no way to use the same map caching strategy as is used for the PropertyDescriptors. This illustrates a larger issue, which is that DynaClass objects aren't singletons like Class objects are. To resolve this, I propose adding an AbstractDynaClass base class that implements hashCode() and equals() based upon the public methods available in DynaClass. This way, even if DynaClasses aren't singletons, they can be used for hash keys. It might be also useful to implement a registry for DynaClasses in this abstract class to provide singleton-like functionality. Existing DynaClass implementations would be modified to extend AbstractDynaClass. Any thoughts? Kris - 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: [chain] add expression evaluation?
At 11:51 AM -0500 12/4/04, Sean Schofield wrote: The velocity engine did everything for you. If your text did not have velocity markup in it, no harm done, it just ignores it. Maybe we could use something like this. Also, VelocityContext really just wraps a HashMap, so it might be possible to take advantage of the chain's Context object. Jexl essentially achieves the same thing with less other overhead -- it doesn't need any support for looking up templates on the filesystem or in the classpath because you are using it in a context where you expect to have the template (i.e. expression) as a String already. For what it's worth, the Jexl 1.0 jar file is about a third of the size of the velocity 1.4 jar. If we were to use something more heavyweight, I'd probably prefer a proper scripting language to velocity, along the lines of David's suggestion of Rhino. I applied Jexl to a project at work yesterday and I was again pleased with its simplicity. When I have time, I'll develop a working example for people to check out. Joe PS See http://jakarta.apache.org/commons/jexl/index.html#A%20Brief%20Example -- 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]
cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/stat/inference ChiSquareTestImpl.java
psteitz 2004/12/04 12:47:46
Modified:math/src/java/org/apache/commons/math/stat/inference
ChiSquareTestImpl.java
Log:
Fixed bug in ChiSquareTest isNonNegative function that was incorrectly
rejecting 2-way tables with zero counts.
Fixes PR #32531
Reported by: Hans van der Heijden
Revision ChangesPath
1.11 +2 -2
jakarta-commons/math/src/java/org/apache/commons/math/stat/inference/ChiSquareTestImpl.java
Index: ChiSquareTestImpl.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/stat/inference/ChiSquareTestImpl.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ChiSquareTestImpl.java26 Jun 2004 22:08:02 - 1.10
+++ ChiSquareTestImpl.java4 Dec 2004 20:47:46 - 1.11
@@ -268,7 +268,7 @@
private boolean isNonNegative(long[][] in) {
for (int i = 0; i in.length; i ++) {
for (int j = 0; j in[i].length; j++) {
-if (in[i][j] = 0) {
+if (in[i][j] 0) {
return false;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/stat/inference ChiSquareTestTest.java
psteitz 2004/12/04 12:52:43
Modified:math/src/test/org/apache/commons/math/stat/inference
ChiSquareTestTest.java
Log:
Added test case using 2-way table containing zeros (illustrates PR #32531).
Increased accuracy of target values in one test case.
Revision ChangesPath
1.4 +12 -2
jakarta-commons/math/src/test/org/apache/commons/math/stat/inference/ChiSquareTestTest.java
Index: ChiSquareTestTest.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/stat/inference/ChiSquareTestTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ChiSquareTestTest.java26 Jun 2004 22:09:07 - 1.3
+++ ChiSquareTestTest.java4 Dec 2004 20:52:43 - 1.4
@@ -113,7 +113,7 @@
// Target values computed using R version 1.8.1
long[][] counts = { {40, 22, 43}, {91, 21, 28}, {60, 10, 22}};
-assertEquals( chi-square test statistic, 22.709,
testStatistic.chiSquare(counts), 1E-3);
+assertEquals( chi-square test statistic, 22.709027688,
testStatistic.chiSquare(counts), 1E-9);
assertEquals(chi-square p-value, 0.0001448,
testStatistic.chiSquareTest(counts), 1E-7);
assertTrue(chi-square test reject,
testStatistic.chiSquareTest(counts, 0.0002));
assertTrue(chi-square test accept,
!testStatistic.chiSquareTest(counts, 0.0001));
@@ -179,5 +179,15 @@
new org.apache.commons.math.stat.inference.ChiSquareTestImpl();
double cst = csti.chiSquareTest(exp, obs);
assertEquals(chi-square p-value, 0.0, cst, 1E-3);
+}
+
+/** Contingency table containing zeros - PR # 32531 */
+public void testChiSquareZeroCount() throws Exception {
+// Target values computed using R version 1.8.1
+long[][] counts = { {40, 0, 4}, {91, 1, 2}, {60, 2, 0}};
+assertEquals( chi-square test statistic, 9.67444662263,
+testStatistic.chiSquare(counts), 1E-9);
+assertEquals(chi-square p-value, 0.0462835770603,
+testStatistic.chiSquareTest(counts), 1E-9);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [RESULT] Push for 1.3.0 release
Thanks Daniel! I think that together with my vote, that makes 4 +1's (with the caveat that Steve's may be tentative) from the core committers on [net]. I propose that we aim for a release on or before December 15th. I would preferably like to achieve a release towards the latter half of next week, if there are no objections. Cheers, Rory Daniel F. Savarese wrote: Rory Winston writes: I think we should push out a 1.3.0 release pre-xmas. There are many, many enhancements and fixes, and also a new component in HEAD. +1 BTW, thanks for all the work you've done going through and addressing all of those issue reports. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32531] - [math] ChiSquareTest incorrectly rejects tables containing zeros
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=32531. 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=32531 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-04 21:58 --- Changes to fix this problem have been committed. Thanks to Hans van der Heijden for reporting this bug. -- 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: [vote][math] Release Math 1.0
I was about to close this vote as passed when I got a private email indicating a small but functionally important bug, which I have now fixed (PR #32531, ChiSquareTestImpl was incorrectly rejecting tables containing 0's). Do we need to restart the vote, or can I close it as successful and cut the release? -Phil Phil Steitz wrote: There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. -- Phil Steitz - 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][math] Release Math 1.0
You Rock! My opinion is yes, we can move forward and continue the release. Finding and correcting bugs is part of the process. Expect to see minor releases next year, expect issues we can't see right now. This current phase of stability needs to be captured in a release. Release often, release early, -Mark Phil Steitz wrote: I was about to close this vote as passed when I got a private email indicating a small but functionally important bug, which I have now fixed (PR #32531, ChiSquareTestImpl was incorrectly rejecting tables containing 0's). Do we need to restart the vote, or can I close it as successful and cut the release? -Phil Phil Steitz wrote: There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. -- Phil Steitz - 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 32533] New: - CLI2 Group Parser skips arguments
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=32533. 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=32533 Summary: CLI2 Group Parser skips arguments Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The CLI2 group parser can skip an argument when you have more than one group in a set of arguments. This is caused when the shared iterator over arguments is passed to the GroupImpl.process method. The process method can pull more than one argument from the iterator when the argument belongs to another group but always does a single arguments.previous() on return. I have worked out a patch that will fix most cases but the real fix may be to process arguments in more than one passes. The first pass would burst arguments and associate them with their groups. The argument list then needs to be sorted by group/argument/ordinal and processed to set values, etc. -- 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 32533] - CLI2 Group Parser skips arguments
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=32533. 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=32533 --- Additional Comments From [EMAIL PROTECTED] 2004-12-04 23:36 --- Created an attachment (id=13649) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13649action=view) Allow GroupImpl to ignore arguments for another group This patch allows the GroupImpl to process options that come up during the processing of an unrelated group. For example, if groupA contains option1, groupB and groupC, groupB processing won't cause groupC options to be skipped. This patch is not a complete fix because it will not catch -groupA_arg1 -groupB_arg1 -groupA_arg2 but catches some common cases like -groupA_arg1 -groupB_arg1 grouptB_arg2. -- 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: [beanutils] PropertyUtils DynaBeans
OK, you're off my Christmas Card list now Paulo. =:oD That's the spirit! Maybe your're cool after all... Cheers, Paulo Niall Pemberton wrote: OK, you're off my Christmas Card list now Paulo. Niall - Original Message - From: Paulo Gaspar To: Jakarta Commons Developers List Sent: Saturday, December 04, 2004 3:41 PM Subject: Re: [beanutils] PropertyUtils DynaBeans Niall, What looks pretty clear is that YOU do not know what he is talking about. On caching: he is only talking about caching introspection information, not the actual beans. Go and study what the DynaBean/DynaClass implementations are all about. Do your home work if you really care about them. Regards, Paulo Gaspar Niall Pemberton wrote: Maybe you could spell out the issues with PropertyUtils and DynaBeans and the methods involved and what you're trying to do because its not clear what your trying to resolve. I'm don't see much value in the getDynaProperties() method being in PropertyUtils - all you need to do is make eveything a DynaBean then you can get the DynaProperties and do whatever you want using the existing DynaBean/DynaClass methods - no need for PropertyUtils at all. DynaBean dynaBean = (bean instanceof DynaBean) ? (DynaBean)bean : new WrapDynaBean(bean); For caching to work people are going to have to change how they create DynaBeans and I believe its better left up to the environment they're being used in to implement a caching mechanism - Struts does this for its DynaActionForm implementation. Niall - Original Message - From: Kris Nuttycombe [EMAIL PROTECTED] To: Commons Developers Jakarta [EMAIL PROTECTED] Sent: Saturday, December 04, 2004 12:55 AM Subject: [beanutils] PropertyUtils DynaBeans Hi, all, As it currently stands, PropertyUtils doesn't support DynaBeans for a number of its methods. It doesn't make much sense to return PropertyDescriptors for DynaBeans, but it's no great pain to use WrapDynaClass on an ordinary class and thereby be able to introspect either regular beans or DynaBeans using the same interface. To support this, I'd like to add a method with the signature: DynaProperty[] getDynaProperties(Object bean) to PropertyUtilsBean, with a corresponding static method in PropertyUtils. Now, one of the other advantages of using PropertyUtilsBean is that it caches the introspected data. Conceivably, this would also be a useful feature for the getDynaProperties method. However, here we have a problem: since DynaClass doesn't have any way to enforce that its implementations implement HashCode, there's no way to use the same map caching strategy as is used for the PropertyDescriptors. This illustrates a larger issue, which is that DynaClass objects aren't singletons like Class objects are. To resolve this, I propose adding an AbstractDynaClass base class that implements hashCode() and equals() based upon the public methods available in DynaClass. This way, even if DynaClasses aren't singletons, they can be used for hash keys. It might be also useful to implement a registry for DynaClasses in this abstract class to provide singleton-like functionality. Existing DynaClass implementations would be modified to extend AbstractDynaClass. Any thoughts? Kris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][math] Release Math 1.0
I agree, move forward with the release. In case I forgot to vote before, here's my +0 (my company is releasing a major new version this month, and I'm selling a house and buying another, so I have no time!). Great job getting this release out! Al --- Mark R. Diggory [EMAIL PROTECTED] wrote: You Rock! My opinion is yes, we can move forward and continue the release. Finding and correcting bugs is part of the process. Expect to see minor releases next year, expect issues we can't see right now. This current phase of stability needs to be captured in a release. Release often, release early, -Mark Phil Steitz wrote: I was about to close this vote as passed when I got a private email indicating a small but functionally important bug, which I have now fixed (PR #32531, ChiSquareTestImpl was incorrectly rejecting tables containing 0's). Do we need to restart the vote, or can I close it as successful and cut the release? -Phil Phil Steitz wrote: There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. -- Phil Steitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/jelly-tags tag-project.xml
brett 2004/12/04 20:07:53 Modified:jellyproject.xml jelly/jelly-tags tag-project.xml Added: jellyparent-project.xml Removed: jellycommonDependencies.ent Log: replace entities with inheritence for dependencies Revision ChangesPath 1.157 +6 -13 jakarta-commons/jelly/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/jelly/project.xml,v retrieving revision 1.156 retrieving revision 1.157 diff -u -r1.156 -r1.157 --- project.xml 22 Nov 2004 03:27:47 - 1.156 +++ project.xml 5 Dec 2004 04:07:53 - 1.157 @@ -14,12 +14,9 @@ See the License for the specific language governing permissions and limitations under the License. -- -!DOCTYPE project [ - !-- see file for description -- - !ENTITY commonDeps SYSTEM file:commonDependencies.ent -] project + extendparent-project.xml/extend pomVersion3/pomVersion namecommons-jelly/name idcommons-jelly/id @@ -162,6 +159,11 @@ iddfs/id emaildfs -gt; apache.org/email /developer +developer + nameBrett Porter/name + idbrett/id + email[EMAIL PROTECTED]/email +/developer /developers contributors contributor @@ -293,15 +295,6 @@ /contributor /contributors dependencies - -!-- - the common Maven dependencies for Jelly shared by the core - build and all individual taglib builds. Use this - file to keep all dependency versions in sync. - Does not include CLI (Command Line Interface). --- - commonDeps; - !-- for servlet support -- dependency idservletapi/id 1.1 jakarta-commons/jelly/parent-project.xml Index: parent-project.xml === !-- Copyright 2002,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. -- project !-- TODO: should this inherit commons-build? -- artifactIdcommons-jelly-parent/artifactId dependencies !-- the common Maven dependencies for Jelly shared by the core build and all individual taglib builds. Use this file to keep all dependency versions in sync. Does not include CLI (Command Line Interface). -- dependency idcommons-jexl/id version1.0/version /dependency dependency idxml-apis/id version1.0.b2/version /dependency dependency idcommons-beanutils/id version1.6/version /dependency dependency idcommons-collections/id version2.1/version /dependency dependency idcommons-logging/id version1.0.3/version /dependency dependency iddom4j/id version1.5/version /dependency dependency idjaxen/id version1.1-beta-2/version /dependency dependency idxerces/id version2.2.1/version /dependency /dependencies /project 1.17 +1 -4 jakarta-commons/jelly/jelly-tags/tag-project.xml Index: tag-project.xml === RCS file: /home/cvs/jakarta-commons/jelly/jelly-tags/tag-project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- tag-project.xml 12 Sep 2004 15:15:11 - 1.16 +++ tag-project.xml 5 Dec 2004 04:07:53 - 1.17 @@ -1,8 +1,4 @@ ?xml version=1.0 encoding=UTF-8? -!DOCTYPE project [ - !-- see file for description -- - !ENTITY commonDeps SYSTEM file:../commonDependencies.ent -] !-- Copyright 2002-2004 The Apache Software Foundation @@ -19,6 +15,7 @@ limitations under the License. -- project + extend../parent-project.xml/extend pomVersion3/pomVersion groupIdcommons-jelly/groupId currentVersion1.0-SNAPSHOT/currentVersion - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
