[jira] Commented: (FILEUPLOAD-106) parseRequest randomly throws Stream ended unexpectedly
[
http://issues.apache.org/jira/browse/FILEUPLOAD-106?page=comments#action_12412207
]
Gerald Turner commented on FILEUPLOAD-106:
--
User error!
The client was running two threads sharing instances of HttpClient FilePart[]
while uploading to two FileUpload servlet servers. Changed it so each upload
thread instantiates it's own FilePart[] and the error no longer randomly occurs.
Please close the bug.
parseRequest randomly throws Stream ended unexpectedly
--
Key: FILEUPLOAD-106
URL: http://issues.apache.org/jira/browse/FILEUPLOAD-106
Project: Commons FileUpload
Type: Bug
Versions: Nightly Builds
Environment: The client and server environments are all Solaris 9, Java
1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
Reporter: Gerald Turner
Attachments: commons-fileupload-1.2-SNAPSHOT-initCause.patch
Hello, I have an application using FileUpload which intermittently encounters
this error as well, about once every 100 uploads. It's a simple servlet that
writes posted files to disk. The client application that is posting to this
FileUpload servlet is using Jakarta Commons HttpClient 3.0.1 with features
such
as MultipartRequestEntity and MultiThreadedHttpConnectionManager.
Typically the posts contain two to three FileParts, a few 20KB audio/x-wav
files accompanied by a 15KB application/voicexml+xml file.
The servlet is actually running on two different servers, and the single
client
posts to both of them, this occasional Stream ended unexpectedly error will
occur on one server and still succeed on the other.
The client and server environments are all Solaris 9, Java 1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
It's interesting to note that the FileUpload servlet catches the Stream ended
unexpectedly exception during parseRequest and is still able to
HttpServletResponse.send(500, e.getMessage()), which the client receives and
there are no other errors leading me to indicating the socket connection was
ganked.
I've applied a patch to the latest FileUpload 1.2-SNAPSHOT in SVN for
including
the root cause in exceptions, e.g.:
+++ src/java/org/apache/commons/fileupload/FileUploadBase.java
@@ -381,9 +381,9 @@
} catch (IOException e) {
-throw new FileUploadException(
-Processing of + MULTIPART_FORM_DATA
-+ request failed. + e.getMessage());
+throw (FileUploadException) new FileUploadException(
+Processing of + MULTIPART_FORM_DATA
++ request failed. + e.getMessage()).initCause(e);
}
Here is a stacktrace of one of the random Stream ended unexpectedly
exceptions:
2006-05-16 16:59:03,947 ERROR [com.xo.nextgen.fileupload.FileUploadServlet]
doPost: Failed to parse uploads from request: Processing of
multipart/form-data request failed. Stream ended unexpectedly
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Stream ended unexpectedly
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
at
com.xo.nextgen.fileupload.FileUploadServlet.doPost(FileUploadServlet.java:278)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:275)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520
[jira] Created: (FILEUPLOAD-106) parseRequest randomly throws Stream ended unexpectedly
parseRequest randomly throws Stream ended unexpectedly
--
Key: FILEUPLOAD-106
URL: http://issues.apache.org/jira/browse/FILEUPLOAD-106
Project: Commons FileUpload
Type: Bug
Versions: Nightly Builds
Environment: The client and server environments are all Solaris 9, Java
1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
Reporter: Gerald Turner
Hello, I have an application using FileUpload which intermittently encounters
this error as well, about once every 100 uploads. It's a simple servlet that
writes posted files to disk. The client application that is posting to this
FileUpload servlet is using Jakarta Commons HttpClient 3.0.1 with features such
as MultipartRequestEntity and MultiThreadedHttpConnectionManager.
Typically the posts contain two to three FileParts, a few 20KB audio/x-wav
files accompanied by a 15KB application/voicexml+xml file.
The servlet is actually running on two different servers, and the single client
posts to both of them, this occasional Stream ended unexpectedly error will
occur on one server and still succeed on the other.
The client and server environments are all Solaris 9, Java 1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
It's interesting to note that the FileUpload servlet catches the Stream ended
unexpectedly exception during parseRequest and is still able to
HttpServletResponse.send(500, e.getMessage()), which the client receives and
there are no other errors leading me to indicating the socket connection was
ganked.
I've applied a patch to the latest FileUpload 1.2-SNAPSHOT in SVN for including
the root cause in exceptions, e.g.:
+++ src/java/org/apache/commons/fileupload/FileUploadBase.java
@@ -381,9 +381,9 @@
} catch (IOException e) {
-throw new FileUploadException(
-Processing of + MULTIPART_FORM_DATA
-+ request failed. + e.getMessage());
+throw (FileUploadException) new FileUploadException(
+Processing of + MULTIPART_FORM_DATA
++ request failed. + e.getMessage()).initCause(e);
}
Here is a stacktrace of one of the random Stream ended unexpectedly
exceptions:
2006-05-16 16:59:03,947 ERROR [com.xo.nextgen.fileupload.FileUploadServlet]
doPost: Failed to parse uploads from request: Processing of multipart/form-data
request failed. Stream ended unexpectedly
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Stream ended unexpectedly
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
at
com.xo.nextgen.fileupload.FileUploadServlet.doPost(FileUploadServlet.java:278)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:275)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109
[jira] Updated: (FILEUPLOAD-106) parseRequest randomly throws Stream ended unexpectedly
[ http://issues.apache.org/jira/browse/FILEUPLOAD-106?page=all ]
Gerald Turner updated FILEUPLOAD-106:
-
Attachment: commons-fileupload-1.2-SNAPSHOT-initCause.patch
Patch which adds Throwable.initCause to various rethrows in FileUploadBase and
MultipartStream in order to debug the root cause of which Stream ended
unexpecedly was thrown.
parseRequest randomly throws Stream ended unexpectedly
--
Key: FILEUPLOAD-106
URL: http://issues.apache.org/jira/browse/FILEUPLOAD-106
Project: Commons FileUpload
Type: Bug
Versions: Nightly Builds
Environment: The client and server environments are all Solaris 9, Java
1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
Reporter: Gerald Turner
Attachments: commons-fileupload-1.2-SNAPSHOT-initCause.patch
Hello, I have an application using FileUpload which intermittently encounters
this error as well, about once every 100 uploads. It's a simple servlet that
writes posted files to disk. The client application that is posting to this
FileUpload servlet is using Jakarta Commons HttpClient 3.0.1 with features
such
as MultipartRequestEntity and MultiThreadedHttpConnectionManager.
Typically the posts contain two to three FileParts, a few 20KB audio/x-wav
files accompanied by a 15KB application/voicexml+xml file.
The servlet is actually running on two different servers, and the single
client
posts to both of them, this occasional Stream ended unexpectedly error will
occur on one server and still succeed on the other.
The client and server environments are all Solaris 9, Java 1.4.2_05, JBoss
3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
a few LANs with very low latency (2ms).
It's interesting to note that the FileUpload servlet catches the Stream ended
unexpectedly exception during parseRequest and is still able to
HttpServletResponse.send(500, e.getMessage()), which the client receives and
there are no other errors leading me to indicating the socket connection was
ganked.
I've applied a patch to the latest FileUpload 1.2-SNAPSHOT in SVN for
including
the root cause in exceptions, e.g.:
+++ src/java/org/apache/commons/fileupload/FileUploadBase.java
@@ -381,9 +381,9 @@
} catch (IOException e) {
-throw new FileUploadException(
-Processing of + MULTIPART_FORM_DATA
-+ request failed. + e.getMessage());
+throw (FileUploadException) new FileUploadException(
+Processing of + MULTIPART_FORM_DATA
++ request failed. + e.getMessage()).initCause(e);
}
Here is a stacktrace of one of the random Stream ended unexpectedly
exceptions:
2006-05-16 16:59:03,947 ERROR [com.xo.nextgen.fileupload.FileUploadServlet]
doPost: Failed to parse uploads from request: Processing of
multipart/form-data request failed. Stream ended unexpectedly
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Stream ended unexpectedly
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
at
com.xo.nextgen.fileupload.FileUploadServlet.doPost(FileUploadServlet.java:278)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:275)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke
Re: Jira down ?
On Wed, Jan 12, 2005 at 12:45:28PM +0100, Emmanuel Bourg wrote: Paul Libbrecht wrote: I seem to see no connection possible since yesterday night to the Apache Jira resulting in a proxy error. What's the good address to notify of such a problem ? in Bugzilla ? ;) or the infrastructure list: http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure Thanks for the note. It's back up again now. --Jeff Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA)
(from a commons-dev thread where it has strayed OT..) On Tue, Jan 20, 2004 at 06:54:11PM -0500, Henri Yandell wrote: On Tue, 20 Jan 2004, Noel J. Bergman wrote: Any reason for forcing people to register to put a bug in? It's just an administration choice for JIRA if I recall. I'll remind you that bugzilla is configured the same way. You must be logged in if you want to create a bug report. The difference is that bugzilla has a link, but you get redirected to a login page, first, whereas Jira doesn't give you the option unless you are logged in. Yeah, it's always a grumble of mine with public bug tracking systems. I wanted to quickly be a good citizen and make a note, not join the community. +1 Frequently I've thought sod it and gone elsewhere when confronted by a Yet Another login form. Given that any change is mailed to the relevant project list, so from an oversight POV, making an anonymous bug entry seems no different to editing a Wiki page. So is there any reason we shouldn't enable anonymous issue posting/commenting, if projects want it? Alternatively, the 'Create Issue' link in JIRA can be exposed by commenting out the permission check in includes/decorators/bodytop.jsp. Users clicking on 'Create Issue': http://nagoya.apache.org/jira/secure/CreateIssue!default.jspa will be asked to log in, and then redirected back to the create issue page. --Jeff That said, you're right, the apache bugzilla does do that doesn't it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] patch for MethodLookupUtils.lookupStaticMethod
Dmitri Plotnikov wrote:
Joern,
I have updated the code to allow null as the argument parameters.
thanks, so i can throw away my patch.
Regards,
Joern
- Dmitri
- Original Message -
From: __matthewHawthorne [EMAIL PROTECTED]
To: Jakarta Commons Users List [EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 9:12 PM
Subject: Re: [jxpath] patch for MethodLookupUtils.lookupStaticMethod
If you can, create a patch and submit it to Bugzilla. That way, it
won't get lost in the mix.
joern turner wrote:
hello,
found a problem in MethodLookupUtils when defining a custom function
with no arguments cause the passed parameter array is null in that case.
a simple test for null and providing an empty Class array in this case
solves the issue.
public static Method lookupStaticMethod(
Class targetClass,
String name,
Object[] parameters)
{
boolean tryExact = true;
Class types[];
if(parameters==null){
types = new Class[0];
}else{
int count = parameters.length;
types = new Class[count];
for (int i = 0; i count; i++) {
Object param = parameters[i];
if (param != null) {
types[i] = param.getClass();
}
else {
types[i] = null;
tryExact = false;
}
}
}
Regards,
Joern Turner
-
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: DBCP deadlock patch
Rodney Waldhoff [EMAIL PROTECTED] writes: I saw the bugzilla note come through, but I haven't had a chance to take a detailed look at it yet. Hopefully I should be able to get to this by the end of the week (unless someone beats me to it, hint, hint :). Have you had a chance to look at it yet? I noticed Tomcat 4.1.21 Beta was just released and I was hoping this patch would make it into a new DBCP release for inclusion in the next release of Tomcat. BTW, the patch is really basic (inserts additional property passing statements) and fits the exsisting coding style. I'm beginning to think I'm the only victim of an ill-configured corporate firewall (Cisco PIX, NAT occurs between LAN and DMZ, unroutable connections hang on open). Why just the other week I was battling an RMI problem with similar symptoms - I'm having to write my own idle timer for a JMS connection :( On Mon, 3 Feb 2003, Gerald Turner wrote: Has anyone looked at the bug #16581? I've attached a patch which merely propagates the idle eviction properties to BasicDataSourceFactory. -- Gerald TurnerEmail: [EMAIL PROTECTED]Phone: (503) 788-1720 GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP deadlock patch
Has anyone looked at the bug #16581? I've attached a patch which merely propagates the idle eviction properties to BasicDataSourceFactory. -- Gerald TurnerEmail: [EMAIL PROTECTED]Phone: (503) 788-1720 GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator LocaleTest.java validator-locale.xml ValidatorTestSuite.java
turner 2003/01/19 22:15:06 Modified:validator/src/share/org/apache/commons/validator ValidatorResources.java ValidatorResourcesInitializer.java validator/src/test/org/apache/commons/validator ValidatorTestSuite.java Added: validator/conf/share validator_1_0_1.dtd validator/src/test/org/apache/commons/validator LocaleTest.java validator-locale.xml Log: Fixes bug 16073. Makes variant work for formsets, and adds it back into the DTD. Moves a few info statements to debug statements to clear up log clutter Revision ChangesPath 1.1 jakarta-commons/validator/conf/share/validator_1_0_1.dtd Index: validator_1_0_1.dtd === !-- DTD for the Validator Rules Configuration File, Version 1.0 To allow for XML validation of your rules configuration file, include the following DOCTYPE element at the beginning (after the xml declaration): !DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0.1//EN http://jakarta.apache.org/commons/dtds/validator_1_0_1.dtd; $Id: validator_1_0_1.dtd,v 1.1 2003/01/20 06:15:06 turner Exp $ -- !-- === Top Level Elements -- !-- The form-validation element is the root of the configuration file hierarchy, and contains nested elements for all of the other configuration settings. -- !ELEMENT form-validation (global*, formset*) !-- The elements defined here are all global and must be nested within a global element. -- !ELEMENT global (validator*, constant*) !-- The validator element defines what validators objects can be used with the fields referenced by the formset elements. The validator element can accept 4 properties: name, classname, method, methodparams, msg, depends, and jsFunctionName. -- !ELEMENT validator (javascript?) !ATTLIST validator name CDATA #REQUIRED classname CDATA #REQUIRED method CDATA #REQUIRED methodParams CDATA #REQUIRED msgCDATA #REQUIRED dependsCDATA #IMPLIED jsFunctionName CDATA #IMPLIED !-- The javascript element defines a JavaScript that can be used to perform client-side validators. -- !ELEMENT javascript (#PCDATA) !-- The constant element defines a static value that can be used as replacement parameters within field elements. The constant-name and constant-value elements define the constant's reference id and replacement value. -- !ELEMENT constant (constant-name, constant-value) !ELEMENT constant-name (#PCDATA) !ELEMENT constant-value (#PCDATA) !-- The formset element defines a set of forms for a locale. Formsets for specific locales can override only those fields that change. The localization is properly scoped, so that a formset can override just the language, or just the country, or both. -- !ELEMENT formset (constant*, form+) !ATTLIST formset language CDATA #IMPLIED country CDATA #IMPLIED variant CDATA #IMPLIED !-- The form element defines a set of fields to be validated. The name corresponds to the identifer the application assigns to the form. -- !ELEMENT form(field+ ) !ATTLIST formname CDATA #REQUIRED !-- The field element defines the properties to be validated. In a web application, a field would also correspond to a control on a HTML form. To validate the properties, the validator works through a JavaBean representation. The field element can accept up to 4 attributes: propertyThe property on the JavaBean corresponding to this field element. depends The comma-delimited list of validators to apply against this field. For the field to succeed, all the validators must succeed. pageThe JavaBean corresponding to this form may include a page property. Only fields with a page attribute value that is equal to or less than the page property on the form JavaBean are processed. This is useful when using a wizard approach to completing a large form, to ensure that a page is not skipped. [0] indexedListProperty
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator EmailTest.java
turner 2003/01/19 22:28:37
Modified:validator/src/share/org/apache/commons/validator
GenericValidator.java
validator/src/test/org/apache/commons/validator
EmailTest.java
Log:
Fixes bug 15898
Dots at the end of domain names
Revision ChangesPath
1.9 +9 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java
Index: GenericValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- GenericValidator.java 16 Oct 2002 22:17:31 - 1.8
+++ GenericValidator.java 20 Jan 2003 06:28:37 - 1.9
@@ -424,8 +424,13 @@
// Check the whole email address structure
bValid = matchEmailPat.match(emailPat, value);
+if (value.endsWith(.)) {
+bValid = false;
+}
+
// Check the user component of the email address
if (bValid) {
+
String user = matchEmailPat.group(1);
// See if user is valid
1.5 +17 -4
jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java
Index: EmailTest.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EmailTest.java15 Dec 2002 21:46:41 - 1.4
+++ EmailTest.java20 Jan 2003 06:28:37 - 1.5
@@ -200,6 +200,19 @@
}
/**
+* pTests the e-mail validation with a dot at the end of
+* the address./p
+ */
+ public void testEmailWithDotEnd() throws ValidatorException {
+ // Create bean to run test on.
+ ValueBean info = new ValueBean();
+
+ info.setValue([EMAIL PROTECTED]);
+ valueTest(info, false);
+
+ }
+
+ /**
* Utlity class to run a test on a value.
*
* @param infoValue to run test on.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator EmailTest.java
turner 2003/01/19 22:50:27
Modified:validator/src/share/org/apache/commons/validator
GenericValidator.java
validator/src/test/org/apache/commons/validator
EmailTest.java
Log:
Fixes bug 16198 , non-ascii characters are now blocked in e-Mail addresses
Revision ChangesPath
1.10 +10 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java
Index: GenericValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- GenericValidator.java 20 Jan 2003 06:28:37 - 1.9
+++ GenericValidator.java 20 Jan 2003 06:50:26 - 1.10
@@ -406,6 +406,7 @@
String word = ( + atom + | + quotedUser + );
// Each pattern must be surrounded by /
+String legalAsciiPat = getDelimittedRegexp(^[\\000-\\177]+$);
String emailPat = getDelimittedRegexp(^(.+)@(.+)$);
String ipDomainPat =
getDelimittedRegexp(^(\\d{1,3})[.](\\d{1,3})[.](\\d{1,3})[.](\\d{1,3})$);
String userPat = getDelimittedRegexp(^ + word + (\\. + word + )*$);
@@ -417,10 +418,15 @@
Perl5Util matchIPPat = new Perl5Util();
Perl5Util matchDomainPat = new Perl5Util();
Perl5Util matchAtomPat = new Perl5Util();
+ Perl5Util matchAsciiPat = new Perl5Util();
boolean ipAddress = false;
boolean symbolic = false;
+if (!matchAsciiPat.match(legalAsciiPat, value)) {
+return false;
+}
+
// Check the whole email address structure
bValid = matchEmailPat.match(emailPat, value);
1.6 +17 -4
jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java
Index: EmailTest.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EmailTest.java20 Jan 2003 06:28:37 - 1.5
+++ EmailTest.java20 Jan 2003 06:50:26 - 1.6
@@ -213,6 +213,19 @@
}
/**
+* pTests the e-mail validation with an RCS-noncompliant character in
+* the address./p
+ */
+ public void testEmailWithBogusCharacter() throws ValidatorException {
+ // Create bean to run test on.
+ ValueBean info = new ValueBean();
+
+ info.setValue(andy.noble@\u008fdata-workshop.com);
+ valueTest(info, false);
+
+ }
+
+ /**
* Utlity class to run a test on a value.
*
* @param infoValue to run test on.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator RELEASE-NOTES.txt
turner 2002/12/13 00:12:51 Modified:validator RELEASE-NOTES.txt Log: Release notes for 1.01 release Revision ChangesPath 1.2 +12 -12jakarta-commons/validator/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/validator/RELEASE-NOTES.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RELEASE-NOTES.txt 21 Oct 2002 04:53:12 - 1.1 +++ RELEASE-NOTES.txt 13 Dec 2002 08:12:51 - 1.2 @@ -1,7 +1,7 @@ $Id$ Commons Validator Package - Version 1.0 + Version 1.01 Release Notes @@ -10,22 +10,22 @@ This document contains the release notes for this version of the Commons Validator package. -Because Struts 1.1 depends on Commons Validator, it is important to have -a stable Validator release before Struts 1.1 is released. In addition, -Validator has never had a release, meaning that there has been no stable -release for other developers to work from, only the nightly build. - -With a clean bug list, Validator seems ready to go out into the world for -a 1.0 release. On the other side of the release, we anticipate improving -the documentation, writing more test cases, and doing some code cleanup. +This is a bugfix release based on the Commons Validator 1.0 release. No new +functionality is introduced. +A new requirement is introduced by virtue of one of the bug fixes. Any +validator rule must now return a value which implements Serializable. NEW FEATURES: -N/A, first release +None BUG FIXES: -See Above +14591: Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus + +14384: ValidatorResources.get-method not working properly + + -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorResources.java
turner 2002/12/04 13:24:01
Modified:validator/src/share/org/apache/commons/validator
ValidatorResources.java
Log:
Fixed bug 14384, refactored code a bit to remove lots of redundent stuff.
Thanks to Björn-H. Moritz for suggesting the fix.
Revision ChangesPath
1.8 +20 -39
jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResources.java
Index: ValidatorResources.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResources.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ValidatorResources.java 16 Oct 2002 18:48:08 - 1.7
+++ ValidatorResources.java 4 Dec 2002 21:24:01 - 1.8
@@ -255,44 +255,25 @@
Vector v = (Vector) hFormSets.get(key);
- if (v == null) return f;
-
- Enumeration formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
- }
- }
+ if (v == null) {
+ key = ((language != null language.length() 0) ? language : ) +
+ ((country != null country.length() 0) ? _ + country : );
+ v = (Vector) hFormSets.get(key);
}
- key = ((language != null language.length() 0) ? language : ) +
- ((country != null country.length() 0) ? _ + country : );
-
- formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
- }
- }
+
+ if (v == null) {
+ key = ((language != null language.length() 0) ? language : );
+ v = (Vector) hFormSets.get(key);
}
- key = ((language != null language.length() 0) ? language : );
- formsets = v.elements();
- while (formsets.hasMoreElements()) {
- o = formsets.nextElement();
- if (o != null) {
- fs = (FormSet)o;
- if ((fs != null) (fs.getForm(formKey) != null)) {
- return fs.getForm(formKey);
- }
- }
+
+ if (v == null) {
+ key = defaultLocale.toString();
+ v = (Vector) hFormSets.get(key);
}
- key = defaultLocale.toString();
- formsets = v.elements();
+
+ if (v == null) return null;
+
+ Enumeration formsets = v.elements();
while (formsets.hasMoreElements()) {
o = formsets.nextElement();
if (o != null) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Validator 1.0 Release
It's Halloween, time for something truly spooky... The Validator 1.0 Release! Technically, there are only four committers in Validator (their names will be omitted to protect the Innocent, You Know Who You Are...), so it's not much of a vote, but the rules say I gotta go through the motions. So, please mark your ballots (good practice for those of us in the US with November 5th looming.) Remember, no hanging chads, and vote for only one candidate... +1: It's about time we finally shipped this sucker. 0: I wanted to vote for Al Gore but couldn't find him on this ballot -1: I have a good reason to hold up the release. (Oh yah, +1 from me.) James -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Validator 1.0 RC3 Available
We've had to do a few intermediate RCs since RC1 was released last week (one to fix a DTD issue, one to close out an obscure but important bug) The latest Validator release candidate (RC3) can be found at: http://jakarta.apache.org/builds/jakarta-commons/release/commons-validator/v 1.0_rc3/ The intent, baring any unusual problems, is to vote on this RC as the 1.0 release on Halloween (Oct 31st). Enjoy (and thanks for Martin Cooper for more RC magic) James -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Validator.java
turner 2002/10/24 20:22:55
Modified:validator/src/share/org/apache/commons/validator
Validator.java
Log:
Fixed bug 13932, Cannot use same name for field and validator, validator is never
invoked. Thanks to Padma Ginnaram for the catch.
Revision ChangesPath
1.10 +9 -7
jakarta-commons/validator/src/share/org/apache/commons/validator/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Validator.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Validator.java24 Sep 2002 20:23:35 - 1.9
+++ Validator.java25 Oct 2002 03:22:55 - 1.10
-334,9 +334,11
ValidatorResults results,
Map hActions,
int pos) throws ValidatorException {
- if (results.getValidatorResult(va.getName()) != null) {
- return isValid(results.getValidatorResult(va.getName()));
- }
+ if (results.getValidatorResult(field.getKey()) != null) {
+ValidatorResult result = results.getValidatorResult(field.getKey());
+if (result.containsAction(va.getName()))
+ return result.isValid(va.getName());
+}
if (va.getDepends() != null) {
StringTokenizer st = new StringTokenizer(va.getDepends(), ,);
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/validator/conf/share validator_1_0.dtd
turner 2002/10/22 12:59:40 Modified:validator/conf/share validator_1_0.dtd Log: Fix DTD to include formset and constant in the appropriate elements, also make formset, constant and validator optional, so that a file can have any or all of them Revision ChangesPath 1.3 +9 -6 jakarta-commons/validator/conf/share/validator_1_0.dtd Index: validator_1_0.dtd === RCS file: /home/cvs/jakarta-commons/validator/conf/share/validator_1_0.dtd,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- validator_1_0.dtd 16 Oct 2002 22:51:01 - 1.2 +++ validator_1_0.dtd 22 Oct 2002 19:59:40 - 1.3 -21,14 +21,14 hierarchy, and contains nested elements for all of the other configuration settings. -- -!ELEMENT form-validation (global+) +!ELEMENT form-validation (global*, formset*) !-- The elements defined here are all global and must be nested within a global element. -- -!ELEMENT global (validator+) +!ELEMENT global (validator*, constant*) !-- -73,7 +73,8 -- !ELEMENT formset (constant*, form+) !ATTLIST formset language CDATA #IMPLIED - country CDATA #IMPLIED + country CDATA #IMPLIED + resource CDATA #IMPLIED !-- -81,7 +82,8 corresponds to the identifer the application assigns to the form. -- !ELEMENT form(field+ ) -!ATTLIST formname CDATA #REQUIRED +!ATTLIST formname CDATA #REQUIRED + resource CDATA #IMPLIED !-- -117,7 +119,8 !ATTLIST field property CDATA #REQUIRED depends CDATA #IMPLIED page CDATA #IMPLIED - indexedListProperty CDATA #IMPLIED + indexedListProperty CDATA #IMPLIED + resource CDATE #IMPLIED !-- -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/validator/conf/share validator_1_0.dtd
turner 2002/10/22 18:32:01 Modified:validator/conf/share validator_1_0.dtd Log: Oopsie, added something else that I was working on and abandoned, removed the bogus resource attributes. Revision ChangesPath 1.4 +4 -7 jakarta-commons/validator/conf/share/validator_1_0.dtd Index: validator_1_0.dtd === RCS file: /home/cvs/jakarta-commons/validator/conf/share/validator_1_0.dtd,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- validator_1_0.dtd 22 Oct 2002 19:59:40 - 1.3 +++ validator_1_0.dtd 23 Oct 2002 01:32:01 - 1.4 -73,8 +73,7 -- !ELEMENT formset (constant*, form+) !ATTLIST formset language CDATA #IMPLIED - country CDATA #IMPLIED - resource CDATA #IMPLIED + country CDATA #IMPLIED !-- -82,8 +81,7 corresponds to the identifer the application assigns to the form. -- !ELEMENT form(field+ ) -!ATTLIST formname CDATA #REQUIRED - resource CDATA #IMPLIED +!ATTLIST formname CDATA #REQUIRED !-- -119,8 +117,7 !ATTLIST field property CDATA #REQUIRED depends CDATA #IMPLIED page CDATA #IMPLIED - indexedListProperty CDATA #IMPLIED - resource CDATE #IMPLIED + indexedListProperty CDATA #IMPLIED !-- -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Now available: Validator 1.0 RC1
The release candidate for Commons Validator is now available at: http://jakarta.apache.org/builds/jakarta-commons/release/commons-validator/v1.0_rc1/ The plan is to make this release the official Validator 1.0 release after a week for people to bang on it, and an official release vote. Shoutouts: To my main man, Martin C, master of da Maven script and keeper of da web stuff. To Struts-Doctor Craig for scoring me da keys to the source. And to Dave the Winterman for giving us such good stuff to riff offa. (Is there anything as pathetic as a middle-aged white guy trying to sound hip?) James -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/validator RELEASE-NOTES.txt
turner 2002/10/20 21:53:12 Added: validator RELEASE-NOTES.txt Log: Added release notes for upcoming 1.0 release Revision ChangesPath 1.1 jakarta-commons/validator/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === $Id: RELEASE-NOTES.txt,v 1.1 2002/10/21 04:53:12 turner Exp $ Commons Validator Package Version 1.0 Release Notes INTRODUCTION: This document contains the release notes for this version of the Commons Validator package. Because Struts 1.1 depends on Commons Validator, it is important to have a stable Validator release before Struts 1.1 is released. In addition, Validator has never had a release, meaning that there has been no stable release for other developers to work from, only the nightly build. With a clean bug list, Validator seems ready to go out into the world for a 1.0 release. On the other side of the release, we anticipate improving the documentation, writing more test cases, and doing some code cleanup. NEW FEATURES: N/A, first release BUG FIXES: See Above -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorResources.java
turner 2002/10/16 11:48:08
Modified:validator/src/share/org/apache/commons/validator
ValidatorResources.java
Log:
Changed ValidatorResources to store FormSets as a vector attached to the Locale key
rather than as a single element. The way it was, it was causing only the formset of
the last XML file for a given Locale to have it's FormSets saved.
Potentially very destabilizing change, but it passes the unit tests afterward, so I
think it's OK, since the changes are all internal to ValidatorResources (i.e., it's
all private access stuff, and the API is still the same.)
Only screw case I can think of is that if resource initialization is called multiple
times on the same Resource (and I couldn't think of a plausible case of this
happening), the FormSets are going to pile up on the Vector used to store it.
Fixed bug 10584
Revision ChangesPath
1.7 +122 -102
jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResources.java
Index: ValidatorResources.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResources.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ValidatorResources.java 30 Mar 2002 04:33:17 - 1.6
+++ ValidatorResources.java 16 Oct 2002 18:48:08 - 1.7
@@ -65,6 +65,8 @@
import java.io.Serializable;
import java.util.Collections;
import java.util.Iterator;
+import java.util.Enumeration;
+import java.util.Vector;
import java.util.Locale;
import java.util.Map;
import org.apache.commons.collections.FastHashMap;
@@ -120,7 +122,14 @@
*/
public void put(FormSet fs) {
if (fs != null) {
-hFormSets.put(buildKey(fs), fs);
+ String key = buildKey(fs);
+ if (hFormSets.get(key) == null) {
+ hFormSets.put(key, new Vector());
+ }
+ Vector formsets = (Vector) hFormSets.get(key);
+ if (!formsets.contains(fs)) {
+ formsets.add(fs);
+ }
if (log.isInfoEnabled()) {
log.info(Adding FormSet ' + fs.toString() + '.);
@@ -234,61 +243,67 @@
*lidefault locale/li
* /ol
*/
- public Form get(String language, String country, String variant, Object formKey)
{
- FormSet fs = null;
- Form f = null;
- String key = null;
- Object o = null;
+public Form get(String language, String country, String variant, Object
formKey) {
+ FormSet fs = null;
+ Form f = null;
+ String key = null;
+ Object o = null;
- key = ((language != null language.length() 0) ? language : ) +
+ key = ((language != null language.length() 0) ? language : ) +
((country != null country.length() 0) ? _ + country : ) +
((variant != null variant.length() 0) ? _ + variant : );
- o = hFormSets.get(key);
- if (o != null) {
- fs = (FormSet)o;
- if (fs != null)
-f = fs.getForm(formKey);
- }
+ Vector v = (Vector) hFormSets.get(key);
- if (f == null) {
- key = ((language != null language.length() 0) ? language : ) +
- ((country != null country.length() 0) ? _ + country : );
-
- o = hFormSets.get(key);
- if (o != null) {
-fs = (FormSet)o;
-if (fs != null)
- f = fs.getForm(formKey);
- }
-
- }
+ if (v == null) return f;
- if (f == null) {
- key = ((language != null language.length() 0) ? language : );
+ Enumeration formsets = v.elements();
+ while (formsets.hasMoreElements()) {
+ o = formsets.nextElement();
+ if (o != null) {
+ fs = (FormSet)o;
+ if ((fs != null) (fs.getForm(formKey) != null)) {
+ return fs.getForm(formKey);
+ }
+ }
+ }
+ key = ((language != null language.length() 0) ? language : ) +
+ ((country != null country.length() 0) ? _ + country : );
- o = hFormSets.get(key);
- if (o != null) {
-fs = (FormSet)o;
-if (fs != null)
- f = fs.getForm(formKey);
- }
- }
-
- if (f == null) {
- key = defaultLocale.toString();
-
- o = hFormSets.get(key);
- if (o != null) {
-fs = (FormSet)o;
-if (fs != null)
- f = fs.getForm(formKey);
- }
- }
-
-
- return f;
- }
+ formsets = v.elements();
+ while (formsets.hasMoreElements()) {
+ o = formsets.nextElement
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java
turner 2002/10/16 15:13:32 Modified:validator/src/share/org/apache/commons/validator Field.java Log: Fixes (completely) bug 13472 Revision ChangesPath 1.7 +5 -4 jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java Index: Field.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Field.java11 Oct 2002 01:49:33 - 1.6 +++ Field.java16 Oct 2002 22:13:32 - 1.7 @@ -498,6 +498,7 @@ hDependencies.setFast(true); } + hMsgs.setFast(true); } /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator GenericValidator.java
turner 2002/10/16 15:17:32 Modified:validator/src/share/org/apache/commons/validator GenericValidator.java Log: Remove extraneous import (fixes bug 13539) Revision ChangesPath 1.8 +4 -5 jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java Index: GenericValidator.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- GenericValidator.java 11 Oct 2002 01:16:37 - 1.7 +++ GenericValidator.java 16 Oct 2002 22:17:31 - 1.8 @@ -63,7 +63,6 @@ package org.apache.commons.validator; import java.io.Serializable; -import java.util.Date; import java.util.Locale; import java.text.DateFormat; import java.text.SimpleDateFormat; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/conf - New directory
turner 2002/10/11 11:03:22 jakarta-commons/validator/conf - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/conf/share - New directory
turner 2002/10/11 11:03:29 jakarta-commons/validator/conf/share - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/conf/share validator_1_0.dtd
turner 2002/10/11 11:05:28 Added: validator/conf/share validator_1_0.dtd Log: Move the ruleset DTD from Struts to Commons, change version to 1.0, remove struts-specfic comments from the DTD comments Revision ChangesPath 1.1 jakarta-commons/validator/conf/share/validator_1_0.dtd Index: validator_1_0.dtd === !-- DTD for the Validator Rules Configuration File, Version 1.0 To allow for XML validation of your rules configuration file, include the following DOCTYPE element at the beginning (after the xml declaration): !DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN http://jakarta.apache.org/validator/dtds/validator_1_0.dtd; $Id: validator_1_0.dtd,v 1.1 2002/10/11 18:05:28 turner Exp $ -- !-- === Top Level Elements -- !-- The form-validation element is the root of the configuration file hierarchy, and contains nested elements for all of the other configuration settings. -- !ELEMENT form-validation (global+) !-- The elements defined here are all global and must be nested within a global element. -- !ELEMENT global (validator+) !-- The validator element defines what validators objects can be used with the fields referenced by the formset elements. The validator element can accept 4 properties: name, classname, method, methodparams, msg, depends, and jsFunctionName. -- !ELEMENT validator (javascript?) !ATTLIST validator name CDATA #REQUIRED classname CDATA #REQUIRED method CDATA #REQUIRED methodParams CDATA #REQUIRED msgCDATA #REQUIRED dependsCDATA #IMPLIED jsFunctionName CDATA #IMPLIED !-- The javascript element defines a JavaScript that can be used to perform client-side validators. -- !ELEMENT javascript (#PCDATA) !-- The constant element defines a static value that can be used as replacement parameters within field elements. The constant-name and constant-value elements define the constant's reference id and replacement value. -- !ELEMENT constant (constant-name, constant-value) !ELEMENT constant-name (#PCDATA) !ELEMENT constant-value (#PCDATA) !-- The formset element defines a set of forms for a locale. Formsets for specific locales can override only those fields that change. The localization is properly scoped, so that a formset can override just the language, or just the country, or both. -- !ELEMENT formset (constant*, form+) !ATTLIST formset language CDATA #IMPLIED country CDATA #IMPLIED !-- The form element defines a set of fields to be validated. The name corresponds to the identifer the application assigns to the form. -- !ELEMENT form(field+ ) !ATTLIST formname CDATA #REQUIRED !-- The field element defines the properties to be validated. In a web application, a field would also correspond to a control on a HTML form. To validate the properties, the validator works through a JavaBean representation. The field element can accept up to 4 attributes: propertyThe property on the JavaBean corresponding to this field element. depends The comma-delimited list of validators to apply against this field. For the field to succeed, all the validators must succeed. pageThe JavaBean corresponding to this form may include a page property. Only fields with a page attribute value that is equal to or less than the page property on the form JavaBean are processed. This is useful when using a wizard approach to completing a large form, to ensure that a page is not skipped. [0] indexedListProperty The indexedListProperty is the method name that will return an array or a Collection used to retrieve the list and then loop through the list performing the validations for this field. -- !ELEMENT field (msg|arg0|arg1|arg2|arg3|var)* !ATTLIST field property CDATA #REQUIRED depends CDATA #IMPLIED page CDATA #IMPLIED indexedListProperty CDATA #IMPLIED !-- The msg element defines
cvs commit: jakarta-commons/validator/src/example/org/apache/commons/validator/example - New directory
turner 2002/10/11 13:11:56 jakarta-commons/validator/src/example/org/apache/commons/validator/example - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example/org/apache/commons/validator applicationResources.properties ValidateBean.java ValidateExample.java validator-example.xml
turner 2002/10/11 13:17:50
Added: validator/src/example/org/apache/commons/validator/example
applicationResources.properties ValidateBean.java
ValidateExample.java validator-example.xml
Removed: validator/src/example/org/apache/commons/validator
applicationResources.properties ValidateBean.java
ValidateExample.java validator-example.xml
Log:
Move the examples into their own package under validator (closes bug 13549)
Revision ChangesPath
1.1
jakarta-commons/validator/src/example/org/apache/commons/validator/example/applicationResources.properties
Index: applicationResources.properties
===
# The error messages for the Validation Actions
errors.required=The {0} field is required.
errors.int=The {0} field is not an integer.
# The formatted names of the properties
nameForm.age.displayname=Age
nameForm.lastname.displayname=Last Name
nameForm.firstname.displayname=First Name
nameForm.city.displayname=City
nameForm.state.displayname=State
nameForm.postalCode.displayname=Postal Code
nameForm.street1.displayname=Street Address
1.1
jakarta-commons/validator/src/example/org/apache/commons/validator/example/ValidateBean.java
Index: ValidateBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/validator/src/example/org/apache/commons/validator/example/ValidateBean.java,v
1.1 2002/10/11 20:17:50 turner Exp $
* $Revision: 1.1 $
* $Date: 2002/10/11 20:17:50 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.validator.example;
/**
* pA simple bean to use with the Validator Example./p
*
* @author James Turner
* @version $Revision: 1.1 $ $Date: 2002/10/11 20:17:50 $
*/
public class ValidateBean extends Object {
String lastName, firstName, street1, street2, city, state, postalCode, age;
public void setLastName(String lastName
cvs commit: jakarta-commons/validator build.xml
turner 2002/10/11 13:18:05 Modified:validator build.xml Log: Move the examples into their own package under validator (closes bug 13549) Revision ChangesPath 1.10 +1 -1 jakarta-commons/validator/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/validator/build.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- build.xml 10 Oct 2002 23:56:27 - 1.9 +++ build.xml 11 Oct 2002 20:18:05 - 1.10 @@ -127,7 +127,7 @@ /copy /target target name=example depends=build-example description=runs example - java fork=yes classname=org.apache.commons.validator.ValidateExample + java fork=yes classname=org.apache.commons.validator.example.ValidateExample taskname=main failonerror=true classpath refid=example.classpath / /java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example - New directory
turner 2002/10/10 16:41:39 jakarta-commons/validator/src/example - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example/org/apache - New directory
turner 2002/10/10 16:41:56 jakarta-commons/validator/src/example/org/apache - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example/org/apache/commons - New directory
turner 2002/10/10 16:42:05 jakarta-commons/validator/src/example/org/apache/commons - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example/org/apache/commons/validator - New directory
turner 2002/10/10 16:42:12 jakarta-commons/validator/src/example/org/apache/commons/validator - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/example/org/apache/commons/validator ValidateBean.java ValidateExample.java applicationResources.properties validator-example.xml
turner 2002/10/10 16:44:32
Added: validator/src/example/org/apache/commons/validator
ValidateBean.java ValidateExample.java
applicationResources.properties
validator-example.xml
Log:
Revision ChangesPath
1.1
jakarta-commons/validator/src/example/org/apache/commons/validator/ValidateBean.java
Index: ValidateBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/validator/src/example/org/apache/commons/validator/ValidateBean.java,v
1.1 2002/10/10 23:44:32 turner Exp $
* $Revision: 1.1 $
* $Date: 2002/10/10 23:44:32 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.validator;
/**
* pA simple bean to use with the Validator Example./p
*
* @author James Turner
* @version $Revision: 1.1 $ $Date: 2002/10/10 23:44:32 $
*/
public class ValidateBean extends Object {
String lastName, firstName, street1, street2, city, state, postalCode, age;
public void setLastName(String lastName) {
this.lastName = lastName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public void setStreet1 (String street1) {
this.street1 = street1;
}
public void setStreet2(String street2) {
this.street2 = street2;
}
public void setCity(String city) {
this.city = city;
}
public void setState(String state) {
this.state = state;
}
public void setPostalCode(String postalCode) {
this.postalCode = postalCode;
}
public void setAge (String age) {
this.age = age;
}
public String getLastName() {
return this.lastName;
}
public String getFirstName() {
return this.firstName;
}
public String getStreet1 () {
return this.street1;
}
public String getStreet2() {
return this.street2;
}
public String getCity() {
return this.city
Re: Validator and Karma
Rob, Could you submit the patch to Bugzilla and I'll apply it after taking a look? Right now we're closing in on a release and are technically in feature freeze, but if it's common-sensical, I'd have no problem apply it. James At 08:02 AM 10/10/2002, Rob Leland wrote: I am trying to fix a bug in the Validator code for struts, and bring it up to date for logging. It would help if I had karma to the commons. Is that possible ? -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator build.xml
turner 2002/10/10 16:56:27
Modified:validator build.xml
Log:
Added build targets for build-example and example
Revision ChangesPath
1.9 +175 -145 jakarta-commons/validator/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/validator/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 19 Jul 2002 03:09:06 - 1.8
+++ build.xml 10 Oct 2002 23:56:27 - 1.9
@@ -1,145 +1,175 @@
-!--
- You will need Ant setup properly to run this script. The
build.properties.sample file
- will need to be edited to point to some jar files and renamed to
build.properties.
---
-project name=Commons Validator default=jar basedir=.
- !-- set global properties for this build --
- property file=build.properties/
- property file=../build.properties/
- property file=${user.home}/build.properties/
-
- property name=title value=Commons Validator /
- property name=name value=validator /
- property name=validator.jar value=commons-validator.jar/
- property name=src value=src /
- property name=build value=build /
- property name=test value=test /
- property name=share value=share /
- property name=dist value=dist /
- property name=docs value=docs /
- property name=build.javadocs value=${dist}/${docs}/api /
- property name=package.root value=org/apache/commons/validator/
-
- !-- Setting Classpath --
- path id=base.classpath
- pathelement path=${commons-beanutils.jar}/
- pathelement path=${commons-collections.jar}/
- pathelement path=${commons-digester.jar}/
- pathelement path=${commons-logging.jar}/
- pathelement path=${oro.jar}/
- /path
-
- path id=test.classpath
- path refid=base.classpath/
- pathelement path=${junit.jar}/
- pathelement location=${xerces.jar}/
- pathelement path=${commons-beanutils.jar}/
- pathelement path=${commons-collections.jar}/
- pathelement path=${commons-digester.jar}/
- pathelement path=${commons-logging.jar}/
- pathelement path=${dist}/${validator.jar} /
- pathelement path=${build}/${test} /
- /path
-
- path id=javadoc.classpath
- path refid=base.classpath/
- pathelement location=${xerces.jar}/
- pathelement path=${dist}/${validator.jar} /
- /path
-
- target name=init description=creates any directories needed by the build
process
- !-- Create the time stamp --
- tstamp/
- !-- Create the build directory structure used by compile --
- mkdir dir=${build}/${share}/
- /target
-
- !-- Compile shared source --
- target name=build depends=init description=builds binary distribution
- !-- Compile the java code from ${src}/${share} into ${build}/${share} --
- javac srcdir=${src}/${share}
- destdir=${build}/${share}
- classpath refid=base.classpath /
- /javac
- /target
-
- !-- Create distribution jar of shared source --
- target name=jar depends=build description=creates distributable jar of the
binaries
- !-- Create the ${dist} directory --
- mkdir dir=${dist} /
-
- !-- Put everything in ${build} --
- jar jarfile=${dist}/${validator.jar}
- basedir=${build}/${share}
- includes=${package.root}/**/
- /target
-
- !-- Create Javadocs --
- target name=javadocs depends=jar description=Creates the API
documentation
- mkdir dir=${build.javadocs}/
- javadoc packagenames=org.apache.commons.validator.*
- sourcepath=${src}/${share}
- destdir=${build.javadocs}
- author=true
- version=true
- windowtitle=${title} API
- doctitle=${title}
- classpath refid=javadoc.classpath /
- /javadoc
- /target
-
- !-- Create distribution --
- target name=dist depends=jar,javadocs description=creates complete
distribution
- !-- Create the ${dist} directory --
- mkdir dir=${dist} /
-
- copy todir=${dist} file=../LICENSE/
- /target
-
- !-- Clean build and dist directories --
- target name=clean
-description=Clean build and distribution directories
- delete dir=${build}/
- delete dir=${dist}/
- /target
-
- !-- Compile JUnit Tests --
- target name=build-test depends=jar description=builds binaries for
testing
- mkdir dir=${build}/${test}/
-
- !-- Compile the java code from ${src}/${test} into ${build}/${test} --
- javac srcdir=${src}/${test}
- destdir=${build
cvs commit: jakarta-commons/validator STATUS.html
turner 2002/10/10 17:15:23 Modified:validator STATUS.html Log: Update status of Validator Revision ChangesPath 1.6 +21 -19jakarta-commons/validator/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/validator/STATUS.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- STATUS.html 1 Oct 2002 00:12:13 - 1.5 +++ STATUS.html 11 Oct 2002 00:15:23 - 1.6 @@ -59,12 +59,24 @@ a name=Release Info/a h33. RELEASE INFO/h3 - pCurrent Release: strongUnreleased, CVS Repository Only/strong/p -pPlanned Next Release: TBD/p - - +pPlanned Next Release: 1.0/p +PTentative Release Date: November 1st, 2002/P +PRelease Manager: James Turner/P +BOPEN BUGS/BBR +7318 javascript: zero - means bad integer?? BR +7349 Date Validation passes invalid date BR +8787 Indexed field validation patch BR +10584 Not all validation files are read in Validation PlugIn BR +10782 If two fields are required, and one has a mask, the mask is BR +13030 Digester unable to resolve external DTD BR +13421 GenericValidator GenericTypeValidator unused variables J BR +13472 Attempt to modify FastHashMap while in fast mode through ite P +BTO DO/BBR +Add DTD for Validation XMLBR +Improve JavadocBR +Write basic tutorialP a name=Committers/a h34. COMMITTERS/h3 @@ -87,24 +99,14 @@ table border=1 tr -th width=80%Action Item/th +th width=70%Action Item/th th width=20%Volunteer/th - /tr - tr -tdCreate Unit Tests./td -tdDavid Winterfeldt/td - /tr - tr -tdCreate Examples./td -tdDavid Winterfeldt/td +th width=10%Expected/th /tr tr tdDocumentation./td -tdDavid Winterfeldt/td - /tr - tr -tdCreate a emValidatorResults/em class to return the status of validations performed (in emorg.apache.commons.validator.Validator/em's validate method)./td -tdDavid Winterfeldt/td +tdJames Turner/td +td1.0 Release/td /tr tr td @@ -112,7 +114,7 @@ a global validation rule for an address object that can then be referenced in a form element. /td -td/td +td/tdtdPost 1.0/td /tr /table -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator GenericTypeValidator.java GenericValidator.java
turner 2002/10/10 18:16:37
Modified:validator/src/share/org/apache/commons/validator
GenericTypeValidator.java GenericValidator.java
Log:
Removed unused variables and fixed JavaDoc
(Closes bug 13421 )
Revision ChangesPath
1.5 +5 -5
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericTypeValidator.java
Index: GenericTypeValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericTypeValidator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- GenericTypeValidator.java 2 Apr 2002 03:55:02 - 1.4
+++ GenericTypeValidator.java 11 Oct 2002 01:16:36 - 1.5
@@ -183,7 +183,7 @@
* is set to codefalse/code for all./p
*
* @paramvalue The value validation is being performed on.
- * @paramdatePattern The pattern passed to
codeSimpleDateFormat/code.
+ * @paramLocale The Locale to use to parse the date (system
default if null)
*/
public static Date formatDate(String value, Locale locale) {
Date date = null;
1.7 +7 -7
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java
Index: GenericValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- GenericValidator.java 19 Sep 2002 17:25:27 - 1.6
+++ GenericValidator.java 11 Oct 2002 01:16:37 - 1.7
@@ -174,7 +174,7 @@
* is set to codefalse/code for all./p
*
* @paramvalue The value validation is being performed on.
- * @paramdatePattern The pattern passed to
codeSimpleDateFormat/code.
+ * @paramLocale The locale to use for the date format,
defaults to the default system default if null.
*/
public static boolean isDate(String value, Locale locale) {
boolean bValid = true;
@@ -190,7 +190,7 @@
formatter.setLenient(false);
- Date date = formatter.parse(value);
+ formatter.parse(value);
} catch (ParseException e) {
bValid = false;
}
@@ -221,7 +221,7 @@
SimpleDateFormat formatter = new SimpleDateFormat(datePattern);
formatter.setLenient(false);
- Date date = formatter.parse(value);
+ formatter.parse(value);
if (strict) {
if (datePattern.length() != value.length()) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java
turner 2002/10/10 18:49:33
Modified:validator/src/share/org/apache/commons/validator Field.java
Log:
Can't modify a fast hash map while inside an iterate on it.
(Closes bug 13472 )
Revision ChangesPath
1.6 +5 -5
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Field.java30 Mar 2002 04:33:17 - 1.5
+++ Field.java11 Oct 2002 01:49:33 - 1.6
@@ -439,7 +439,7 @@
* to create the dependency codeMap/code.
*/
public void process(Map globalConstants, Map constants) {
- hMsgs.setFast(true);
+ hMsgs.setFast(false);
hArg0.setFast(true);
hArg1.setFast(true);
hArg2.setFast(true);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Validator 1.0 Release (Second Call)
That's certainly a reasonable request, getting the doc and examples in shape is a major requirement in my book for doing a 1.0 release. James At 03:04 PM 10/1/2002, Taras Tielkes wrote: I'm willing to help and contribute to this project in the future. (Especially where it concerns using this component outside of Struts) However, with the current documentation (ahem?), it's hard for me to even figure out *how* things are supposed to work, let alone see if they are working correctly. What I would really like to see is a sample (no unit test please, that's not what is needed) that demonstrates most of the functionality of commons-validator. I'm talking about a small, command-line application that does some non-trivial validation. Multiple dependant validations, using localized resources, some custom validations that return errors in a meaningful way, using commons-validator utility methods/classes where applicable. I think the presence of such a sample would help people understand how commons-validator can be used. This would again result in more community participation for this component. (At least, this applies to myself) And yes, this is a bit off-topic for this thread :-) Kind regards, tt might i suggestion that the validator component considers asking martin and scott to be committers? they've both volunteered to help with the release and are commons committers of good repute but (at the moment) their votes are non-binding. this means that you're still 2 votes short of the quorum you need. - robert On Friday, September 27, 2002, at 06:16 PM, Martin Cooper wrote: +1 I think it would be great if we could get a DTD into the first release, as Taras Tielkes suggested. It'd be nice to see his other comments addressed also, but I wouldn't hold up the first release for them. I can help with the release process if needed. -- Martin Cooper -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 9:23 AM To: [EMAIL PROTECTED] Subject: [VOTE] Validator 1.0 Release (Second Call) And yea, my first call unto the masses for a vote on a Validator 1.0 release was met with a deafening silence. So second try: please vote! +1: Finally having a release of Validator sounds good -1: I have a good reason why now would not be a good time to do a release James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Validator 1.0 Release (Second Call)
At 12:34 PM 9/27/2002, Scott Sanders wrote: You are volunteering to be the Release Manager? If so, I am +1, and willing the help with publishing if you don't have access. I am in fact volunteering to RM the release. So thanks for the vote, and the offer of help. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator STATUS.html
turner 2002/09/18 23:58:25 Modified:validator STATUS.html Log: Added myself to committers list. Revision ChangesPath 1.4 +1 -0 jakarta-commons/validator/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/validator/STATUS.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- STATUS.html 19 Jul 2002 02:44:58 - 1.3 +++ STATUS.html 19 Sep 2002 06:58:25 - 1.4 @@ -76,6 +76,7 @@ ul lia href=mailto:[EMAIL PROTECTED];David Winterfeldt/a/li lia href=mailto:[EMAIL PROTECTED];Craig McClanahan/a/li + lia href=mailto:[EMAIL PROTECTED];James Turner/a/li /ul a name=Action Items/a -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator RequiredIfTest.java validator-requiredif.xml TestValidator.java ValidatorTestSuite.java
turner 2002/09/19 10:11:46
Modified:validator/src/share/org/apache/commons/validator
Validator.java ValidatorResults.java
validator/src/test/org/apache/commons/validator
TestValidator.java ValidatorTestSuite.java
Added: validator/src/test/org/apache/commons/validator
RequiredIfTest.java validator-requiredif.xml
Log:
Committing enhancement speced in Bug 11541, allows validator rules to
gain access to validator object, and exposes hResources so that rules can pluck
off the submitted form bean,
Revision ChangesPath
1.8 +35 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Validator.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Validator.java30 Mar 2002 04:28:35 - 1.7
+++ Validator.java19 Sep 2002 17:11:46 - 1.8
@@ -87,6 +87,7 @@
* and the validation rules for a JavaBean./p
*
* @author David Winterfeldt
+ * @author James Turner
* @version $Revision$ $Date$
*/
public class Validator implements Serializable {
@@ -118,6 +119,13 @@
public static String FIELD_KEY = org.apache.commons.validator.Field;
/**
+* Resources key the codeValidator/code is stored under.
+* This will be automatically passed into a validation method
+* with the current codeValidator/code if it is
+* specified in the method signature.
+ */
+ public static String VALIDATOR_KEY = org.apache.commons.validator.Validator;
+ /**
* Resources key the codeLocale/code is stored.
* This will be used to retrieve the appropriate
* codeFormSet/code and codeForm/code to be
@@ -189,6 +197,20 @@
}
/**
+* Get a resource to be used during the processing
+* of validations.
+*
+* @param key The full class name of the parameter
+*of the validation method that
+*corresponds to the value/instance
+*passed in with it.
+ */
+
+ public Object getResource(String key) {
+ return hResources.get(key);
+ }
+
+ /**
* Gets the form name which is the key
* to a set of validation rules.
*/
@@ -320,12 +342,16 @@
if (hResources.containsKey(LOCALE_KEY)) {
locale = (Locale)hResources.get(LOCALE_KEY);
}
+ hResources.put(VALIDATOR_KEY, this);
if (locale == null) {
locale = Locale.getDefault();
}
Form form = null;
+ if (resources == null) {
+ throw new ValidatorException(Resources not defined for Validator);
+ }
if ((form = resources.get(locale, formName)) != null) {
Map hActions = resources.getValidatorActions();
List lActions = new ArrayList();
@@ -413,12 +439,17 @@
int size = lParams.size();
int beanIndexPos = -1;
int fieldIndexPos = -1;
+ int validatorIndexPos = -1;
Class[] paramClass = new Class[size];
Object[] paramValue = new Object[size];
for (int x = 0; x size; x++) {
String paramKey = (String)lParams.get(x);
+ if (VALIDATOR_KEY.equals(paramKey)) {
+ validatorIndexPos = x;
+ }
+
if (BEAN_KEY.equals(paramKey)) {
beanIndexPos = x;
}
1.3 +15 -5
jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResults.java
Index: ValidatorResults.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorResults.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ValidatorResults.java 30 Mar 2002 04:28:35 - 1.2
+++ ValidatorResults.java 19 Sep 2002 17:11:46 - 1.3
@@ -74,6 +74,7 @@
* validation rules processed on JavaBean./p
*
* @author David Winterfeldt
+ * @author James Turner
* @version $Revision$ $Date$
*/
public class ValidatorResults implements Serializable {
@@ -83,6 +84,15 @@
*/
protected Map hResults = new
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator GenericValidator.java
turner 2002/09/19 10:25:27
Modified:validator/src/share/org/apache/commons/validator
GenericValidator.java
Log:
Bug 11541
Added double, short and float range checking.
Revision ChangesPath
1.6 +41 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java
Index: GenericValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- GenericValidator.java 2 Apr 2002 01:59:11 - 1.5
+++ GenericValidator.java 19 Sep 2002 17:25:27 - 1.6
@@ -75,6 +75,7 @@
* performing validations./p
*
* @author David Winterfeldt
+ * @author James Turner
* @version $Revision$ $Date$
*/
public class GenericValidator implements Serializable {
@@ -248,6 +249,42 @@
* @parammax The maximum value of the range.
*/
public static boolean isInRange(int value, int min, int max) {
+ return ((value = min) (value = max));
+}
+
+/**
+ * pChecks if a value is within a range (min amp; max specified
+ * in the vars attribute)./p
+ *
+ * @paramvalue The value validation is being performed on.
+ * @parammin The minimum value of the range.
+ * @parammax The maximum value of the range.
+*/
+public static boolean isInRange(float value, float min, float max) {
+ return ((value = min) (value = max));
+}
+
+/**
+ * pChecks if a value is within a range (min amp; max specified
+ * in the vars attribute)./p
+ *
+ * @paramvalue The value validation is being performed on.
+ * @parammin The minimum value of the range.
+ * @parammax The maximum value of the range.
+*/
+public static boolean isInRange(short value, short min, short max) {
+ return ((value = min) (value = max));
+}
+
+/**
+ * pChecks if a value is within a range (min amp; max specified
+ * in the vars attribute)./p
+ *
+ * @paramvalue The value validation is being performed on.
+ * @parammin The minimum value of the range.
+ * @parammax The maximum value of the range.
+*/
+public static boolean isInRange(double value, double min, double max) {
return ((value = min) (value = max));
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
VOTE: Behavior of Validator
As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons-dev Digest 18 Sep 2002 15:52:45 -0000 Issue 958
At 11:52 AM 9/18/2002, Craig R. McClanahan wrote: Commons Folks, I'd like to propose James Turner [EMAIL PROTECTED] as a committer on the Commons Validator project (and a new committer to Apache). He has taken the time to understand the Validator code base quite well, submitted many useful bug reports and patches, and has the itch to improve the quality of this component, and has shown remarkable forebearance and persistence in getting paid attention to :-). Thanks Craig! If you folks take me on, I hope to drive Validator to a 1.0 release sometime soon, and then work on cleaning up and refactoring some of the code. FOR: shown remarkable forebearance and persistence in getting paid attention to READ: Has been enough of a pest about his patches that it would be easier to let him commit them himself :-) James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Latka] Setting a cookie
On Fri, Jun 07, 2002 at 10:31:43AM +1000, Glen Stampoultzis wrote: Is it possible to set a cookie using latka? If not could someone point me to how to extend latka to allow this? It looks like the session element ought to support a nested cookie element. At least there's an addCookie() method on the Session object, so it's probably just a job of adding the XML-Java mapping. Unfortunately my Maven is fubar'ed or something.. I can't build Latka (or cli). --Jeff Regards, Glen Stampoultzis (TriNexus Pty Ltd) Fixed:+61 3 9753-6850 Mob:+61 (0)402 835 458 ICQ: 62722370EMail: [EMAIL PROTECTED] URL's: http://jakarta.apache.org/poi, http://www.krysalis.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Sean Sullivan
+1 Welcome! --Jeff On Tue, Jun 04, 2002 at 02:39:02PM -0500, [EMAIL PROTECTED] wrote: I would like to nominate Sean Sullivan as a committer for the Jakarta Commons project. Sean has been active in providing patches and support the HttpClient project over the last several months and I think he would be a good addition to the community. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ committer vote ] - for an extra committer...
+1 --Jeff On Fri, May 24, 2002 at 12:18:51PM +1000, Arron Bates wrote: Already a committer on the Struts project, wodering if the committers of the commons would allow an extra hand for the project?... ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka Anteater
On Thu, May 16, 2002 at 10:41:55AM -0500, Morgan Delagrange wrote: - Original Message - From: Ivelin Ivanov [EMAIL PROTECTED] Jeff, Thank you for the extensive response. I am having hard time making a choice, but it appears that Anteater was built from scratch based on your experience with Latka and is therefore a more viable long term solution. Nono.. Ovidiu Predescu wrote Anteater, in order to automate Cocoon testing (at least partly). Here is his initial post (2001-09-21) outlining the need, and proposed Ant-based solution: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100108643304886w=2 I pointed Ovidiu to Latka, saying: Note that [Latka] doesn't use Ant. I suspect this is actually a good thing. Ant 1.x is not flexible enough to be easily repurposed as a http testing engine - http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100121712029019w=2 .. and how wrong I was ;P Ovidiu coded up Anteater in a remarkably short period of time, and announced an initial version here: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100221277132628w=2 (Full cocoon-dev thread is at http://marc.theaimsgroup.com/?t=10010867042r=1w=2) So the point is, Anteater was done in full knowledge of Latka (and Cactus). Ovidiu just wanted to try the Ant approach, and proved rather spectactularly that it's a good one. Anteater is a shining example of successful opportunism, whereas Latka is a shining example of traditional software engineering, crafting a solution to a problem. I don't know about that... :) I think the differences are greater than they appear; it depends on what your needs are. I'd try to enumerate which product is better for what, but it's open to interpretation and personal preference. Objectivism is overrated ;) I'm sure anything you have to say would be useful for people choosing. Can latka be used for writing complete test case scenarios: e.g. login, go through a product purchase, logout? I've written tests like that. You can wrap tests in a session tag, which retains cookies and referers between requests. You can't tell Latka to fill out forms or push buttons, but you can set request parameters and request headers to simulate that kind of user activity. Anteater doesn't have a session tag yet (it's in the TODO), so can't do this sort of thing. Do you plan to include an option for JUnit reporting in Anteater similar to Latka's, so that tests can integrated with all other junit tests? Yes that's planned, and there is already a formatter element implemented, but I've never seen it working. Ovidiu might know more. --Jeff At some point, Latka will probably come with an Ant task. Regards, Ivelin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Latka] XPath validator, BaseConditionalValidator class
On Thu, May 02, 2002 at 08:23:04PM -0400, bob mcwhirter wrote: Oh yeah, FYI I had to change one of the import statements. Jaxen appears to have renamed a class from org.jaxen.jdom.XPath to org.jaxen.jdom.JDOMXPath. Ah yes, and that's breaking the build, because Maven is pulling in jdom-b7.jar. Dion, do you know how to go about getting a jdom-b8.jar uploaded? --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Release Vote for BeanUtils 1.3 and Digester 1.2
On Mon, Apr 29, 2002 at 09:39:03AM -0700, Craig R. McClanahan wrote: Vote on releasing COMMONS-BEANUTILS Version 1.3 [ ] +1 I am in favor of this release and will help [X] +0 I am in favor of this release but cannot help [ ] -0 I am not in favor of this release [ ] -1 I am opposed to this release, and here is why: Vote on releasing COMMONS-DIGESTER Version 1.2 [ ] +1 I am in favor of this release and will help [X] +0 I am in favor of this release but cannot help [ ] -0 I am not in favor of this release [ ] -1 I am opposed to this release, and here is why: --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JXPath 1.0 Release Plan
+1 --Jeff On Wed, Apr 24, 2002 at 07:07:18AM -0700, Dmitri Plotnikov wrote: I am calling for a vote on the JXPath 1.0 Beta Release Plan .. I volunteer to be release manager for this release. Regards Dmitri Plotnikov. [EMAIL PROTECTED] Let me start with my vote 1. Adopt Proposed Release Plan[+1] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: new 'wrapper' commons component
On Mon, Apr 01, 2002 at 11:10:40AM -0800, [EMAIL PROTECTED] wrote: On Mon, 1 Apr 2002 [EMAIL PROTECTED] wrote: Hi, I would like to propose a new common component, based on code used in tomcat, avalon and other java servers to work as NT services and unix daemons. The initial code is based on the wrapper project at sourceforge, and will replace ( and be merged with ) the other components that duplicate the same functionality ( daemon, jk_nt_service, etc). Attached is the proposal, please send your votes. +1 Can anyone think of a more descriptive, less generic name than wrapper? :) --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] [Vote] Release Collections 2.0 build 4
LICENSE may be in the distribution, but the build.xml still references ../LICENSE, causing certain targets in the source distribution to fail: dist-jar: [mkdir] Created dir: /tmp/buildtemp_200204021013 [copy] Copying 88 files to /tmp/buildtemp_200204021013 [mkdir] Created dir: /tmp/buildtemp_200204021013/META-INF [copy] Could not find file /home/jeff/LICENSE to copy. BUILD FAILED /home/jeff/commons-collections-2.0-src/build.xml:258: Could not find file /home/jeff/LICENSE to copy. Otherwise, all looks good. --Jeff On Mon, Apr 01, 2002 at 12:27:02PM -0600, Morgan Delagrange wrote: Hi all, Third time is a charm. Please vote on whether or not to release the latest Collections 2.0 build: ... http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.0/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] beanutils build system
Hi Jon,
Would you be happy (ie, would it build on your system) if we applied the
patch with the following modifications?
1) Source ${basedir}/build.properties before
${user.home}/build.properties
Many people have a ~/build.properties with default values, which only
needs to be overridden by ./build.properties for unusual cases. Changing
the order breaks these people's setups. So I'm proposing that the order
be:
property file=${basedir}/build.properties /
property file=${user.home}/beanutils.build.properties /
property file=${user.home}/build.properties /
property file=${basedir}/default.properties /
2) Not delete build.properties.sample. Ie, defaults.properties will
default the values to ${lib.repo}/.., but people without a jar
repository can still 'cp build.properties.sample build.properties' and
have things working.
I quite like the defaults.properties idea. Keeps build.xml clean, and
you don't lose your place in build.xml when looking up the value of a
property.
If we're all happy with this, the change should be done to all projects,
not just beanutils (yes I volunteer).
--Jeff
On Fri, Mar 22, 2002 at 03:33:54PM -0800, Jon Scott Stevens wrote:
Included is a patch for the beanutils build system so that it will build out
of the box without having to mv build.properties.sample to build.properties.
It removes the build.properties.sample file and adds it as
default.properties.
It basically implements a build system similar to Lucene, Scarab, Turbine,
etc...please apply it.
...
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
On Tue, Mar 19, 2002 at 09:14:53AM -0800, Daniel Rall wrote:
Jeff Turner [EMAIL PROTECTED] writes:
On Mon, Mar 18, 2002 at 07:49:29PM -0800, Daniel Rall wrote:
Why not use lib.repo instead of root? Many other projects are already
using this variable to point to the location where Java libraries are
rooted.
By library repository, do you mean a directory full of random jars,
copied or symlinked there from various projects?
Exactly. Preferably with version numbers in their file names. ;-)
there's the catch...
Is this a jar management scheme we want to encourage? :)
Yes. Practice has shown me that it works extremely well. In fact,
it's a time honored tradition, with the historical precedent dating
back the beginnings of Unix. See /lib, /usr/lib, and /usr/local/lib
on your favorite Unix or Linux box. Let's learn from history.
I agree that a /usr/lib repository mechanism is much better than the
project-centric approach, IF it's done properly. Specifically, if
version management is taken very seriously. Otherwise you end up with a
directory full of jars from who-knows-where.
If Maven has solved the versioning problem, then I'm keen to use it.
Until then, is there any reason we can't accomodate both systems? Heck,
they're just build properties ;)
I think we should assume a more structured, project-centric approach:
base.path = ${user.home}
jakarta.home = ${base.path}/jakarta
proj.home = ${jakarta.home}/...
proj.jar = ${proj.home}/...
junit.home = ${base.path}/junit3.7
junit.jar = ${junit.home}/junit.jar
This structure only works efficiently when you've checked out or
downloaded the dependent packages in the exact manner that the build
file's author did.
It works very efficiently if you accept the premises it's based on, that
users have either:
- checked stuff out from CVS and built a distribution (ant dist).
- downloaded a binary distribution (the standard Jakarta software
distribution mechanism).
If, rather, you're assuming a Maven-managed jar repository, then it's
not optimal.
I claim that most Jakarta-commons users are not using Maven (yet) and
therefore those assumptions are valid. Agree? But it's not an either/or
situation. You're more than welcome to add properties to accomodate a
more advanced, repository-centric approach.
I'm not too fussed either way. As long as there's *something* instead of
the various hardcoded paths I've seen (/java/jars, /cvs/, d:/java/lib,
etc). If we can get some +1's either way, I volunteer to update the
projects.
I am fussy. I'm so sick of building these projects where I have to
set a million build variables instead of just one or two to produce a
JAR (which I generally just need as a dependency for some other
project).
Absolutely. Every time I get a chance to work on a Commons project, I
first spend half an hour fiddling with dependencies to get it building.
--Jeff
- Dan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
On Mon, Mar 18, 2002 at 07:49:29PM -0800, Daniel Rall wrote:
Why not use lib.repo instead of root? Many other projects are already
using this variable to point to the location where Java libraries are
rooted.
By library repository, do you mean a directory full of random jars,
copied or symlinked there from various projects?
Is this a jar management scheme we want to encourage? :)
I think we should assume a more structured, project-centric approach:
base.path = ${user.home}
jakarta.home = ${base.path}/jakarta
proj.home = ${jakarta.home}/...
proj.jar = ${proj.home}/...
junit.home = ${base.path}/junit3.7
junit.jar = ${junit.home}/junit.jar
Assuming this, I think 'base.path' is better than 'lib.repo', because
it's specifying a base path, not a library repository.
I'm not too fussed either way. As long as there's *something* instead of
the various hardcoded paths I've seen (/java/jars, /cvs/, d:/java/lib,
etc). If we can get some +1's either way, I volunteer to update the
projects.
--Jeff
[EMAIL PROTECTED] writes:
jefft 02/03/18 17:30:59
Modified:digester build.properties.sample
Log:
More properties parametrization
Revision ChangesPath
1.5 +5 -3 jakarta-commons/digester/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-commons/digester/build.properties.sample,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.properties.sample 27 Feb 2002 00:50:33 - 1.4
+++ build.properties.sample 19 Mar 2002 01:30:59 - 1.5
@@ -1,5 +1,7 @@
-jaxp.jaxp.jar=/java/jars/jaxp.jar
-jaxp.parser.jar=/java/jars/crimson.jar
+root=/java/jars
+jaxp.home=${root}
+jaxp.jaxp.jar=${jaxp.home}/jaxp.jar
+jaxp.parser.jar=${jaxp.home}/crimson.jar
# Commons projects -- correct if 'ant dist' is run on each project in the
# default CVS directory layout
@@ -11,4 +13,4 @@
commons-logging.jar=${commons-logging.home}/commons-logging.jar
# junit.jar - JUnit 3.7+ Classpath
-junit.jar=/java/jars/junit.jar
+junit.jar=${root}/junit.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
On Mon, Mar 18, 2002 at 08:41:22PM -0800, Craig R. McClanahan wrote:
On Tue, 19 Mar 2002, Jeff Turner wrote:
On Mon, Mar 18, 2002 at 07:49:29PM -0800, Daniel Rall wrote:
Why not use lib.repo instead of root? Many other projects are already
using this variable to point to the location where Java libraries are
rooted.
...
I think we should assume a more structured, project-centric approach:
base.path = ${user.home}
jakarta.home = ${base.path}/jakarta
proj.home = ${jakarta.home}/...
proj.jar = ${proj.home}/...
junit.home = ${base.path}/junit3.7
junit.jar = ${junit.home}/junit.jar
...
The projects that inherit their build philosophy from Turbine definitely
like lib.repo, because they tend to put all the dependency JAR files in
one place.
The projects that inherit their build philosophy from Struts and Tomcat
definitely like base.path, because they assume that you have checked out
and built each of the dependent JARs, in a common base subdirectory. (For
me, for example, that is /home/craigmcc/Jakarta, with a subdirectory under
it for each CVS repository I care about, and I maintain the results of
ant dist builds in each case for the code that I currently develop
against).
The defaults from Digester have inherited the latter philosophy (because
of where the code came from), so base.path is a better name for
build.properties.sample in this case.
Thanks for the explanation.
NOTE: This isn't a value judgement on which philosophy is better -- both
are equally valid, but consistency within a particular philosophy is even
more important than choosing one or the other.
I rather thought Jakarta-commons had it's own internal consistency to
defend, irrespective of where a project originated.
No need for flames about such a trivial issue. Anyone who cares, please
vote:
[ ] Standardize on the project-centric 'base.path' approach.
[ ] Standardize on the repository-centric 'lib.repo' approach.
[ ] Leave as is.
--Jeff
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
On Tue, Mar 05, 2002 at 01:42:17PM -0500, Serge Knystautas wrote: I was just talking with a coworker about how to build some automated tests for our webapp, and sure enough Latka does a lot of what I was thinking. I had a few other todo items I might contribute, assuming I can get my client to pay or can otherwise find the time. I thought I'd bring up the ideas first to get some feedback on whether this is going in a good or bad direction: 1. meta process for test definition generation/maintenance I'd like to define a meta XML file for a webapp that could declare something like all HTML pages and JSPs in this webapp should be tested. Then new meta process code would use that meta XML to check that the Latka test definition meets these requirements... it would the recurse through the files in a webapp and look for them in the latka test file. How would you go about determining the URLs of all HTML pages and JSPs? Is this really *all* (ie you have inside information; it's your webapp you're testing), or just visible from the usual application workflow? Ie, is the list created by hand or created through a wget-like follow-the-links strategy? If there were gaps, the meta check could either a) fail with a list of pages that aren't included or (my preference) b) add them to the test file with some comments (and stop before running the latka test). By default it could just require 200 status codes for those newly spotted pages. The tester could then look at the bottom of the latka test file, and cut and paste the definitions up to suites or to more understandable places in the file, and otherwise flesh out the validations. 2. JTidy for HTML validation I would really like to be able to validate that the HTML in a site is well formed. If you mean well formed in the XML sense (XHTML), you could use the XPath validator, and just validate for something like '/'. I've tried doing it with a servlet filter, but using Latka would make much more sense. Ideally we could define the JTidy settings for a site and whether to test all by default, and let individual requests override that. Sounds good. 3. Better ant/junit integration Wasn't there an Ant task for running Latka in the works? Dion? I'd have to see what's already there, but as I use ant to do my builds already, I'd like to have 2 custom taskdefs that will a) do the meta checking that the latka tests are complete and b) run the latka test. If you're really keen on Ant integration, there's another testing framework called Anteater (http://sourceforge.net/projects/aft), which is 100% Ant tasks. It inherits a lot of expressive power from Ant itself. Eg, you can pattern-match or XPath-match, and then store the matched pattern/XML in an Ant property. You can also use Ant's parallel to start/stop Tomcat servers. --Jeff Comments? Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka notes
On Tue, Mar 05, 2002 at 09:54:55PM -0500, Serge Knystautas wrote: I don't think I explained my idea 1 very well based on comments. The issue I'm facing is making sure my latka suite stays current with the site as developers maintain the site. For an initial import, I might have a webapp with 350 JSPs... I don't want to manually build the latka suite for that. More importantly, as the team of developers add more JSPs, I want to know that some schmuck didn't add a JSP to CVS and not add it to the functional test. I would start with just a file system dir list, recursing through subdirs and listing all *.jsp files. (no link checking or wget or anything complex... just pure dir.list() with recursion). This would create a list like: /test.jsp /index.jsp /login.jsp /contacts/list.jsp /contacts/add.jsp /contacts/edit.jsp It would take these URLs and build the latka suite file. If there already was a latka suite file, it would append the files not already in there. Really this is just a tool/script to maintain the latka suite file. Perl, or shell would be easiest. If you want to keep location-independence (list URLs, not file paths), you could write a servlet that returns a list of directory contents as XML. Then use Ant's get to retrieve the XML listing, style to transform it into a Latka XML file, and off you go. I was getting somewhat ahead of myself with the meta decription, but I was thinking the filtering could get more advanced so that I included *.jsp and *.html, but excluded everything in /include since those pages are not directly called. Maybe I should just fashion this as an ant task so I can leverage it's include/exclude file pattern capabilities. Except in Ant you can't iterate over items in a fileset. Maybe there's some 3rd party tasks for that. On an unrelated note, I thought of two other validators... a) link checking, and b) xml validation (if your servlet is supposed to output XML instead of HTML). Anyone else working on these kind of validators? XML validation should be very easy (XPath does it for free). Link checking might need the JTidy one's capabilities first. AFAIK, no-one is working on them. --Jeff Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 5:34 PM Subject: Re: Latka notes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] thoughts on Java pre processor
On Wed, Mar 06, 2002 at 01:55:25AM -, James Strachan wrote:
...
So the aim of the preprocessor would be to allow us to add some syntax
suguar to Java to save us some typing and avoid redundancy. I just wondered
what others thoughts are. Here's a couple of ideas for some syntax sugar...
...
foreach?
==
To help avoid repetive code of the form...
for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
Foo foo = (Foo) iter.next();
foo.bar();
}
maybe introduce a C#-like foreach statement...
foreach( Foo foo in something.iterator() ) {
foo.bar();
}
and maybe throw in some logging syntax, which can be compiled to log4j,
the Commons logger or compiled out altogether.
--Jeff
(who once did write a preprocessor to let you embed declarative XML
statements like debug level=1This is a debug statement/debug in
Java. It worked by converting the marked up .java to XML, then applying
stylesheets ala XSP to transform debug to code, then stripping the XML
tags to get .java again. I thought it was neat :)
Just thinking aloud here (as always ;-). Thoughts?
James
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Vote] Mapper framework in sandbox (was RE: Commons Validator Pac kaging/Content)
On Tue, Jan 15, 2002 at 10:24:37AM +0100, Rey Francois wrote: I've sent this post yesterday but I'm pretty sure it will quickly fade under the abyss of all the posts on this list. So I post my proposal again, using a more appropriate title, and using the recommended format: Proposal for a mapper framework ... (1.5) interaction with other packages The mapper framework makes use of - the Commons Digester - the Commons BeanUtils - JavaCC - the Commons Pool (work in progress) Perhaps we should expand the meaning of interaction to include how it compares to existing Commons components with similar goals. I'm very happy to see components competing for the same turf (as the charter allows), as long as it's clear to newcomers (ie, me:) what the differences are, in terms of features, stability (esp. API contracts) and future development prospects. I want to know which to spend time learning. +1 for putting it in the sandbox (with a cleaned-up build system:) +10 if you could outline in the proposal how it differs from David's validator. Btw, the javadocs look very good, which to me is a sign of overall quality. --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Latka docs (Re: cvs commit: jakarta-commons/latka/doc index.xml)
It would be nice if we could use docbook within the standard Anakia-based website system. It should be doable simply be transforming the docbook to stylebook before running Anakia. This is what Avalon does (though using Cocoon instead of Anakia). The stylesheet is: jakarta-avalon/src/documentation/stylesheets/docbook2body.xsl There's also a Docbook - PDF stylesheet in Avalon. I'm telling people because I'm off tomorrow on holidays for 5 weeks, so may not have time to try this before I leave. --Jeff On Tue, Jan 15, 2002 at 09:56:02PM -, [EMAIL PROTECTED] wrote: morgand 02/01/15 13:56:02 Added: latka/doc index.xml Log: latka docbook before xpath validator doco -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[httpclient] Anakia outputting [Element:
Hi, When I run 'ant xdoc' from a cleanly checked-out httpclient, the HTML output contains: blockquote [Element: p/] [Element: p/] [Element: p/] /blockquote Anyone know why this would be happening? thanks, --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Latka AbstractReporter.java documentation
Applied, thanks. --Jeff On Fri, Jan 11, 2002 at 04:05:14PM +1100, dIon Gillard wrote: Index: ./latka/src/java/org/apache/commons/latka/AbstractReporter.java .. -- dIon Gillard, Multitask Consulting http://www.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Docs for Latka BaseRequestEvent.java
.. also applied. Thanks, --Jeff On Sun, Jan 13, 2002 at 02:00:12PM +1100, dion wrote: Index: latka/src/java/org/apache/commons/latka/event/BaseRequestEvent.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Update to Commons package approval guideline
+1 Although.. I can sort of see why the original required super-majority. Three +1's are very easy to get when approval doesn't necessarily mean that three committers are willing to support the code. Oh well, we'll see if it works :) --Jeff On Wed, Jan 09, 2002 at 02:26:20PM -0800, Martin Cooper wrote: The current Commons guidelines require a positive super-majority vote of active subproject committers before a new package is accepted into Commons. Given the number of committers in Commons today, I believe that this is no longer tenable. Therefore I propose that we update item #17 of the guidelines to require majority approval, as defined in the Jakarta guidelines, before a package is accepted into Commons. The replacement text for item #17 would be as follows: - 17. New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, and the initial set of committers. 1. As stated in the Jakarta guidelines, an action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes. - +1 from me. :-) -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka code formatting
On Mon, Jan 07, 2002 at 05:40:06PM -0600, Morgan Delagrange wrote: Hi Jeff, Would you object if I added something like this to the Latka docs? Latka follows the blah coding convention except that we like underscores for our class variables. +1 I tried to stick to that convention.. if I didn't, give me a poke and I'll fix. --Jeff If Turbine can do it, why not us? :) - Morgan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [proposal] some store components for the commons-sandbox
On Mon, Jan 07, 2002 at 06:46:35PM +0100, Gerhard Froehlich wrote: Hi, Currently I'm working on the Cocoon store and caching. I implemented some store components, that are maybe useful to migrate as Jakarta commons-sandbox components. They mainly exist of a: 1. Store - The overall interface 2. MRUMemoryStore - A simple MRU Memory Store class 3. JispFilesystemStore - A jisp (http://www.coyotegulch.com/jisp/index.html) based Filesystem store! 4. Some helper classes (Key's, etc...) We use this components in the Cocoon project as a fast (memory) and slow (filesystem) storage implementation. In the moment they are Avalon based components but I think they could easy changed into something more common ;-). Ok, do you think this Components are a try worth to book into the sandbox area or just a waste of time. That would be very cool. I didn't know Cocoon's cache/store was 'detachable' from the rest of Cocoon, but I'm glad it is (having once had to manually rip out Cocoon 1's cache for a project;). Btw, there is already a cache in the sandbox, which IIRC from a conversation looong ago, is already pretty mature and tested. If anyone knows both codebases, it would be nice to have a comparison, for the benefit of users trying to choose. --Jeff Thx for your time. Gerhard PS: I'm committer in the Jakarta Avalon project and in the Cocoon xml-apache project. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka Documentation
(repost; this is the second mail of mine that mysteriously vanished..) On Mon, Jan 07, 2002 at 05:31:36PM -0600, Morgan Delagrange wrote: - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 07, 2002 5:26 AM Subject: cvs commit: jakarta-commons/latka/src/java/org/apache/commons/latka/validators XPathHandler.java XPathValidator.java ... + liFix the documentation system :) It's currently horrible; a single HTML file, + created by some GUI editor. I would very much recommend the XML DTD + + stylesheet in the Anteater project (see a + href=http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aft/Anteater/doc/;http ://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aft/Anteater/doc//a), + whose styled output may be (temporarily) viewed a + href=http://opensource.socialchange.net.au/latka/Anteater.html;here/a./ li ... It wasn't created by a GUI, actually, it was generated by DocBook. We could always go back to actual docbook XML and generate the thing, or we could use something else. I agree, the docs are a mess. Argh :) I thought it looked rather illegible. Docbook sounds fine.. could you check it into CVS please? --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Nominating Jeff Turner as Commons committer
Thanks all! :) --Jeff On Fri, Jan 04, 2002 at 05:50:14PM -0800, Craig R. McClanahan wrote: I added the appropriate CVS karma for Jeff. Welcome! Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
byte b = 'a'; not allowed
There seems to be a bug in 'javac', which lets you implicitly typecast a char
to a byte. Eg:
public class Test {
public static void main(String args[]) {
byte b = 'a';
}
'javac Test.java' compiles fine. That's from the Blackdown 1.3.0 JDK.
'jikes Test.java' reports:
Found 1 semantic error compiling Test.java:
3. byte b = 'a';
-
*** Error: A byte value must be an integer value (note that a character literal is not
an integer value) in the range -128..127.
Which makes perfect sense, since a char is 16 bits, and a byte is 8 bits. This
is relevant to httpclient, which would not compile with jikes:
[javac] Found 22 semantic errors compiling
/home/jeff/apache/jakarta/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/URIUtil.java:
[javac]
[javac]703. case '0':
[javac] -
I fixed httpclient with a typecast (email waiting in a moderator's queue
presumably), but I thought I'd raise awareness of the issue here, and take the
opportunity to do a bit of jikes advocacy ;)
--Jeff
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: byte b = 'a'; not allowed
On Fri, Jan 04, 2002 at 07:53:28PM -0800, [EMAIL PROTECTED] wrote:
Interesting, I never saw this, even though I used jikes (1.15).
Ah.. when I try to exploit the bug with an 8-bit character, javac throws an
error:
Test.java:3: possible loss of precision
found : char
required: byte
byte x = 'ö';
^
1 error
So it looks like it's my old version of jikes (1.13). I'll upgrade and try
again.
However, I do get this warning below. It is just a warning, but...
compile:
[javac] Compiling 29 source files to
/home/otis/cvs-repositories/jakarta/jakarta-commons/httpclient/target/classes
[javac]
[javac] Issued 1 semantic warning compiling
/home/otis/cvs-repositories/jakarta/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/log/SimpleLog.java:
[javac]
[javac]103. } catch(Throwable t) {
[javac] -
[javac] *** Caution: This try block cannot throw a checked exception (JLS
section 14.7) that can be caught here. You may have intended to catch a
RuntimeException instead of an Exception.
[copy] Copying 3 files to
/home/otis/cvs-repositories/jakarta/jakarta-commons/httpclient/target/classes
Yes, that's from a block of code:
try {
} catch(Throwable t) {
// ignored
}
Looks like the try { is misplaced.
--Jeff
BUILD SUCCESSFUL
Otis
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] forcing a specific DTD
On Tue, Nov 13, 2001 at 11:57:46PM -0800, Tal Dayan wrote: Hi Jeff, It worked as advertised in first try. Glad you found it useful. Fudging doctypes is not exactly an elegant solution, but in the real world it's unfortunately necessary, at least until XML schemas take over the world (NOoo..!!;) The API looks very flexible (e.g. generating a DOCTYPE based on the original one) and it generated the correct DOCTYPE in all cases I tried (with and without ? xml ... ?, with and without original DOCTYPE, etc). It seems like a very good workaround for the DTD enforcing issue and if the license permits, we would like to use it. The original code was released under the MPL 1.1, which I *think* is APL-compatible, and which I guess is changeable to APL anyway if it's non-viral? I hate licenses.. --Jeff Thanks, Tal -Original Message- From: Jeff Turner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 6:46 PM To: Jakarta Commons Developers List Subject: Re: [digester] forcing a specific DTD You can use this utility to force a specific doctype: http://newgate.socialchange.net.au/~jeff/doctypechanger/ I posted this on Nov 5: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=100491227030900w=2 --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
