DO NOT REPLY [Bug 33409] New: - [validator: email] inexisting dashes and TLD erroneously accepted
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=33409. 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=33409 Summary: [validator: email] inexisting dashes and TLD erroneously accepted Product: Commons Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Validator AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The org.apache.commons.validator.EmailValidator javadoc even says that the erroneous TLD d- is accepted. Why don't you rule them out? 3 out of 4 test values org.apache.commons.validator.EmailTest.testEmailWithDash() seem to be similarly far from reality w.r.t. their TLDs. Shouldn't this code attempt to comply with - http://www.iana.org/gtld/gtld.htm and - http://www.iana.org/cctld/cctld.htm similarly, [EMAIL PROTECTED] doesn't really appear to exist ever in practice and still validates. see also: Bug 29541 and Bug 31644 -- 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 29541] - [validator] EmailValidator allows apostrophes in domain name
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=29541. 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=29541 --- Additional Comments From [EMAIL PROTECTED] 2005-02-05 10:30 --- see also Bug 31644 and Bug 33409 -- 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 31644] - [validator] JavaScript email validation doesn't accept 4 letter TLDs (.info,.name)
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=31644. 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=31644 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-02-05 10:51 --- the 4 letter TLDs appear to be fixed by commons-validator-1.1.3.jar .museum still fails there. As per Bug 33409, it would be better not to accept arbitrary 4-letter or longer TLDs, but truly implement the IANA TLDs. see also Bug 29541 -- 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 29541] - [validator] EmailValidator allows apostrophes in domain name
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=29541. 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=29541 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Discuss: FeedParser move to Commons Proper...
From: Kevin A. Burton [EMAIL PROTECTED] What I'm worried about this is that we might be a bit early for a top level java project. We only have 3 developers and we haven't done a release yet (because we're prevented from doing one). Yes, probably too early. Is there a pattern of projects moving from the commons to a top level jakarta project? HttpClient is the only one that has tried to go to be a subproject within Jakarta. However it still isn't there, despite it being approved long ago. Also, Jakarta is an odd destination to head for. The ASF board encourages projects to move out of Jakarta and become top level at apache (like Ant, Struts etc) (Note this is controversial with some people) I just want to do whats easy and conventional for now ;) If you believe that you can do a quality 0.5 release now then you are probably OK for commons promotion. However, you may need to advertise a possible package rename if you intend to move out of commons longer term. Also, read the commons charter and see if you think feedparser fits. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Discuss: FeedParser move to Commons Proper...
On Sat, 2005-02-05 at 10:45 +, Stephen Colebourne wrote: From: Kevin A. Burton [EMAIL PROTECTED] snip Is there a pattern of projects moving from the commons to a top level jakarta project? HttpClient is the only one that has tried to go to be a subproject within Jakarta. However it still isn't there, despite it being approved long ago. The sole reason HttpClient is not currently seen as present at the Jakarta level is our intention to release HttpClient 3.0 out of Jakarta Commons in order to avoid confusion primarily associated with package (re)naming and so on. As soon as HttpClient 3.0 goes final we will move quickly to establish presence at the Jakarta level. You can count on our (at least my) assistance with promotion process should you decide to give it a go Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: FeedParser move to Commons Proper...
BCEL was (until recently) a dormant project, no active committers around anymore to respond to questions / commit bug fixes. Because BCEL is at jakarta level this was/is problematic. The Jakarta PMC cannot provide oversight if no committers are present and on the PMC so this would main the end of BCEL. The BCEL problem was resolved. An external contributer was voted in as committer and some existing PMC members are acting as mentors to bring this component back to full health. To prevent this kind of situation is one of the reasons jakarta-commons was formed: To protect smaller component/libraries. We stick together and form a larger community with more committers/contributers. -- Dirk Anaximandro (Woody) wrote: Tim O'Brien, please, sorry by my stupidity, but how do you means with: To promote feedparser out of commons at this point might create the possibility for another BCEL. ? Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151488 - jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Author: scohen
Date: Sat Feb 5 04:48:48 2005
New Revision: 151488
URL: http://svn.apache.org/viewcvs?view=revrev=151488
Log:
correct initiateListParsing() so that it works in all cases.
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java?view=diffr1=151487r2=151488
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Sat Feb 5 04:48:48 2005
@@ -2330,9 +2330,15 @@
// We cache the value to avoid creation of a new object every
// time a file listing is generated.
if(__entryParser == null) {
-// if a null parserKey is supplied, check the
- // configuration to see if one was specified there.
-if (null == parserKey) {
+if (null != parserKey) {
+// if a parser key was supplied in the parameters,
+// use that to create the paraser
+ __entryParser =
+ __parserFactory.createFileEntryParser(parserKey);
+
+} else {
+ // if no parserKey was supplied, check for a configuration
+ // in the params, and if non-null, use that.
if (null != __configuration) {
__entryParser =
__parserFactory.createFileEntryParser(__configuration);
@@ -2340,11 +2346,9 @@
// if a parserKey hasn't been supplied, and a configuration
// hasn't been supplied, then autodetect by calling
// the SYST command and use that to choose the parser.
-parserKey = getSystemName();
-
- }
-} else {
- __entryParser =
__parserFactory.createFileEntryParser(parserKey);
+ __entryParser =
+ __parserFactory.createFileEntryParser(getSystemName());
+ }
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151489 - in jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp: AllTests.java FTPClientConfigFunctionalTest.java
Author: scohen
Date: Sat Feb 5 04:56:14 2005
New Revision: 151489
URL: http://svn.apache.org/viewcvs?view=revrev=151489
Log:
Add new functional test submitted by W. McDonald Buck accessing a server at
NOAA to test timezone functionality.
Added:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/AllTests.java
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/AllTests.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/AllTests.java?view=diffr1=151488r2=151489
==
---
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/AllTests.java
(original)
+++
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/AllTests.java
Sat Feb 5 04:56:14 2005
@@ -28,6 +28,7 @@
//$JUnit-BEGIN$
suite.addTest(ListingFunctionalTest.suite());
suite.addTestSuite(FTPClientConfigTest.class);
+suite.addTestSuite(FTPClientConfigFunctionalTest.class);
//$JUnit-END$
return suite;
}
Added:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java?view=autorev=151489
==
---
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
(added)
+++
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Sat Feb 5 04:56:14 2005
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2005 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.net.ftp;
+
+import junit.framework.TestCase;
+import java.io.IOException;
+import java.net.SocketException;
+import java.text.SimpleDateFormat;
+import java.util.Calendar;
+import java.util.Comparator;
+import java.util.Iterator;
+import java.util.TimeZone;
+import java.util.TreeSet;
+
+/*
+ * This test was contributed in a different form by W. McDonald Buck
+ * of Boulder, Colorado, to help fix some bugs with the FTPClientConfig
+ * in a real world setting. It is a perfect functional test for the
+ * Time Zone functionality of FTPClientConfig.
+ *
+ * A publicly accessible FTP server at the US National Oceanographic and
+ * Atmospheric Adminstration houses a directory which contains
+ * 300 files, named sn. to sn.0300. Every ten minutes or so
+ * the next file in sequence is rewritten with new data. Thus the directory
+ * contains observations for more than 24 hours of data. Since the server
+ * has its clock set to GMT this is an excellent functional test for any
+ * machine in a different time zone.
+ */
+
+public class FTPClientConfigFunctionalTest extends TestCase {
+
+private FTPClient FTP = new FTPClient();
+private FTPClientConfig FTPConf;
+
+
+/**
+ *
+ */
+public FTPClientConfigFunctionalTest() {
+super();
+
+ }
+
+/*
+ * @throws java.lang.Exception
+ */
+protected void setUp() throws Exception {
+super.setUp();
+ FTPConf = new FTPClientConfig(FTPClientConfig.SYST_UNIX);
+ FTPConf.setServerTimeZoneId(GMT);
+ FTP.configure(FTPConf);
+try {
+FTP.connect(tgftp.nws.noaa.gov);
+FTP.login(anonymous,[EMAIL PROTECTED]);
+FTP.changeWorkingDirectory(SL.us008001/DF.an/DC.sflnd/DS.metar);
+FTP.enterLocalPassiveMode();
+} catch (SocketException e) {
+e.printStackTrace();
+} catch (IOException e) {
+e.printStackTrace();
+}
+}
+/*
+ * @throws java.lang.Exception
+ */
+protected void tearDown() throws Exception {
+FTP.disconnect();
+super.tearDown();
+}
+/**
+ * @param arg0
+ */
+public FTPClientConfigFunctionalTest(String arg0) {
+super(arg0);
+}
+
+
+private TreeSet getSortedList(FTPFile[] files) {
+// create a TreeSet which will sort each element
+// as it is added.
+TreeSet sorted = new TreeSet(new
svn commit: r151490 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Author: scohen Date: Sat Feb 5 05:17:28 2005 New Revision: 151490 URL: http://svn.apache.org/viewcvs?view=revrev=151490 Log: fix syntax error Modified: jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java Modified: jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java?view=diffr1=151489r2=151490 == --- jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java (original) +++ jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java Sat Feb 5 05:17:28 2005 @@ -22,7 +22,6 @@ import java.util.Calendar; import java.util.Comparator; import java.util.Iterator; -import java.util.TimeZone; import java.util.TreeSet; /* @@ -143,7 +142,7 @@ // test that notwithstanding any time zone differences, the newest file // is older than now. -assertTrue(lastfile.getTimestamp().getTime().before(now); +assertTrue(lastfile.getTimestamp().getTime().before(now)); Calendar first = firstfile.getTimestamp(); // test that the oldest is less than two days older than the newest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] status
Hi Woody, Where did you post your proposals/patches? I'm very interested in improving the i18n/contract components. If you have any suggestions the best way is to describe the idea behind it so that it can be discussed in the mailing list. You can also post the related patches/files as attachment to a bugzilla entry (enhancement request). Please try to describe each single idea / enhancement and include some code snippets in the mail if it makes the idea clearer. Regarding the proposal of a ConfigManager: I'd like to keep the components as simple as possible. I've understood that we need to have the ability to have more than one MessageManager per VM. So my proposal would be just to add a getInstance(String messageManager) method to the MessageManager and get rid of the static methods. But perhaps I've missed the point. So it would be great if you could explain in more detail what the ConfigManager is for. Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Samstag, 5. Februar 2005 06:03 An: Jakarta Commons Developers List; [EMAIL PROTECTED] Betreff: Re: [i18n] status Thanx Oliver. I will wait for him, :o Woody - Original Message - From: Oliver Zeigermann [EMAIL PROTECTED] To: Anaximandro (Woody) [EMAIL PROTECTED] Cc: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Friday, February 04, 2005 3:47 PM Subject: Re: [i18n] status I am sure that your suggestions are valueable and you do not bore me at all. However, the proposals you made should be inspected by Daniel, as I have no deeper insight into neither contract nor i18n. Oliver On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody) [EMAIL PROTECTED] wrote: Oliver, I sent one proposal too (another class diagram, with a macro vision of my suggestions). The idea behind my suggestion is write one mediator (ConfigManager) to retain one specific configuration (I can have many threads running with diferent configurations) and put one service locator in MessageManager. Each message (LocalizedText, LocalizedMessage, etc) comunicates with MessageManager through your configuration. I write a lot of code to test this ideas and to be more confident with this project, but now I stuck, this project is not mine and I need to take easy with ideas 8( You wanna see this class diagram? I'm boring you? Sorry Woody I mainly work on xmlio, but am not aware of any proposed changes to the project. The class diagrams you sent have been put online by me. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151504 - in jakarta/commons/proper/configuration/trunk: ./ RELEASE-NOTES.txt build.xml project.xml src/conf/ src/conf/MANIFEST.MF xdocs/changes.xml
Author: oheger
Date: Sat Feb 5 07:41:17 2005
New Revision: 151504
URL: http://svn.apache.org/viewcvs?view=revrev=151504
Log:
Preparing 1.1 release candidate
Added:
jakarta/commons/proper/configuration/trunk/src/conf/
jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF (with
props)
Modified:
jakarta/commons/proper/configuration/trunk/ (props changed)
jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/configuration/trunk/build.xml
jakarta/commons/proper/configuration/trunk/project.xml
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Propchange: jakarta/commons/proper/configuration/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Sat Feb 5 07:41:17 2005
@@ -1,3 +1,4 @@
+
*~
.nbattrs
docs
@@ -12,3 +13,4 @@
*.ser
junit*.properties
*.patch
+dist
Modified: jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt?view=diffr1=151503r2=151504
==
--- jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt Sat Feb 5
07:41:17 2005
@@ -1,7 +1,7 @@
-$Id: RELEASE-NOTES.txt,v 1.1 2003/12/23 15:09:05 epugh Exp $
+$Id$
Commons Configuration Package
- Version 1.0
+ Version 1.1
Release Notes
@@ -11,14 +11,8 @@
This document contains the release notes for this version of the Commons
Configuration component, and highlights changes since the previous version.
+Release 1.1 contains new features and bug fixes as well. A complete list of
+changes can be obtained from the changelog report that is created when building
+with maven or can be viewed at
-NEW FEATURES
-
-
-This is the first milestone release of this component.
-
-
-BUG FIXES
-=
-
-Not applicable.
+ http://jakarta.apache.org/commons/configuration/changes-report.html
Modified: jakarta/commons/proper/configuration/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/build.xml?view=diffr1=151503r2=151504
==
--- jakarta/commons/proper/configuration/trunk/build.xml (original)
+++ jakarta/commons/proper/configuration/trunk/build.xml Sat Feb 5 07:41:17
2005
@@ -26,7 +26,7 @@
property name=targetconfdir value=${defaulttargetdir}/${confdir}/
!-- Manual changes end --
- property name=final.name value=commons-configuration-1.1-dev
+ property name=final.name value=commons-configuration-1.1RC1
/property
path id=build.classpath
fileset dir=${libdir}
Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/project.xml?view=diffr1=151503r2=151504
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Sat Feb 5 07:41:17
2005
@@ -22,7 +22,7 @@
pomVersion3/pomVersion
idcommons-configuration/id
- currentVersion1.1-dev/currentVersion
+ currentVersion1.1RC1/currentVersion
inceptionYear2001/inceptionYear
nameCommons Configuration/name
shortDescriptionCommon Configuration/shortDescription
Added: jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF?view=autorev=151504
==
--- jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF (added)
+++ jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF Sat Feb 5
07:41:17 2005
@@ -0,0 +1,9 @@
+Manifest-Version: 1.0
+Package: @package@
+Extension-Name: @name@
+Specification-Version: @version@
+Specification-Vendor: Apache Software Foundation
+Specification-Title: @title@
+Implementation-Version: @version@
+Implementation-Vendor: Apache Software Foundation
+Implementation-Vendor-Id:
Propchange: jakarta/commons/proper/configuration/trunk/src/conf/MANIFEST.MF
--
svn:eol-style = native
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffr1=151503r2=151504
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
svn commit: r151505 - jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC1
Author: oheger Date: Sat Feb 5 07:46:10 2005 New Revision: 151505 URL: http://svn.apache.org/viewcvs?view=revrev=151505 Log: Tagging release candidate 1.1RC1 Added: jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC1/ - copied from r151504, jakarta/commons/proper/configuration/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33409] - [validator] Email: inexisting dashes and TLD erroneously accepted
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=33409. 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=33409 [EMAIL PROTECTED] changed: What|Removed |Added Platform|PC |All Summary|[validator: email] |[validator] Email: |inexisting dashes and TLD |inexisting dashes and TLD |erroneously accepted|erroneously accepted -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151509 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Author: scohen
Date: Sat Feb 5 08:31:31 2005
New Revision: 151509
URL: http://svn.apache.org/viewcvs?view=revrev=151509
Log:
add comment illustrating value of functionality
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java?view=diffr1=151508r2=151509
==
---
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
(original)
+++
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
Sat Feb 5 08:31:31 2005
@@ -37,6 +37,14 @@
* contains observations for more than 24 hours of data. Since the server
* has its clock set to GMT this is an excellent functional test for any
* machine in a different time zone.
+ *
+ * Noteworthy is the fact that the ftp routines in some web browsers don't
+ * work as well as this. They can't, since they have no way of knowing the
+ * server's time zone. Depending on the local machine's position relative
+ * to GMT and the time of day, the browsers may decide that a timestamp
+ * would be in the future if given the current year, so they assume the
+ * year to be last year. This illustrates the value of FTPClientConfig's
+ * time zone functionality.
*/
public class FTPClientConfigFunctionalTest extends TestCase {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] 1.1 release
As promised I have created the commons-configuration-1.1RC1 release candidate. A new tag was added in svn using svn copy https://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk https://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC1 The distributions for 1.1RC1 can be found at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ As release notes the changelog report can be used, which can be found at http://jakarta.apache.org/commons/configuration/changes-report.html I hope I have done nothing dramatically wrong (first trial). Comments are welcome. What is the next step for a release? Calling a vote? Oliver Oliver Heger wrote: Our senior committers seem to have disappeared a bit, which makes the task of cutting out a new release not easier. What I can do is to (try to) create a release candidate, but I think I won't find the time to do all the necessary reading about how releases are managed. If no one objects, I will do this in the next days. Or does somebody volunteer for the job as release manager? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ReflectionUtils
On Wed, 2005-02-02 at 01:07, Torsten Curdt wrote: Stephen Colebourne wrote: By using an interface strategy to find methods I believe that this takes it out of scope for [lang]. We have tried to restrict lang to tasks that are non-framework like and non-religious. I see I am also being harsh, because there is a [reflect] component in the sandbox, which is dormant. That was meant to handle generic ReflectionUtils type things. What about it? it's been waiting a while for someone to pick it up for a while now :) Plus there are MethodUtils and so on in [beanutils]. Ok ...I will have a look into both the beanutils and the reflect component. i'd say that the reflect would be the better match. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151515 - jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml
Author: rdonkin Date: Sat Feb 5 10:05:08 2005 New Revision: 151515 URL: http://svn.apache.org/viewcvs?view=revrev=151515 Log: Fixed typo Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml?view=diffr1=151514r2=151515 == --- jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml (original) +++ jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml Sat Feb 5 10:05:08 2005 @@ -49,7 +49,7 @@ /dependency dependency groupIdcommons-beanutils/groupId - artifactIdcommons-beanutils-bean-collections/groupId + artifactIdcommons-beanutils-bean-collections/artifactId version1.7.0/version urlhttp://jakarta.apache.org/commons/beanutils//url /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] performance of ns-aware parsing
On Thu, 2005-02-03 at 07:52 -0800, Reid Pinchback wrote: --- Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote: Of course if someone can demonstrate that non-namespace-aware parsers *are* still useful then I'll change my mind. Just to clarify, since I was being sloppy before (I gotta stop typing in shorthand) there is an important distinction: a) having NS-aware parser, always using NS-aware API methods b) having NS-aware parser, selectively using NS-aware API methods c) having non-NS-aware parser (and obviously never using NS-aware API methods) d) having NS-aware parser where the developer fixes a grammar that ignores any NS distinctions Even for Sax the performance difference between (a) and (b) is roughly a factor of 2 across all parsers when processing small (typical message-sized) docs that don't use NS. I would *really* love to see some actual measurements on this if you can find some. You seem to be quoting from some study you have done or read - it would be great to have this. [See comments on Piccolo below] Mucking with (d) is supposed to result in significant wins when you tune the grammar handling to your app, but I haven't tried it myself and I've never seen timing differences quoted. I don't quite understand what (d) means, but is it actually relevant? Again, we are talking about *namespaces* not validation. The w3c namespaces spec clearly makes a distinction between namespaces and whether or not the namespace URI means anything: quote source=http://www.w3c.org/TR/xml-names11/; Note also that the Namespaces specification says nothing about what might (or might not) happen if one were to attempt to dereference a URI/IRI used to identify a namespace. /quote What I'm trying to achieve is to avoid having actions or patterns deal with element-names containing prefixes, eg stating that an element's name is foo:item. This is just broken; the item's name is really the tuple (some-namespace, item). Grammars/schemas can optionally be bound to namespaces, but namespaces themselves are a lower layer that can be used without any of these things. I'm talking here about requiring the parser to convert foo:item into (namespace, item) but do not intend to imply that any kind of schema should be loaded for the specified namespace. The XMLReader.setNamespaceAware(true) method does exactly this; enables mapping of prefixes - namespaces, but does not enable processing of either DTDs or schemas. I'm not trying to advocate any approach except to notice that, since your README mentioned requiring a namespace-aware parser, it sounded like there was a potential for options (b), (c), and (d) to become unintentionally closed to developers in Digester2 when they weren't in Digester1. Well, I did intend to close options (b) and (c) as I didn't believe there was any reason at all to support them. Some real measurements showing the kind of performance you quote would definitely change my mind. I agree that old parsers providing (c) aren't particularly interesting, but if you spend any time tracing through the guts of the parsing, particularly when you see how DTDs are loaded for entity resolution, you begin to see (d) as having potential. Throwing (b) away may result in less code in Digester2, but it may be worth doing some timing tests to see if that code reduction is consequence-free. What does loading DTDs have to do with namespaces? I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. Actually the XML spec distinguishes between the default namespace and all other namespaces, so parsers can reasonably make the same distinction and try to avoid a bunch of per-entity operations and temporary object creations in the case where there is no namespace. Sorry, what per-entity operations, and what temporary object creations? Look at the piccolo stats published on Sourceforge. Compare Soap, Soap+NS, and random XML-no NS timings and it suggests that NS ain't free. Useful links: Jade (now part of Javolution) http://javolution.org/api/index.html, look at the javolution.xml package (trades String for CharSequence to increase performance, but keeps NS) Hmm.. I've added a reference to javolution to the wiki. However I couldn't find any info on the performance of namespaceAware vs nonNamespaceAware... Picollo you probably already have the link for, but for anybody else interested: http://piccolo.sourceforge.net Piccolo does have a page where they state their performance tests for SOAP - namespaces off is about 12% faster than SOAP - namespaces on. But there is no further info on what these phrases mean. The piccolo site provides a download for SAXBench benchmarking tool, but (a) I never managed to get this working, and (b) it
svn commit: r151536 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Author: skitching
Date: Sat Feb 5 20:19:16 2005
New Revision: 151536
URL: http://svn.apache.org/viewcvs?view=revrev=151536
Log:
* add comments to setValidating re how to validate against an xml schema
* remove method setPublicId; it was always broken
* rename getPublicId -- getDtdPublicId, add getDtdSystemId
* move code that sets up XMLReader callbacks into SAXHandler.initCallbacks
so it is accessable to users who create XMLReaders directly.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java?view=diffr1=151535r2=151536
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Sat Feb 5 20:19:16 2005
@@ -123,15 +123,31 @@
// - Properties
/**
- * Determine whether we are to validate the xml input against a schema.
+ * Determine whether we are to validate the xml input against a DTD.
* If so, then an error will be reported by the parse() methods if the
* input doesn't comply with the schema. If validation is disabled, then
* performance will be improved, but no error will be reported if the
* input is not correct.
* p
- * Note that even when validation is disabled, any external schema or DTD
- * referenced by the input document must still be read, as it can declare
- * default attributes and similar items which affect xml parsing.
+ * Note that even when validation is disabled, any external DTD referenced
+ * by the input document must still be read, as it can declare default
+ * attributes and similar items which affect xml parsing.
+ * p
+ * In order to validate a document against an xml schema, all of the
+ * following must be done:
+ * ul
+ * liValidation must be enabled (using this method or by setting feature
+ * http://xml.org/sax/features/validation; on the XMLReader object).
+ * liSchema-validation must be enabled in a parser-specific manner. For
+ * the Xerces parser (which is bundled with java 1.4 and 1.5) the feature
+ * http://apache.org/xml/features/validation/schema; must be set on the
+ * XMLReader object.
+ * liThe input xml document must declare the schema to use by defining
+ * xml attribute xsi:noNamespaceSchemaLocation or xsi:schemaLocation
+ * on some element (usually the root element)
+ * liThe DOCTYPE declaration on the top of the input xml element must
+ * be removed; schema validation is ignored if DOCTYPE is present.
+ * /ul
*
* @param validating The new validating parser flag.
*
@@ -166,6 +182,10 @@
*
* pThe reader passed here should be configured with namespace-aware
* parsing enabled, as the digester classes assume this./p
+ *
+ * pThis method does not set up the SAXHandler as the reader's handler
+ * for content, dtd or other events. You should generally call method
+ * SAXHandler.initCallbacks before starting the parse.
*/
public void setXMLReader(XMLReader reader) {
this.reader = reader;
@@ -174,7 +194,7 @@
/**
* Set the class loader to be used for instantiating application objects
* when required. If a non-null value is passed to this method, then
- * method [EMAIL PROTECTED] #useContextClassLoader} will have no effect.
+ * method [EMAIL PROTECTED] #setUseContextClassLoader} will have no effect.
* p
* When an Action is executed due to some xml input, and that Action
* wishes to create an object to represent the input, then the class
@@ -254,34 +274,35 @@
}
/**
- * Set the publid id of the current file being parsed. This will cause
- * the declared DOCTYPE (if any) of the input document to be ignored.
- *
- * Instead the provided publicId will be looked up in the known entities,
- * and the resource located at the associated URL will be used as the
- * DTD for this input document.
+ * Get the public identifier of the DTD associated with the document
+ * currently being parsed, or most recently parsed.
* p
- * NOTE: if the input document doesn't include a DOCTYPE, then the
- * DTD specified by this call is not used. There is currently no way
- * to force an input document to be validated against a specific DTD
- * (due to a lack of this feature in the xml standard).
- *
- * @param publicId the DTD/Schema public's id.
svn commit: r151537 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Author: skitching
Date: Sat Feb 5 20:32:34 2005
New Revision: 151537
URL: http://svn.apache.org/viewcvs?view=revrev=151537
Log:
* implement org.xml.sax.ext.LexicalHandler interface so that info on the DTD
public and system ids can be obtained properly rather than the EntityResolver
hack used previously.
* Remove broken setPublicId method.
* Rename getPublicId-getDTDPublicId, add getDTDSystemId
* Remove reference to XMLReader which is sending events to the SAXHandler.
This was used by NodeCreateRule; instead, have SAXHandler provide the
option to forward ContentHandler method callbacks to an arbitrary object.
See SAXHandler.setContentHandler/getContentHandler.
* add initCallbacks method
* whitespace cleanups
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java?view=diffr1=151536r2=151537
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Sat Feb 5 20:32:34 2005
@@ -47,9 +47,11 @@
import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.SAXParseException;
import org.xml.sax.XMLReader;
-import org.xml.sax.helpers.DefaultHandler;
+import org.xml.sax.ContentHandler;
import org.xml.sax.ErrorHandler;
import org.xml.sax.EntityResolver;
+import org.xml.sax.helpers.DefaultHandler;
+import org.xml.sax.ext.LexicalHandler;
/**
* pAn object which handles SAX events generated during parsing of an
@@ -87,7 +89,7 @@
* logged, then ignored.
*/
-public class SAXHandler extends DefaultHandler {
+public class SAXHandler extends DefaultHandler implements LexicalHandler {
// - Constructors
@@ -101,16 +103,6 @@
// --- Instance Variables
/**
- * The XMLReader object that is generating the SAX events being handled
- * by this object. This member is currently here for only one purpose:
- * so that the CreateNodeRule can get access to it and (temporarily)
- * redirect the sax events to its own handler. This isn't entirely
- * elegant (particularly as it introduces a cyclic dependency between
- * this class and its XMLReader); alternative solutions are welcome.
- */
-private XMLReader reader;
-
-/**
* The EntityResolver used to look up any external entities referenced
* from within the input xml. Note that this class always receives the
* event initally, so that they can be logged, but if the user has
@@ -221,16 +213,28 @@
// ---
/**
+ * If null, then calls to this objects' characters, startElement,
endElement
+ * and processingInstruction methods are forwarded to the specified object.
+ * This is intended to allow rules to temporarily take control of the
+ * sax events. In particular, this is used by NodeCreateAction.
+ */
+private ContentHandler contentHandler = null;
+
+/**
* The public identifier of the DTD we are currently parsing under
- * (if any). The user may set this explicitly, in which case we ignore
- * the DTD specified in the input xml file and use the one provided
- * by the user. See method resolveEntity.
- *
- * TODO: Consider if this should be moved to Context. Maybe not if the
- * user has explicitly set it, but certainly if it is extracted from
- * the input data...
+ * (if any). See method [EMAIL PROTECTED] #startDTD}.
+ *
+ * TODO: Consider if this should be moved to Context.
+ */
+private String dtdPublicId = null;
+
+/**
+ * The system identifier of the DTD we are currently parsing under
+ * (if any). See method [EMAIL PROTECTED] #startDTD}.
+ *
+ * TODO: Consider if this should be moved to Context.
*/
-private String publicId = null;
+private String dtdSystemId = null;
/**
* The body text of the current element. As the parser reports chunks
@@ -265,7 +269,7 @@
// General object configuration methods
//
// These methods are expected to be called by the user or by the
-// Digester class in order to set this object up ready to perform
+// Digester class in order to set this object up ready to perform
// parsing.
//
// Some methods (particularly the getters) are also used during
@@ -273,51 +277,98 @@
// -
svn commit: r151538 - in jakarta/commons/proper/httpclient/trunk: build.xml project.xml src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java xdocs/downloads.xml xdocs/news.xml xdocs/status.xml
Author: mbecke
Date: Sat Feb 5 20:35:54 2005
New Revision: 151538
URL: http://svn.apache.org/viewcvs?view=revrev=151538
Log:
Updates for 3.0 RC1.
Modified:
jakarta/commons/proper/httpclient/trunk/build.xml
jakarta/commons/proper/httpclient/trunk/project.xml
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml
jakarta/commons/proper/httpclient/trunk/xdocs/news.xml
jakarta/commons/proper/httpclient/trunk/xdocs/status.xml
Modified: jakarta/commons/proper/httpclient/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/build.xml?view=diffr1=151537r2=151538
==
--- jakarta/commons/proper/httpclient/trunk/build.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/build.xml Sat Feb 5 20:35:54 2005
@@ -38,7 +38,7 @@
property name=component.title value=HttpClient Library/
!-- The current version number of this component --
- property name=component.version value=3.0-beta1/
+ property name=component.version value=3.0-rc1/
!-- == Properties: Source Directories --
Modified: jakarta/commons/proper/httpclient/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/project.xml?view=diffr1=151537r2=151538
==
--- jakarta/commons/proper/httpclient/trunk/project.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/project.xml Sat Feb 5 20:35:54 2005
@@ -6,7 +6,7 @@
idcommons-httpclient/id
gumpRepositoryIdjakarta-commons-httpclient/gumpRepositoryId
inceptionYear2001/inceptionYear
- currentVersion3.0-beta1/currentVersion
+ currentVersion3.0-rc1/currentVersion
packageorg.apache.commons.httpclient/package
organization
@@ -33,6 +33,11 @@
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
/repository
versions
+version
+ id3.0-rc1/id
+ name3.0-rc1/name
+ tagHTTPCLIENT_3_0_RC1/tag
+/version
version
id3.0-beta1/id
name3.0-beta1/name
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java?view=diffr1=151537r2=151538
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java
Sat Feb 5 20:35:54 2005
@@ -1,7 +1,7 @@
/*
* $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//httpclient/src/java/org/apache/commons/httpclient/params/DefaultHttpParamsFactory.java,v
1.16 2004/11/20 21:48:47 mbecke Exp $
* $Revision: 1.16 $
- * $Date: 2004/11/20 21:48:47 $
+ * $Date$
*
*
*
@@ -68,7 +68,7 @@
protected HttpParams createParams() {
HttpClientParams params = new HttpClientParams(null);
-params.setParameter(HttpMethodParams.USER_AGENT, Jakarta
Commons-HttpClient/3.0-beta1);
+params.setParameter(HttpMethodParams.USER_AGENT, Jakarta
Commons-HttpClient/3.0-rc1);
params.setVersion(HttpVersion.HTTP_1_1);
params.setConnectionManagerClass(SimpleHttpConnectionManager.class);
params.setCookiePolicy(CookiePolicy.RFC_2109);
Modified: jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml?view=diffr1=151537r2=151538
==
--- jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/xdocs/downloads.xml Sat Feb 5
20:35:54 2005
@@ -14,7 +14,7 @@
The following releases are avilable for download:
/p
ul
- li3.0-beta1 - 21 November 2004 -
+ li3.0-RC1 - 06 February 2004 -
a href=http://jakarta.apache.org/site/binindex.cgi;Binary/a
and
a
href=http://jakarta.apache.org/site/sourceindex.cgi;Source/a - a
href=http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES.txt;
@@ -53,8 +53,8 @@
source![CDATA[
dependency
idcommons-httpclient/id
-version3.0-beta1/version
-urlhttp://jakarta.apache.org/commons/httpclient//url
+version3.0-rc1/version
+
svn commit: r151539 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java
Author: skitching
Date: Sat Feb 5 20:36:18 2005
New Revision: 151539
URL: http://svn.apache.org/viewcvs?view=revrev=151539
Log:
* made changes due to original XMLReader object not being accessable
any more. Instead, use new setContentHandler method on SAXHandler class.
* moved endElement method to more logical location within file.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java?view=diffr1=151538r2=151539
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java
Sat Feb 5 20:36:18 2005
@@ -98,7 +98,7 @@
/**
* Constructor.
*
- * pStores the content handler currently used by Digester so it can
+ * pStores the context currently used by Digester so it can
* be reset when done, and initializes the DOM objects needed to
* build the node./p
*
@@ -116,39 +116,23 @@
this.root = root;
this.top = root;
-oldSaxHandler = context.getSAXHandler();
-oldContext = context;
-reader = oldSaxHandler.getXMLReader();
-// assert oldReader.getContentHandler() == oldSaxHandler
+this.context = context;
}
// - Instance Variables
-
-/**
- * The content handler used by Digester before it was set to this
- * content handler.
- */
-protected SAXHandler oldSaxHandler = null;
-
/**
* The parsing context currently in use.
*/
-protected Context oldContext = null;
+protected Context context = null;
/**
- * The XMLReader being used to parse the input xml.
- */
-protected XMLReader reader;
-
-/**
* Depth of the current node, relative to the element where the content
* handler was put into action.
*/
protected int depth = 0;
-
/**
* A DOM Document used to create the various Node instances.
*/
@@ -194,44 +178,6 @@
/**
- * Checks whether control needs to be returned to Digester.
- *
- * @param namespaceURI the namespace URI
- * @param localName the local name
- * @param qName the qualified (prefixed) name
- * @throws SAXException if the DOM implementation throws an exception
- */
-public void endElement(String namespaceURI, String localName,
- String qName)
-throws SAXException {
-
-try {
-if (depth == 0) {
-// restore sax event handler
-reader.setContentHandler(oldSaxHandler);
-
-// push built node onto stack so that other rules can
-// access it. Note that this node gets popped in the
-// end method of the parent NodeCreateAction, so it won't
-// be there very long...
-oldContext.push(root);
-
-// and manually fire the rules that would have been fired
-// had the normal SAXHandler been receiving parse events
-// instead of this temporary handler.
-oldSaxHandler.endElement(namespaceURI, localName, qName);
-}
-
-top = top.getParentNode();
-depth--;
-} catch (DOMException e) {
-throw new SAXException(e.getMessage());
-}
-
-}
-
-
-/**
* Adds a new
* [EMAIL PROTECTED] org.w3c.dom.ProcessingInstruction
ProcessingInstruction} to
* the current node.
@@ -296,6 +242,46 @@
}
+
+/**
+ * Checks whether control needs to be returned to Digester.
+ *
+ * @param namespaceURI the namespace URI
+ * @param localName the local name
+ * @param qName the qualified (prefixed) name
+ * @throws SAXException if the DOM implementation throws an exception
+ */
+public void endElement(String namespaceURI, String localName,
+ String qName)
+throws SAXException {
+
+try {
+
svn commit: r151540 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Author: skitching
Date: Sat Feb 5 20:37:18 2005
New Revision: 151540
URL: http://svn.apache.org/viewcvs?view=revrev=151540
Log:
Added tests for setRoot/getRoot methods.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java?view=diffr1=151539r2=151540
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Sat Feb 5 20:37:18 2005
@@ -124,8 +124,69 @@
/**
* Test storage of the 'root' variable
*/
-public void testRoot() {
+public void testRoot1() {
// setRoot, getRoot
+SAXHandler saxHandler = new SAXHandler();
+Log log = saxHandler.getLogger();
+Context context = new Context(saxHandler, log);
+
+Object root;
+
+// initially, getRoot returns null
+root = context.getRoot();
+assertNull(Initial root object is null, root);
+
+// after setRoot, returns the object set
+context.setRoot(root1);
+root = context.getRoot();
+assertEquals(setRoot/getRoot retrieves set object, root1, root);
+
+// can set multiple times, always returns the last object set
+// also, stack depth should be max of 1
+context.setRoot(root2);
+context.setRoot(root3);
+context.setRoot(root4);
+root = context.getRoot();
+assertEquals(setRoot multiple times, root4, root);
+assertEquals(context.getStackSize(), 1);
+}
+
+/**
+ * Test storage of the 'root' variable
+ */
+public void testRoot2() {
+// setRoot, getRoot
+SAXHandler saxHandler = new SAXHandler();
+Log log = saxHandler.getLogger();
+Context context = new Context(saxHandler, log);
+
+Object root;
+
+// initially, getRoot returns null
+root = context.getRoot();
+assertNull(Initial root object is null, root);
+
+// after pushing an object, root is set
+context.push(item1);
+root = context.getRoot();
+assertEquals(push sets root, item1, root);
+
+// after pushing other objects, root does not change
+context.push(item2);
+context.push(item3);
+context.push(item4);
+root = context.getRoot();
+assertEquals(push sets root, item1, root);
+assertEquals(push increases stackdepth, 4, context.getStackSize());
+
+// after popping all objects off stack, root remains set
+context.pop();
+context.pop();
+context.pop();
+context.pop();
+root = context.getRoot();
+assertEquals(root remains set after pop, item1, root);
+assertEquals(root remains set after pop, 0, context.getStackSize());
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151542 - jakarta/commons/proper/httpclient/tags/HTTPCLIENT_3_0_RC1
Author: mbecke Date: Sat Feb 5 20:43:11 2005 New Revision: 151542 URL: http://svn.apache.org/viewcvs?view=revrev=151542 Log: Created 3.0 RC1 tag. Added: jakarta/commons/proper/httpclient/tags/HTTPCLIENT_3_0_RC1/ - copied from r151541, jakarta/commons/proper/httpclient/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] performance of ns-aware parsing
--- Simon Kitching [EMAIL PROTECTED] wrote: On Thu, 2005-02-03 at 07:52 -0800, Reid Pinchback wrote: Even for Sax the performance difference between (a) and (b) is roughly a factor of 2 across all parsers when processing small (typical message-sized) docs that don't use NS. I would *really* love to see some actual measurements on this if you can find some. You seem to be quoting from some study you have done or read - it would be great to have this. [See comments on Piccolo below] Take another look at the Piccolo data, and compare the 2 Soap examples to the random no-NS data. The differences between the two Soap examples isn't material because both use NS, so in a sense you have a couple of different samples of NS data, and in the random case you have another sample, but I agree it would be better to create tests that were better understood in order to decide what the difference was. Mucking with (d) is supposed to result in significant wins when you tune the grammar handling to your app, but I haven't tried it myself and I've never seen timing differences quoted. I don't quite understand what (d) means, but is it actually relevant? Again, we are talking about *namespaces* not validation. Yes... and every entity (Element and Attribute) is jammed through a resolution process first. Remember XML attributes with default values? Guess where those values are identified and handed to the parser - during the resolution process. Namespaces just add more data to shuffle around during the resolution process. What I'm trying to achieve is to avoid having actions or patterns deal with element-names containing prefixes, eg stating that an element's name is foo:item. This is just broken; the item's name is really the tuple (some-namespace, item). Grammars/schemas can optionally be bound to namespaces, but namespaces themselves are a lower layer that can be used without any of these things. I'm talking here about requiring the parser to convert foo:item into (namespace, item) but do not intend to imply that any kind of schema should be loaded for the specified namespace. That sounds sensible. The XMLReader.setNamespaceAware(true) method does exactly this; enables mapping of prefixes - namespaces, but does not enable processing of either DTDs or schemas. I don't think it actually has any impact at all on DTD processing. DTDs, if declared, are always processed unless you install an entity resolver that excises that activity out. I agree that old parsers providing (c) aren't particularly interesting, but if you spend any time tracing through the guts of the parsing, particularly when you see how DTDs are loaded for entity resolution, you begin to see (d) as having potential. Throwing (b) away may result in less code in Digester2, but it may be worth doing some timing tests to see if that code reduction is consequence-free. What does loading DTDs have to do with namespaces? As you said, the XML spec doesn't require that the namespaces mean anything, and hence it is possible that a parser won't try to resolve and validate against multiple DTDs, but I haven't ever traced through the code in a situation where there were multiple namespaces to resolve against, so I don't know if there is relationship there or not. In general, if a parser thinks it needs a DTD in order to understand a document, it tends to grab it. I don't know if there are situations where it tries to interpret namespace declations as public ids for DTDs. If that happens, then those DTDs would also be loaded by the parser and namespaces would have to be matched to the appropriate collections of contexts during entity resolution. I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. I stopped using belief as a measurement of code a long time ago. Usually only works when I wrote all the code. :-) I'll cook up an experiment and see what I can come up with in the way of timing information. Sorry, what per-entity operations, and what temporary object creations? The Jade/Javolution author wrote a fair bit about that, I'll see if I can find his pages. I couldn't find the details at the Javolution site; when Jade was separate he indicated that the String operations required to satisfy the SAX API semantics dragged down performance heavily. Zapthink comments on XML parsing challenges, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci85,00.html No occurrence of the word namespace anywhere in the article. For this and other similar concepts, it helps to start associating namespaces with other aspects of parsing internals. Elements and attributes have to be matched up to their definitions - the resolution process. Namespaces are an aspect of the match up, just more information to
Re: [digester2] performance of ns-aware parsing
On Sat, 2005-02-05 at 21:02 -0800, Reid Pinchback wrote: --- Simon Kitching [EMAIL PROTECTED] wrote: Mucking with (d) is supposed to result in significant wins when you tune the grammar handling to your app, but I haven't tried it myself and I've never seen timing differences quoted. I don't quite understand what (d) means, but is it actually relevant? Again, we are talking about *namespaces* not validation. Yes... and every entity (Element and Attribute) is jammed through a resolution process first. Remember XML attributes with default values? Guess where those values are identified and handed to the parser - during the resolution process. Namespaces just add more data to shuffle around during the resolution process. Well, in a document that doesn't use namespaces, the penalty is zero. In a document that uses namespaces, there are a few xmlns:... attributes floating around. But these have to be handled by the DTD processor regardless of whether namespace processing is enabled or not, yes? I don't see where namespaces adds any extra data for a DTD processor to deal with during the infoset augmentation stage. What I'm trying to achieve is to avoid having actions or patterns deal with element-names containing prefixes, eg stating that an element's name is foo:item. This is just broken; the item's name is really the tuple (some-namespace, item). Grammars/schemas can optionally be bound to namespaces, but namespaces themselves are a lower layer that can be used without any of these things. I'm talking here about requiring the parser to convert foo:item into (namespace, item) but do not intend to imply that any kind of schema should be loaded for the specified namespace. That sounds sensible. The XMLReader.setNamespaceAware(true) method does exactly this; enables mapping of prefixes - namespaces, but does not enable processing of either DTDs or schemas. I don't think it actually has any impact at all on DTD processing. DTDs, if declared, are always processed unless you install an entity resolver that excises that activity out. You are right; DTDs get processed in the same manner regardless of whether the parser is namespace-aware or not. What I meant was namespaceAware does not affect the parser's handling of DTDs or schemas (though it is a prerequisite for schema validation). I agree that old parsers providing (c) aren't particularly interesting, but if you spend any time tracing through the guts of the parsing, particularly when you see how DTDs are loaded for entity resolution, you begin to see (d) as having potential. Throwing (b) away may result in less code in Digester2, but it may be worth doing some timing tests to see if that code reduction is consequence-free. What does loading DTDs have to do with namespaces? As you said, the XML spec doesn't require that the namespaces mean anything, and hence it is possible that a parser won't try to resolve and validate against multiple DTDs, but I haven't ever traced through the code in a situation where there were multiple namespaces to resolve against, so I don't know if there is relationship there or not. In general, if a parser thinks it needs a DTD in order to understand a document, it tends to grab it. I presume you're using DTD as a general term covering both traditional DTDs (which are not namespace-aware) and w3c schemas? An xml parser does need to read a DTD regardless of whether validation is enabled or not, for the reasons you pointed out: default attributes, entity definitions etc. But w3c xml schemas deliberately don't have any functionality that affects the infoset of the document. So if you're not validating you can completely ignore any xml schema - and parsers do. To double-check, I tested this today, and verified the entity resolver isn't called to resolve xsi:schemaLocation references unless validation is enabled. I don't know if there are situations where it tries to interpret namespace declations as public ids for DTDs. No, xml parsers never dereference namespace-uris to load either DTDs or schemas. The only way to reference a schema from an xml document is via xsi:schemaLocation=namespace url I think some XML editing programs do try to load schemas based upon the namespace URI (eg jEdit, XMLSpy) but this is quite different (and probably against the xml standard). I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. I stopped using belief as a measurement of code a long time ago. Usually only works when I wrote all the code. :-) I'll cook up an experiment and see what I can come up with in the way of timing information. That would be excellent. I look forward to seeing the results.. Regards, Simon
Re: svn commit: r151515 - jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml
Thanks for that :-( On Sat, 05 Feb 2005 18:05:09 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rdonkin Date: Sat Feb 5 10:05:08 2005 New Revision: 151515 URL: http://svn.apache.org/viewcvs?view=revrev=151515 Log: Fixed typo Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml?view=diffr1=151514r2=151515 == --- jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml (original) +++ jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml Sat Feb 5 10:05:08 2005 @@ -49,7 +49,7 @@ /dependency dependency groupIdcommons-beanutils/groupId - artifactIdcommons-beanutils-bean-collections/groupId + artifactIdcommons-beanutils-bean-collections/artifactId version1.7.0/version urlhttp://jakarta.apache.org/commons/beanutils//url /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
