[jira] Resolved: (VALIDATOR-154) [validator] GenericValidator.isDate can fail when strict == true
[ http://issues.apache.org/jira/browse/VALIDATOR-154?page=all ]
Niall Pemberton resolved VALIDATOR-154.
---
Fix Version/s: (was: 1.3.1)
Resolution: Won't Fix
The routines package has a new DateValidator implementation which fixes this:
http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#date
The o.a.c.v.DateValidator will be deprecated in favour of
o.a.c.v.routines.DateValidator
closing as WONT FIX
[validator] GenericValidator.isDate can fail when strict == true
Key: VALIDATOR-154
URL: http://issues.apache.org/jira/browse/VALIDATOR-154
Project: Commons Validator
Issue Type: Improvement
Components: Routines
Affects Versions: Nightly Builds
Environment: Operating System: All
Platform: All
Reporter: Gregg Yost
Assigned To: Niall Pemberton
Priority: Minor
Attachments: date-patches.zip
org.apache.commons.validator.GenericValidator.isDate(String value, String
datePattern, boolean strict) fails in some situations when the strict
parameter is true (it can either accept invalid dates or reject valid ones).
I
detected this in 1.0.2 but the latest code in CVS seems to have the same
problem (though in the latest code, the problem code has moved from
GenericValidator to DateValidator).
The problem is that the strict == true is implemented by comparing the
length
of the input string to the length of the pattern string. This heuristic
fails
in some situations. For example:
- datePattern = -MM-dd, value = 2003-06-2x returns that the date is
valid but it isn't. SimpleDateFormat parses the 2003-06-2 part as June 2,
2003 even when setLenient(false) has been called, and the value and pattern
lengths are the same so the strict test passes.
- datePattern = MMM dd, , value = January 12, 2003 returns that the
date is NOT valid but it is. The date parses correctly but the pattern and
value lengths are different, so the strict test doesn't pass.
Both problems can be fixed by changing the implementation of strict == true
to see whether after the date has been parsed, the ParsePosition is at the
end
of the input value string.
Here's some sample code that should work correctly for the
DateValidator.isValid method in the latest source code. Similar code would
work in version 1.0.2 in GenericValidator.isDate. You should consider
whether
the version of isValid that takes a Locale as a parameter is working as
intended as well (maybe it is, since it doesn't have a strict parameter --
but should there be a way to specify both strict and a Locale?)
public boolean isValid(String value, String datePattern, boolean strict) {
if (value == null || datePattern == null || datePattern.length() = 0) {
return false;
}
SimpleDateFormat formatter = new SimpleDateFormat(datePattern);
formatter.setLenient(false);
ParsePosition pos = new ParsePosition(0);
formatter.parse(value, pos);
if (strict (pos.getIndex() value.length())) {
return false;
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl [EMAIL PROTECTED] wrote:
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8
if( ! Modifier.isPrivate(clazz.getModifiers()) !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8
PropertyUtilsBean#invokeMethod(...):
8
method.setAccessible(true);
return method.invoke(bean,values);
8
I first wanted to discuss this here and not creating an bug immediately.
Tom
-
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]
[jira] Resolved: (VALIDATOR-119) [validator] add validateTwoFields (e.g. for passwords)
[ http://issues.apache.org/jira/browse/VALIDATOR-119?page=all ] Niall Pemberton resolved VALIDATOR-119. --- Resolution: Won't Fix Without a patch, so I'm closing this as WONT FIX. I'm happy for it to be re-opened if someone submits a patch with test cases. [validator] add validateTwoFields (e.g. for passwords) -- Key: VALIDATOR-119 URL: http://issues.apache.org/jira/browse/VALIDATOR-119 Project: Commons Validator Issue Type: Improvement Components: Routines Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Priority: Minor would be great to have this in struts1.3! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-146) [validator] punycode in email validation
[ http://issues.apache.org/jira/browse/VALIDATOR-146?page=all ] Niall Pemberton resolved VALIDATOR-146. --- Resolution: Won't Fix Since no-ones submitted a patch, I'm closing this as WONT FIX. I'm happy for it to be re-opened if someone submits a patch and test cases. [validator] punycode in email validation Key: VALIDATOR-146 URL: http://issues.apache.org/jira/browse/VALIDATOR-146 Project: Commons Validator Issue Type: Improvement Components: Routines Environment: Operating System: All Platform: All Reporter: Viraj Turakhia Priority: Minor Hi, I am using struts 1.2 and its validator framework for my application. My client is a German and they are using IDN as laid by RFC3490. (visit http://www.denic.de/en/faqs/idn_faqs/index.html for details) Validator plugin for struts doesn't validate email address as per this standard. Could you please let me know when you are going to accomodate this? Thanks, Viraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-123) [validator] Add JXPath Validator
[ http://issues.apache.org/jira/browse/VALIDATOR-123?page=all ] Niall Pemberton updated VALIDATOR-123: -- Bugzilla Id: (was: 29145) Fix Version/s: Validator2 [validator] Add JXPath Validator Key: VALIDATOR-123 URL: http://issues.apache.org/jira/browse/VALIDATOR-123 Project: Commons Validator Issue Type: Improvement Components: Routines Affects Versions: Nightly Builds Environment: Operating System: other Platform: All Reporter: Don Brown Priority: Minor Fix For: Validator2 Attachments: jxpath-patches.zip This patch adds a jxpath validator that allows schematron-style validations using xpath. Many types of objects are supported including DOM, JDOM, JavaBeans, DynaBeans, etc. For more information, see JXPath's website. This concept is from XMLForms - http://sf.net/projects/freebuilder, previously of Cocoon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-106) [validator] Javascript Rendering Extension
[ http://issues.apache.org/jira/browse/VALIDATOR-106?page=all ] Niall Pemberton updated VALIDATOR-106: -- Bugzilla Id: (was: 32343) Fix Version/s: Validator2 [validator] Javascript Rendering Extension -- Key: VALIDATOR-106 URL: http://issues.apache.org/jira/browse/VALIDATOR-106 Project: Commons Validator Issue Type: Improvement Components: JavaScript Environment: Operating System: All Platform: All Reporter: Niall Pemberton Priority: Minor Fix For: Validator2 I have developed an extension for Commons Validator that renders the dynamic javascript for Form validation. More details on the listed web site along with a download of the source code and a sample webapp that lets you try it out and shows you the source code. * The main component is the ScriptRenderer class which renders the necessary javascript for form validation to a StringBuffer. * Static javascript methods have more appropriate method signatures and are smaller and simpler. * fields are validated in the order defined in validation.xml (rather than by Validator) * it handles 'indexed' field validation * I've re-written the Date Validation Javascript Validator so its simpler and takes properly into account the difference between the different date patterns. * It can now provide field level validation - for example in the onchange method of a field. There are examples of all this in the sample webapp. The only word of warning - until a couple of weeks ago I knew virtually no javascript! So it would be good if someone experienced could re-view it - the sample webapp shows you the generated javascript. I would like to add this to Commons Validator, but thought I would post it fore re-view first. Niall -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-168) [validator] Extension to provide test cases for client-side validation
[ http://issues.apache.org/jira/browse/VALIDATOR-168?page=all ]
Niall Pemberton updated VALIDATOR-168:
--
Bugzilla Id: (was: 32873)
Fix Version/s: Validator2
[validator] Extension to provide test cases for client-side validation
--
Key: VALIDATOR-168
URL: http://issues.apache.org/jira/browse/VALIDATOR-168
Project: Commons Validator
Issue Type: Improvement
Components: JavaScript
Environment: Operating System: All
Platform: All
Reporter: Nacho G. Mac Dowell
Priority: Minor
Fix For: Validator2
ABSTRACT: There is a general problem with client side validation in validator.
It is almost impossible to provide test cases for functions working on forms.
Instead, if the validator functions focused on what they (should) do best:
validation, then it would be much simpler to provide tests for all
validators. I
propose making two functions in between forms and validator. One would act as
a
sort of controller (validateField) and another would grab all values from the
field (grabValuesFromSingleField). Most validators would have the same
signature: a single parameter of type Array. The most obviest enhancements
would
be easier maintainability, greater clarity and reusability. Another
enhancement
this would provide is conforming to the nature of http: being able to send
multiple values for any type of single field.
NOTE: Some discussion about this went on in #32343 with Niall's Javascript
Rendering Extension. I beleive it would help stop bugs like #32351 and many
others.
PROPOSAL: First of all I want to look at a couple of transformed validator
functions so we can inmediately get a grasp of the benefits we'll encounter
(note that the parameter is an array of values and that isAllDigits and trim
are
omitted for clarity):
function validateRequired(values) {
var isValid = values.length 0;
for (i=0; ivalues.length; i++) {
if (trim(values[i]).length == 0) {
isValid = false;
break;
}
}
return isValid;
}
function validateInteger(values) {
var isValid = true;
for (i=0; ivalues.length; i++) {
if (!isAllDigits(values[i])) {
isValid = false;
break;
} else {
var iValue = parseInt(values[i]);
if (isNaN(iValue) || !(iValue = -2147483648 iValue
= 2147483647)) {
isValid = false;
break;
}
}
}
return isValid;
}
* Providing test-cases for this would be fairly simple:
A html page with this use of these tests can be found at:
http://www.visual-ma.com/validator/tests.html
function testInteger() {
assertFalse(validateInteger(new Array(\1\, \a\, \b\)));
assertTrue(validateInteger(new Array(\1\, \-2\, \44\)));
}
function assertTrue(evalMe) {
if (eval(evalMe)) {
log([assertTrue] Test ok for: + evalMe);
} else {
log([assertTrue] Test failed for: + evalMe, true);
}
}
function assertFalse(evalMe) {
if (eval(evalMe)) {
log([assertFalse] Test failed for: + evalMe, true);
} else {
log([assertFalse] Test ok for: + evalMe);
}
}
* So to the point now. The controller would be:
function validateField(oField, validatorFunction) {
if (!oField.type oField.length oField[0]) {
//if it has no type it means there are multiple fields with the
same name. We
shall put the type
//for the field for easier handling
oField.type = oField[0].type;
oField.name = oField[0].name
}
var bValid = true;
var focusField = oField;
if (oField.type == 'radio' || oField.type == 'checkbox') {
var virtualField = oField;
if (!oField.length) {
virtualField = new Array();
virtualField.type = oField.type;
virtualField.name = oField.name;
virtualField[0] = oField;
}
eval(bValid = + validatorFunction +
(grabValuesFromSingleField(virtualField)));
//no need to focus on these
focusField = null;
} else if (oField.length !oField.options) {
for (n=oField.length - 1; n=0; n--) {//reverse so we can focus
on the first
eval(var auxValid = + validatorFunction +
(grabValuesFromSingleField(oField[n])));
if (!auxValid) {
[jira] Updated: (VALIDATOR-126) [validator] More generic handling of form field values
[ http://issues.apache.org/jira/browse/VALIDATOR-126?page=all ]
Niall Pemberton updated VALIDATOR-126:
--
Bugzilla Id: (was: 30872)
Fix Version/s: Validator2
[validator] More generic handling of form field values
--
Key: VALIDATOR-126
URL: http://issues.apache.org/jira/browse/VALIDATOR-126
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Environment: Operating System: Windows XP
Platform: PC
Reporter: Harvey
Priority: Minor
Fix For: Validator2
Attachments: js.patch
This validation works for server side, but does not work for client side.
The
lines in validation.xml are:
field property=groupId depends=required
arg0 key=evaluationForm.groupId/
/field
field property=reviewers depends=required
arg0 key=evaluationForm.reviewers/
/field
(group_id is the list, reviewers are the checkboxes). No JS errors are
generated in Mozilla. I have the following Struts-generated JS code (this is
a
partial, but relevant listing):
==
function validateEvaluationForm(form)
{
if (bCancel)
return true;
else
return validateMaxLength(form) validateRequired(form)
validateIntRange(form);
}
function maxlength () {
this.aa = new Array(message, Message can not be greater than 4000
characters., new Function (varName, this.maxlength='4000'; return this
[varName];));
}
function required () {
this.aa = new Array(groupId, Evaluation group is required., new
Function (varName, return this[varName];));
this.ab = new Array(reviewers, Reviewers is required., new Function
(varName, return this[varName];));
this.ac = new Array(deadline.date, Deadline day is required., new
Function (varName, this.min='1'; this.max='31'; return this[varName];));
}
function intRange () {
this.aa = new Array(deadline.date, Deadline day is not in the range 1
through 31., new Function (varName, this.min='1'; this.max='31'; return
this[varName];));
}
==
Finally, the lines I get when the JS does not catch this validation and the
form is submitted (i.e., server side validation) are (and these are correct):
* Please provide a Program Group
* Please provide at least one reviewer
Thank you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-143) [validator] Add script generator and JSP taglib
[ http://issues.apache.org/jira/browse/VALIDATOR-143?page=all ] Niall Pemberton updated VALIDATOR-143: -- Bugzilla Id: (was: 29536) Fix Version/s: Validator2 [validator] Add script generator and JSP taglib --- Key: VALIDATOR-143 URL: http://issues.apache.org/jira/browse/VALIDATOR-143 Project: Commons Validator Issue Type: Improvement Components: JavaScript Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Don Brown Priority: Minor Fix For: Validator2 This patch basically moves the Struts Javascript validator taglib over to commons-validator. Naturally, all the Struts-specific code has been removed. The biggest change was from Struts' MessageResources to JDK's ResourceBundle. 100% percent of the capabilities of the Struts version was maintained, however, Struts will still probably need to extend this class to load ValidatorResources from the servlet context as they do, and wrap MessageResources as a ResourceBundle implementation. This should make it easier for other projects like Spring to use the validator needing as little integration code as possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-111) [validator] Add time validation
[ http://issues.apache.org/jira/browse/VALIDATOR-111?page=all ] Niall Pemberton updated VALIDATOR-111: -- Bugzilla Id: (was: 22431) Fix Version/s: 1.4.0 There is now a server side Time validator in the new routines package. Leaving this open as it also has javascript time validator http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#date [validator] Add time validation --- Key: VALIDATOR-111 URL: http://issues.apache.org/jira/browse/VALIDATOR-111 Project: Commons Validator Issue Type: Improvement Components: JavaScript Environment: Operating System: All Platform: All Reporter: Nick Sydenham Priority: Minor Fix For: 1.4.0 Attachments: StrutsValidators.java, time.xml The date validator doesn't handle times on the client. Need a new validator to handle times. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-157) [validator] Add BSF Validator
[ http://issues.apache.org/jira/browse/VALIDATOR-157?page=all ] Niall Pemberton updated VALIDATOR-157: -- Bugzilla Id: (was: 29205) Fix Version/s: Validator2 [validator] Add BSF Validator - Key: VALIDATOR-157 URL: http://issues.apache.org/jira/browse/VALIDATOR-157 Project: Commons Validator Issue Type: Improvement Components: Routines Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Don Brown Priority: Minor Fix For: Validator2 Attachments: bsf-patches.zip This patch adds a validator that executes BSF-supported script snippets defined in the variable eval to determine validity. Code, unit tests, and patches to supporting files are included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-134) [validator] create 5 or more password-policy validators
[ http://issues.apache.org/jira/browse/VALIDATOR-134?page=all ] Niall Pemberton resolved VALIDATOR-134. --- Resolution: Won't Fix I think people are better off implementing their own custom password validators. Closing as WONT FIX [validator] create 5 or more password-policy validators --- Key: VALIDATOR-134 URL: http://issues.apache.org/jira/browse/VALIDATOR-134 Project: Commons Validator Issue Type: Improvement Components: Routines Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor besides the already existing length-check, the following (server-side only as per COM-160 - although most sites tell a cracker on their registration pages in plain english anyway what the minimum policy is) validators would be useful: - require capital letter - require a non-captial letter - require a number - require a special character. Furthermore there should be combination-validators, e.g. one would use the above four to implement a 2 out of 4 rule. Most government uses require something alike, e.g. as per http://www.isb.admin.ch/imperia/md/content/sicherheit/informatiksicherheit/sicherheitsweisungen/anhang1_d.pdf, item 2.4 (German) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-173) [validator] Change ValidatorUtils.getValueAsString to throw exception
[ http://issues.apache.org/jira/browse/VALIDATOR-173?page=all ] Niall Pemberton resolved VALIDATOR-173. --- Resolution: Won't Fix [validator] Change ValidatorUtils.getValueAsString to throw exception - Key: VALIDATOR-173 URL: http://issues.apache.org/jira/browse/VALIDATOR-173 Project: Commons Validator Issue Type: Improvement Components: Framework Environment: Operating System: All Platform: PC Reporter: peter merikan Priority: Minor If you misspell the name of a dependent property it is ignored by the validator. The validator uses the ValidatorUtil.getValueAsString method to get the value from the dependent property. The returned value is null because the property doesn't exist and the ValidatorUtil.getValueAsString method catches all exceptions (e.g. NoSuchMethodException) Shouldn't the validator throw a exception if a property doesn't exist? What if I change the name of a property and then correct the jsp but forgot to update validate.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-200) validateCreditCard javascript could ignore whitespace and hyphens
[ http://issues.apache.org/jira/browse/VALIDATOR-200?page=all ]
Niall Pemberton updated VALIDATOR-200:
--
Fix Version/s: 1.4.0
validateCreditCard javascript could ignore whitespace and hyphens
-
Key: VALIDATOR-200
URL: http://issues.apache.org/jira/browse/VALIDATOR-200
Project: Commons Validator
Issue Type: Improvement
Components: JavaScript
Affects Versions: 1.3.0 Release
Environment: -all-
Reporter: Paul Devine
Priority: Minor
Fix For: 1.4.0
the validateCreditCard javascript routine flags an input field as an invalid
credit card number if the input field contains any non-numeric characters or
whitespaces. I currently modify the input field's value before validation to
remove whitespaces and hyphens, like this:
$('paymentForm:cardNumber').value =
$('paymentForm:cardNumber').value.replace(/ /g,'');
$('paymentForm:cardNumber').value =
$('paymentForm:cardNumber').value.replace(/-/g,'');
It would be simple enough to have the validateCreditCard function handle
this, but rather than modifying the input field value, it would modify the
variable it is validating on, so the user does not see any `change` in what
they have entered
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-150) [validator] Commons Validator JavaScript is not Namespaced
[ http://issues.apache.org/jira/browse/VALIDATOR-150?page=all ] Niall Pemberton updated VALIDATOR-150: -- Bugzilla Id: (was: 38184) Fix Version/s: Validator2 [validator] Commons Validator JavaScript is not Namespaced -- Key: VALIDATOR-150 URL: http://issues.apache.org/jira/browse/VALIDATOR-150 Project: Commons Validator Issue Type: Improvement Components: JavaScript Environment: Operating System: All Platform: All Reporter: Niall Pemberton Priority: Minor Fix For: Validator2 See comments on VALIDATOR-109. From VALIDATOR-109 Of course, one of the big issues with the Commons Validator JavaScript code is that it too is not namespaced. ;-( That's something that needs fixing. It's not that hard to fix, but the changes would introduce new rules for people writing custom validators. It's most definitely do-able, though, and needs to be done. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-122) [validator] Form extends multiple forms
[ http://issues.apache.org/jira/browse/VALIDATOR-122?page=all ] Niall Pemberton updated VALIDATOR-122: -- Bugzilla Id: (was: 34416) Fix Version/s: Validator2 [validator] Form extends multiple forms --- Key: VALIDATOR-122 URL: http://issues.apache.org/jira/browse/VALIDATOR-122 Project: Commons Validator Issue Type: Improvement Components: Framework Environment: Operating System: other Platform: Other Reporter: Samuel Fleischle Priority: Minor Fix For: Validator2 Attachments: Form.java, validator_1_2_0.dtd The extends attribute in the form elements allows to extend another form as shown in code below. form name=form1 ... /form form name=form2 ... /form form name=form3 extends=form1 ... /form To get a bean-centric view of the forms, there is the necessity to extend from more than one form: form name=form4 extends=form1, form2 ... /form I changed the following code in the Form.class (see also the attachement): - List inheritanceList: holds all extended forms - setExtends(String): allows comma-seperated list in the same way like the depends attribute of the field-element. Fills the inheritanceList - process(Map, Map, Map): added a while-loop, to iterate over the inheritanceList In the validator_1_2_0.dtd I changed the following: - form element contains 0..* field-elements, allowing a form without fields, in the case, if all fields are from extends forms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-203) Refactor UrlValidator - especially the line 370-ish TODO.
[ http://issues.apache.org/jira/browse/VALIDATOR-203?page=all ] Niall Pemberton updated VALIDATOR-203: -- Fix Version/s: 1.4.0 (was: 1.3.1) Refactor UrlValidator - especially the line 370-ish TODO. - Key: VALIDATOR-203 URL: http://issues.apache.org/jira/browse/VALIDATOR-203 Project: Commons Validator Issue Type: Task Reporter: Henri Yandell Assigned To: Henri Yandell Fix For: 1.4.0 The UrlValidator class needs some cleanup. Just looking at VALIDATOR-202 there were some obvious places where things could be cleaned up and the solution for VALIDATOR-202 could use improvement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-205) Improve handling of ; in paths
[ http://issues.apache.org/jira/browse/VALIDATOR-205?page=all ] Niall Pemberton updated VALIDATOR-205: -- Component/s: Routines Fix Version/s: 1.4.0 Improve handling of ; in paths -- Key: VALIDATOR-205 URL: http://issues.apache.org/jira/browse/VALIDATOR-205 Project: Commons Validator Issue Type: Improvement Components: Routines Reporter: Henri Yandell Fix For: 1.4.0 VALIDATOR-204 fixes a bug that a ; was not considered a valid character. It does it by blanketedly accepting it as an okay character when in fact there are proviso's and conditions surrounding the existence of a ; within a path. RFC 3986 apparantly contains a regexp for urls, so might be useful to take that and use it as a basis for this validator. Simplest case - improve the ; handling somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-203) Refactor UrlValidator - especially the line 370-ish TODO.
[ http://issues.apache.org/jira/browse/VALIDATOR-203?page=all ] Niall Pemberton updated VALIDATOR-203: -- Component/s: Routines Refactor UrlValidator - especially the line 370-ish TODO. - Key: VALIDATOR-203 URL: http://issues.apache.org/jira/browse/VALIDATOR-203 Project: Commons Validator Issue Type: Task Components: Routines Reporter: Henri Yandell Assigned To: Henri Yandell Fix For: 1.4.0 The UrlValidator class needs some cleanup. Just looking at VALIDATOR-202 there were some obvious places where things could be cleaned up and the solution for VALIDATOR-202 could use improvement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
On 11/23/06, Henri Yandell [EMAIL PROTECTED] wrote: JIRA reports are good - we've a big backlog in BeanUtils but it's starting to go down. There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87). I don't know why the API is designed to only work with public methods; whether that's an aspect of adherence to the spec, by design or legacy. Seems that if we're going to use setAccessible, that we could just open it to package and private too. Anyone know why MethodUtils intentionally limits itself? There is indeed a large dose of legacy here ... the early versions of BeanUtils (which came out of Struts in the pre-1.0 days) were never consciously designed to be a general purpose bean property manipulation library (i.e. the BeanUtils moniker was something of a stretch :-). The sole initial intents were to provide for the type conversions that Digester needed, plus the copy request parameters to a form bean that the 1.xversion of a Struts ActionForm needed. Hence, there was never any initial consideration for supporting the more esoteric cases that a general purpose framework would need to support. If BeanUtils is going to continue to evolve on the trajectory that seems to be epitomized by recent comments on the mailing list and in JIRA issues, it will need to be modified to deal with scenarios like this. On the other hand, more modern approaches to both configuration management (alternative strategies for parsing configuration files plus completely different approaches like JAXB), plus the decoupling of modern web frameworks from hard coded things like a Struts ActionForm, means that my personal need to care about what happens in BeanUtils is pretty much zero. I don't consider it an appropriate place to do innovative development, but if you are interested in improving support for legacy applications then it is (of course) fertile ground for incremental improvements -- some of which could be pretty substantial improvements in usabilty. Have at it ... but you'll find me watching from the sidelines. Hen Craig McClanahan
Re: [BeanUtils] Why does needs the method declaring a class to be public
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 +
BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl [EMAIL PROTECTED] wrote:
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced
version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8
if( ! Modifier.isPrivate(clazz.getModifiers()) !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8
PropertyUtilsBean#invokeMethod(...):
8
method.setAccessible(true);
return method.invoke(bean,values);
8
I first wanted to discuss this here and not creating an bug
immediately.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-210) Generated JavaScript Causes HTML Page to Contain Illegal HTML
Generated JavaScript Causes HTML Page to Contain Illegal HTML
-
Key: VALIDATOR-210
URL: http://issues.apache.org/jira/browse/VALIDATOR-210
Project: Commons Validator
Issue Type: Bug
Components: JavaScript
Affects Versions: 1.3.0 Release
Environment: All
Reporter: Neil Sherman
Priority: Minor
Various JavaScript functions contain JavaDoc comments at the start such as:
/*$RCSfile: validateMaxLength.js,v $ $Rev: 376673 $ $Date: 2006-02-10
13:42:31 + (Fri, 10 Feb 2006) $ */
/**
* A field is considered valid if less than the specified maximum.
* Fields are not checked if they are disabled.
* p
* strongCaution:/strong Using codevalidateMaxLength/code on a
password field in a
* login page gives unnecessary information away to hackers. While it only
slightly
* weakens security, we suggest using it only when modifying a
password./p
* @param form The form validation is taking place on.
*/
function validateMaxLength(form) {
This causes the W3C tidy application to report the following:
+ / + letter not allowed here
Cause:
The 2 characters / have been detected in a wrong place.
Solution:
In most case, this is due to wrong javascript:
BAD document.write(/h1);
GOOD document.write(\/h1);
References:
W3C faq: http://validator.w3.org/docs/help.html#faq-javascript
HtmlHelp: http://www.htmlhelp.com/tools/validator/problems.html#script
And thus produces illegal HTML.
The proposed solution is to remove the offending tags.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-133) Indexed properties as arg0-arg3
[ http://issues.apache.org/jira/browse/VALIDATOR-133?page=all ] Niall Pemberton updated VALIDATOR-133: -- Bugzilla Id: (was: 23372) Summary: Indexed properties as arg0-arg3 (was: [validator] Indexed properties as arg0-arg3) Fix Version/s: Validator2 Indexed properties as arg0-arg3 --- Key: VALIDATOR-133 URL: http://issues.apache.org/jira/browse/VALIDATOR-133 Project: Commons Validator Issue Type: Improvement Components: Framework Environment: Operating System: All Platform: All Reporter: Jim Prantzalos Priority: Minor Fix For: Validator2 I entered something similar to this as a feature enhancement to the Struts validator prior to figuring out that this is really a commons-validator enhancement request. (See also I entered something similar to this as a feature enhancement to the Struts validator prior to figuring out that this is really a commons-validator enhancement request. (See also Bug #23351). The basic problem is, when working with forms that contain indexed properties, how do I use the validator to generate meaningful error messages, such as: Employment #2: must specify a start date for primary employer 'Motown Music'. My recommendation is: 1) Add a 'property' attribute to arg0-3 such that I can use the indexed properties as parameters to my messages. Example: arg1 property=emps[].employerName/ 2) Add an 'index' literal such that I can pass the current index as a parameter to my messages. Example: arg1 property=[].index/ or arg1 property=*index*/ Whatever literal is used, it would also be nice to have it available in var-value. Used together with 'validwhen' it would be very helpful. Example: field property=startDate indexedListProperty=emps depends=validwhen ... var-value((*index* != '0') or (*this* != null))/var-value ... -jim). The basic problem is, when working with forms that contain indexed properties, how do I use the validator to generate meaningful error messages, such as: Employment #2: must specify a start date for primary employer 'Motown Music'. My recommendation is: 1) Add a 'property' attribute to arg0-3 such that I can use the indexed properties as parameters to my messages. Example: arg1 property=emps[].employerName/ 2) Add an 'index' literal such that I can pass the current index as a parameter to my messages. Example: arg1 property=[].index/ or arg1 property=*index*/ Whatever literal is used, it would also be nice to have it available in var-value. Used together with 'validwhen' it would be very helpful. Example: field property=startDate indexedListProperty=emps depends=validwhen ... var-value((*index* != '0') or (*this* != null))/var-value ... -jim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-169) Field validation for a list of fields
[ http://issues.apache.org/jira/browse/VALIDATOR-169?page=all ]
Niall Pemberton updated VALIDATOR-169:
--
Bugzilla Id: (was: 22046)
Summary: Field validation for a list of fields (was: [validator]
Field validation for a list of fields)
Fix Version/s: Validator2
Field validation for a list of fields
-
Key: VALIDATOR-169
URL: http://issues.apache.org/jira/browse/VALIDATOR-169
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Environment: Operating System: other
Platform: Other
Reporter: Jovovich
Priority: Minor
Fix For: Validator2
Attachments: patch.txt
I have a JSP with a list of fields and I'm using the Validator in combination
with Struts for validating the field entries. The current behaviour of the
Validator in case of a failed validation is stopping the validation for the
whole list of fields. It would be much better, if the validator is processing
the list of fields in any case. As a JSP programmer, I am able to show an
error message for _each_ wrong field of the list.
This can be fixed with a small change in class Validator.java method
validateField. Instead of doing a return statement in the inner loop, just
call the break statement, so the outer loop can continue its work.
private void validateField(Field field, ValidatorResults allResults)
throws ValidatorException {
Map actions = resources.getValidatorActions();
if (field.isIndexed()) {
Object oIndexed;
try {
oIndexed =
PropertyUtils.getProperty(
hResources.get(BEAN_KEY),
field.getIndexedListProperty());
} catch (Exception e) {
log.error(in validateField, e);
return;
}
Object indexedList[] = new Object[0];
if (oIndexed instanceof Collection) {
indexedList = ((Collection) oIndexed).toArray();
} else if (oIndexed.getClass().isArray()) {
indexedList = (Object[]) oIndexed;
}
for (int pos = 0; pos indexedList.length; pos++) {
ValidatorResults results = new ValidatorResults();
StringTokenizer st = new StringTokenizer(field.getDepends(),
,);
while (st.hasMoreTokens()) {
String depend = st.nextToken().trim();
ValidatorAction action = (ValidatorAction)
actions.get(depend);
if (action == null) {
log.error(
No ValidatorAction called
+ depend
+ found for field
+ field.getProperty());
return;
}
boolean good =
validateFieldForRule(field, action, results, actions,
pos);
allResults.merge(results);
if (!good) {
break;
}
}
}
Thanks,
Tobias
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-170) Validating Arrays of simple Objects
[ http://issues.apache.org/jira/browse/VALIDATOR-170?page=all ]
Niall Pemberton updated VALIDATOR-170:
--
Bugzilla Id: (was: 32978)
Summary: Validating Arrays of simple Objects (was: [validator]
Validating Arrays of simple Objects)
Fix Version/s: Validator2
Validating Arrays of simple Objects
---
Key: VALIDATOR-170
URL: http://issues.apache.org/jira/browse/VALIDATOR-170
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.3.0 Release
Environment: Operating System: Windows 2000
Platform: PC
Reporter: William Ferguson
Priority: Minor
Fix For: Validator2
The Validator needs the ability to validate an array of simple Objects such
as
Strings. Ie it should be possible to define a bean like:
class foo {
public String getBar();
public void setBar(String[] values);
}
and have the values of Bar validated.
Currently (validator 1.1.3 as ships with Struts 1.2.8, and looks same in
1.1.4),
to validate an array of properties you need to specify
property='somePropertyName'
indexedListProperty='propertyAtWhichCollectionIsFound'
This will iterate through the collection found at
'propertyAtWhichCollectionisFound',
and will validate the 'somePropertyName' property on each element.
But if it is a collection of Strings then there is no valid property name to
define.
Ie you don't seem to be able to validate a collection of Strings.
To fix it, either 'property' needs to be optional (not recommended), or a new
approach to indexed properties needs to be taken. Perhaps by allowing
'property'
to define where the array of values can be found as well as any property to
validate on the elements (using dot notation), and having the Validator
introspect the values at each step and determine whether ot needs to iterate
over a collection. This would also solve some of the enhancements requests
that have been made for the Validator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-129) Enhance form to handle nested forms (beans)
[ http://issues.apache.org/jira/browse/VALIDATOR-129?page=all ] Niall Pemberton updated VALIDATOR-129: -- Bugzilla Id: (was: 38133) Summary: Enhance form to handle nested forms (beans) (was: [validator] [patch] Enhance form to handle nested forms (beans)) Fix Version/s: Validator2 Enhance form to handle nested forms (beans) --- Key: VALIDATOR-129 URL: http://issues.apache.org/jira/browse/VALIDATOR-129 Project: Commons Validator Issue Type: Improvement Components: Framework Affects Versions: 1.2.0 Release Environment: Operating System: other Platform: Other Reporter: Tomasz Bech Priority: Minor Fix For: Validator2 Attachments: nested-patch-v1.txt It was initialy discussed in the bug http://issues.apache.org/bugzilla/show_bug.cgi?id=16394 but I recognized that the author wanted a little bit different feature. Generally validator doesn't support validation of nested beans/forms. Current IndexedListProperty implementation allows it only for one nested bean, it is not sufficient for complex forms/beans (many nested levels), it is rather workaround than full implementation. It also doesn't correspond to Struts nested tag (and validator is mainly used by Struts). Patch is included, it is based on latest validator1.2.0 svn. Form tag can now include nested tag as (it is in dtd_1.2.1): !-- Defines the nested beans to be validated. Two way of nested beans are possible: simple - accessed by property and 'indexed'- accessed by indexed property. Nested validation supports any level of nested beans. The idea and usage is similar to nested tag in Struts taglib. The nested element accepts these attributes: propertyThe property on the JavaBean corresponding to this nested element. 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 on the bean. typeThe type/name of the nested bean which will be validated. The validation rules are described as standard form tag with the same name as specified for type. One and exactly one of property and indexedListProperty can be specified exclusively. -- !ELEMENT nested (msg|arg|var)* !ATTLIST nested property CDATA #IMPLIED !ATTLIST nested indexedListProperty CDATA #IMPLIED !ATTLIST nested type CDATA #REQUIRED Example usage is: form-validation global validator name=byte classname=org.apache.commons.validator.TestValidator method=validateByte methodParams=java.lang.Object,org.apache.commons.validator.Field msg=/ /global formset form name=complexForm field property=value depends=byte/ nested property=subForm type=subForm1/ nested indexedListProperty=listSubForms type=subForm2/ nested indexedListProperty=listComplexSubForms type=subFormComplex/ /form form name=subForm1 field property=value depends=byte/ /form form name=subForm2 extends=subForm1 /form form name=subFormComplex field property=value depends=byte/ nested property=subForm type=subForm1/ nested indexedListProperty=listSubForms type=subForm2/ /form /formset /form-validation There is test included (NestedTest.java), see there NestedTest-config.xml and how to use nested tag. Currently I tested it in our STRUTS project, it works correctly for 2 level nested beans. Please give me any feedback, reports, bugs, etc. I hope that there is a chance to have it merged in the source base. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-186) Enhance the IndexedListProperty to handle nested lists.
[ http://issues.apache.org/jira/browse/VALIDATOR-186?page=all ]
Niall Pemberton updated VALIDATOR-186:
--
Fix Version/s: Validator2
Description:
Allowing lists to be validated helps a great deal but the code that is supplied
with the commons-validator 1.0 could be simplified and enhanced. There are two
features that it would be nice to have:
1) When the IndexedListProperty is used it would be nice if all the fields in
the list were validated, i.e. the validation did not stop at the first error.
This would need a different loop mechanism and the key to be set to the fully
qualified path, e.g list[0].value and not list[].value.
2) It would be very nice if the IndexedListProperty could be nested, e.g. the
size for all the doors on all the rooms must be greater than n. I am not
sure of the syntax in the configuration file that makes sense but offer
list1.list2.list3. as a suggestion. The PropertyUtils could then be called
on the bean using the list1 property to get the first list and then called
on each of the returned objects using the list2 property, etc. So, if you
had two rooms, the first with one door, the second with two and the
validation.xml Field looked like:
field
property=size
indexedListProperty=rooms.doors
depends=min
arg0 key=error.door.size/
var
var-namemin/var-name
var-value${n}/var-value
/var
/field
The validator waould in effect be called for:
rooms[0].doors[0].size
rooms[1].doors[0].size
rooms[1].doors[1].size
The code below provides an example of how this could be done. It uses the
IndexedProperty to pass information down a reentrant stack because I did not
want to change the parameters to the Validator.validate method but that would
obviously be safer. Also, by putting this code snipit in place, all the other
isIndexed code could be removed so you don't have to loop twice (as it does in
version 1.0).
Thanks...Peter
//
// These snippits are out of the Validator class. There is a one line
// change to validate, one new method and one tidied up method.
// The code has been tested and works but you may not like the way it
// changes the BEAN_KEY and uses the IndexProperty.
//
/**
* Performs validations based on the configured resources.
* Needed as we cannot access (override) the private methods.
*
* @return The codeMap/code returned uses the property
* of the codeField/code for the key and the value
* is the number of error the field had.
*/
public ValidatorResults validate() throws ValidatorException
{
ValidatorResults results = new ValidatorResults();
Locale locale = null;
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)
{
for (Iterator i = form.getFields().iterator(); i.hasNext(); )
{
Field field = (Field)i.next();
if (field.getPage() = page)
{
// *
// This is the only line that changed in this method.
// *
validateFieldNested(field, results);
// *
}
}
}
return results;
}
/**
* Validate field nested. This method handles nested list validation
* of the form IndexedListProperty = list1.list2.list3. It gets all the
* instances in list1 off the BEAN_KEY (root bean) using the PropertyUtils
* then gets all the list2 entries of all the list1 objects, then all the
* list3 objects of the list2 objects, etc. The result is that the
* validateField method is called on all the list3 objects with the property
* as it was but the BEAN_KEY set to the current list3 object and the
* Field key set to the fully qualified key (e.g. list1[0].list2[0].list3
[0]).
*
* @param field See Validator.validateField
* @param allResultsSee Validator.validateField
*/
private void validateFieldNested (Field field, ValidatorResults allResults)
throws ValidatorException
{
// Does it have an IndexedList property?
[jira] Updated: (VALIDATOR-116) Indexed Property Validation - javascript non-javascript
[ http://issues.apache.org/jira/browse/VALIDATOR-116?page=all ] Niall Pemberton updated VALIDATOR-116: -- Bugzilla Id: (was: 22687) Summary: Indexed Property Validation - javascript non-javascript (was: [validator] Indexed Property Validation - javascript non-javascript) Fix Version/s: Validator2 Indexed Property Validation - javascript non-javascript - Key: VALIDATOR-116 URL: http://issues.apache.org/jira/browse/VALIDATOR-116 Project: Commons Validator Issue Type: Improvement Components: Framework Environment: Operating System: other Platform: All Reporter: G. Wayne Kidd Priority: Minor Fix For: Validator2 When an indexed property is validated (which apparently cannot happen at all for javascript validations - I checked the CVS), only one error is identified for each validation type. There should be an error for each bad field. With the current implementation, there is no way for the user to identify the source of the problem since it could be any one (or more) of the repeating items. The comment in the javascript tag that indicates why there is no javascript for this case indicates that the messages can't be identified. The right thing to do seems to be either to give an error parm that is the field string itself. The other choice seems to me to be that you could specify a identification property in the xml that shows which item is failing. For example, suppose an indexed object (using nested tags) has a property called lastName that is being validated. If it is required and missing, there is nothing to put in the message. But if there is a field in the iterator that is generated, account number or indexid (at worst), then that could be specified to be placed in the error message. No matter what, it does not seem fair to make the user fix the same error with additional round-trips when we have obviously already analyzed the error for all of the iterations. Wayne -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r478518 - in /jakarta/commons/proper/validator/trunk: src/javascript/org/apache/commons/validator/javascript/ xdocs/
Author: niallp
Date: Thu Nov 23 01:23:23 2006
New Revision: 478518
URL: http://svn.apache.org/viewvc?view=revrev=478518
Log:
VALIDATOR-210 - JavaScript Causes HTML Page to Contain Illegal HTML - thanks to
Neil Sherman
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateEmail.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateFloat.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateFloatRange.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateIntRange.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateInteger.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMask.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateRequired.js
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateShort.js
jakarta/commons/proper/validator/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js?view=diffrev=478518r1=478517r2=478518
==
---
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js
(original)
+++
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js
Thu Nov 23 01:23:23 2006
@@ -3,7 +3,6 @@
/**
* Check to see if fields are a valid byte.
* Fields are not checked if they are disabled.
-* p
* @param form The form validation is taking place on.
*/
function validateByte(form) {
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js?view=diffrev=478518r1=478517r2=478518
==
---
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
(original)
+++
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
Thu Nov 23 01:23:23 2006
@@ -3,7 +3,6 @@
/**
* Check to see if fields are a valid creditcard number based on Luhn
checksum.
* Fields are not checked if they are disabled.
-* p
* @param form The form validation is taking place on.
*/
function validateCreditCard(form) {
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js?view=diffrev=478518r1=478517r2=478518
==
---
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js
(original)
+++
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js
Thu Nov 23 01:23:23 2006
@@ -3,7 +3,6 @@
/**
* Check to see if fields are a valid date.
* Fields are not checked if they are disabled.
-* p
* @param form The form validation is taking place on.
*/
function validateDate(form) {
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateEmail.js
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateEmail.js?view=diffrev=478518r1=478517r2=478518
==
---
Re: [BeanUtils] Why does needs the method declaring a class to be public
Hi,
the problem are not the methods visibility the methods in the sub-class
are public but their class declaration is not and you can call them if
you method.setAccessible(true) I've currently modified BeanUtils in my
project and it works perfectly.
Tom
Will Pugh schrieb:
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 +
BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl [EMAIL PROTECTED] wrote:
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced
version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8
if( ! Modifier.isPrivate(clazz.getModifiers()) !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8
PropertyUtilsBean#invokeMethod(...):
8
method.setAccessible(true);
return method.invoke(bean,values);
8
I first wanted to discuss this here and not creating an bug
immediately.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-210) Generated JavaScript Causes HTML Page to Contain Illegal HTML
[ http://issues.apache.org/jira/browse/VALIDATOR-210?page=all ]
Niall Pemberton resolved VALIDATOR-210.
---
Fix Version/s: 1.3.1
Resolution: Fixed
Assignee: Niall Pemberton
Fixed thanks!
http://svn.apache.org/viewvc?view=revrevision=478518
You will be able to test this out by dowloading the next nightly build:
http://people.apache.org/builds/jakarta-commons/nightly/commons-validator/
Generated JavaScript Causes HTML Page to Contain Illegal HTML
-
Key: VALIDATOR-210
URL: http://issues.apache.org/jira/browse/VALIDATOR-210
Project: Commons Validator
Issue Type: Bug
Components: JavaScript
Affects Versions: 1.3.0 Release
Environment: All
Reporter: Neil Sherman
Assigned To: Niall Pemberton
Priority: Minor
Fix For: 1.3.1
Various JavaScript functions contain JavaDoc comments at the start such as:
/*$RCSfile: validateMaxLength.js,v $ $Rev: 376673 $ $Date: 2006-02-10
13:42:31 + (Fri, 10 Feb 2006) $ */
/**
* A field is considered valid if less than the specified maximum.
* Fields are not checked if they are disabled.
* p
* strongCaution:/strong Using codevalidateMaxLength/code on a
password field in a
* login page gives unnecessary information away to hackers. While it
only slightly
* weakens security, we suggest using it only when modifying a
password./p
* @param form The form validation is taking place on.
*/
function validateMaxLength(form) {
This causes the W3C tidy application to report the following:
+ / + letter not allowed here
Cause:
The 2 characters / have been detected in a wrong place.
Solution:
In most case, this is due to wrong javascript:
BAD document.write(/h1);
GOOD document.write(\/h1);
References:
W3C faq: http://validator.w3.org/docs/help.html#faq-javascript
HtmlHelp: http://www.htmlhelp.com/tools/validator/problems.html#script
And thus produces illegal HTML.
The proposed solution is to remove the offending tags.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Thanks Henri,
maybe we could make this configurable somehow. I can't read somewhere in
the spec of JavaBeans that you can't use inheritance.
Tom
Henri Yandell schrieb:
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl [EMAIL PROTECTED] wrote:
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced
version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8
if( ! Modifier.isPrivate(clazz.getModifiers()) !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8
PropertyUtilsBean#invokeMethod(...):
8
method.setAccessible(true);
return method.invoke(bean,values);
8
I first wanted to discuss this here and not creating an bug
immediately.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-265) Allow access to public methods from not public classes
Allow access to public methods from not public classes
--
Key: BEANUTILS-265
URL: http://issues.apache.org/jira/browse/BEANUTILS-265
Project: Commons BeanUtils
Issue Type: New Feature
Components: Bean / Property Utils
Affects Versions: 1.7.0
Reporter: Tom Schindl
Currently BeanUtils doesn't provide the possibility to access getters and
setters in classes who are package-scoped!
---8---
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
---8---
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Hi, Craig McClanahan schrieb: On 11/23/06, Henri Yandell [EMAIL PROTECTED] wrote: [...] If BeanUtils is going to continue to evolve on the trajectory that seems to be epitomized by recent comments on the mailing list and in JIRA issues, it will need to be modified to deal with scenarios like this. On the other hand, more modern approaches to both configuration management (alternative strategies for parsing configuration files plus completely different approaches like JAXB), plus the decoupling of modern web frameworks from hard coded things like a Struts ActionForm, means that my personal need to care about what happens in BeanUtils is pretty much zero. I don't consider it an appropriate place to do innovative development, but if you are interested in improving support for legacy applications then it is (of course) fertile ground for incremental improvements -- some of which could be pretty substantial improvements in usabilty. Well for me BeanUtils are a really usable components because the classes I need to deal with in my framework are not 100% JavaBeans (they are SWT-Widgets I'm loading from XML-Spec to design GUIs in a language called XSWT) so other technologies to instantiate them fail for me miserably and BeanUtils really help me here a lot to set the various values with nearly no custom code. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-205) Improve handling of ; in paths
[ http://issues.apache.org/jira/browse/VALIDATOR-205?page=comments#action_12452193 ] Niall Pemberton commented on VALIDATOR-205: --- The regular expression in RFC 3986 is already being used by UrlValidator - see the URL_PATTERN static variable. Also reading RFC 3986 [1] it has the following definition for path: segment and segment-nz make up the path. Both of these are composed of any number of pchar characters which is defined as one of the following three categories unreserved, pct-encoded or sub-delims sub-delims includes the semi-colon i.e. ; So from what I can see the change you made, fixed the problem and we can close this as invalid? [1] http://www.ietf.org/rfc/rfc3986.txt Improve handling of ; in paths -- Key: VALIDATOR-205 URL: http://issues.apache.org/jira/browse/VALIDATOR-205 Project: Commons Validator Issue Type: Improvement Components: Routines Reporter: Henri Yandell Fix For: 1.4.0 VALIDATOR-204 fixes a bug that a ; was not considered a valid character. It does it by blanketedly accepting it as an okay character when in fact there are proviso's and conditions surrounding the existence of a ; within a path. RFC 3986 apparantly contains a regexp for urls, so might be useful to take that and use it as a basis for this validator. Simplest case - improve the ; handling somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
On 11/23/06, Tom Schindl [EMAIL PROTECTED] wrote: Hi, the problem are not the methods visibility the methods in the sub-class are public but their class declaration is not and you can call them if you method.setAccessible(true) I've currently modified BeanUtils in my project and it works perfectly. This solution will work (by default) ... until you try it on a server where a security manager with rational policies is enabled by default (such as had *better* be the case, for example, in a server environment that shares a JVM across multiple third party webapps). If you don't think this is imprtant, you might as well be coding in a scripting language, because you are giving up one of the key advantages of using a strongly typed language like Java. Note that I am not at all dissing the choice to use such a language ... but you should be aware of what you give up to gain the corresponding benefits. Therefore I would be pretty unhappy with a proposal to make BeanUtils to this sort of thing by default, without some deliberate choice by the application developer (thereby explicitly accepting the security vulnerabilities that come with setAccessbile() working as described here). Tom Craig
Re: [BeanUtils] Why does needs the method declaring a class to be public
Craig McClanahan schrieb: On 11/23/06, Tom Schindl [EMAIL PROTECTED] wrote: Hi, the problem are not the methods visibility the methods in the sub-class are public but their class declaration is not and you can call them if you method.setAccessible(true) I've currently modified BeanUtils in my project and it works perfectly. This solution will work (by default) ... until you try it on a server where a security manager with rational policies is enabled by default (such as had *better* be the case, for example, in a server environment that shares a JVM across multiple third party webapps). If you don't think this is imprtant, you might as well be coding in a scripting language, because you are giving up one of the key advantages of using a strongly typed language like Java. you are right in server environments this might bring us into trouble under certain circumstance. That's why I proposed to make this configurable because e.g. in my case stand-alone SWT-Application (Loading GUI from XML) doesn't have any problems with it. BTW what I can not really understand is why I can not call a *public* method from a class without setAccessible(true) using reflection when I can do it in any ordinary java application. Providing access to private, package, protected scoped methods should not be allowed by the way using BeanUtils. The only thing I request is to call public methods! Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How patching the homepage?
i would like to make a patch for the homepage. In the commons-compress section the examples should be replaced with: http://wiki.apache.org/jakarta-commons/Compress If you agree, please tell me how can i do this or where i can find information about to do this. The homepage is/will get generated by maven so patches to src/site are welcome ...and then someone just needs to get them online. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-261) Return null but not throw NestedNullException if the nested property is null
[ http://issues.apache.org/jira/browse/BEANUTILS-261?page=comments#action_12452230 ] Jiemiao Shi commented on BEANUTILS-261: --- It's my pleasure to report bugs. I am busy working on another wok recently and I will focus on this project some day later. Return null but not throw NestedNullException if the nested property is null Key: BEANUTILS-261 URL: http://issues.apache.org/jira/browse/BEANUTILS-261 Project: Commons BeanUtils Issue Type: New Feature Components: Bean / Property Utils Reporter: Jiemiao Shi Can provide a method in PropertyUtils to get nested properties without throwing a NestedNullException when any of the no-end property is null? example: /* code begin */ Employee employee=... emplyee.setAddress(null); String street=(String) PropertyUtils.getNestedProperty(employee, address.street);// /* code end */ The statement will throws a NestedNullException, but return null will make it easier to write code in some situation. So can please provide a method only return null? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r478560 - in /jakarta/commons/proper/validator/trunk: src/share/org/apache/commons/validator/EmailValidator.java src/test/org/apache/commons/validator/EmailTest.java xdocs/changes.xml
Author: niallp
Date: Thu Nov 23 05:09:27 2006
New Revision: 478560
URL: http://svn.apache.org/viewvc?view=revrev=478560
Log:
VALIDATOR-190 - EmailValidator allows control characters (ASCII 0-31 and 127) -
thanks to Cott and Gabriel Belingueres
Modified:
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/EmailValidator.java
jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/EmailTest.java
jakarta/commons/proper/validator/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/EmailValidator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/EmailValidator.java?view=diffrev=478560r1=478559r2=478560
==
---
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/EmailValidator.java
(original)
+++
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/EmailValidator.java
Thu Nov 23 05:09:27 2006
@@ -38,7 +38,7 @@
*/
public class EmailValidator {
-private static final String SPECIAL_CHARS =
\\(\\)@,;:'\.\\[\\];
+private static final String SPECIAL_CHARS =
\\000-\\037\\(\\)@,;:'\.\\[\\]\\177;
private static final String VALID_CHARS = [^\\s + SPECIAL_CHARS + ];
private static final String QUOTED_USER = (\[^\]*\);
private static final String ATOM = VALID_CHARS + '+';
Modified:
jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/EmailTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/EmailTest.java?view=diffrev=478560r1=478559r2=478560
==
---
jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/EmailTest.java
(original)
+++
jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/EmailTest.java
Thu Nov 23 05:09:27 2006
@@ -221,6 +221,18 @@
}
+ /**
+* Tests the email validation with ascii control characters.
+* (i.e. Ascii chars 0 - 31 and 127)
+*/
+public void testEmailWithControlChars() throws ValidatorException {
+EmailValidator validator = new EmailValidator();
+for (char c = 0; c 32; c++) {
+assertFalse(Test control char + ((int)c),
validator.isValid(foo + c + [EMAIL PROTECTED]));
+}
+assertFalse(Test control char 127, validator.isValid(foo +
((char)127) + [EMAIL PROTECTED]));
+}
+
/**
* Write this test according to parts of RFC, as opposed to the type of
character
* that is being tested.
Modified: jakarta/commons/proper/validator/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/xdocs/changes.xml?view=diffrev=478560r1=478559r2=478560
==
--- jakarta/commons/proper/validator/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/validator/trunk/xdocs/changes.xml Thu Nov 23
05:09:27 2006
@@ -40,6 +40,11 @@
body
release version=1.3.1 date=Pending
+ action dev=niallp type=fix issue=VALIDATOR-190
+EmailValidator allows control characters (ASCII 0-31 and 127).
+dueto name=Cott/
+dueto name=Gabriel Belingueres/
+ /action
action dev=niallp type=fix issue=VALIDATOR-210 due-to=Neil
Sherman
JavaScript Causes HTML Page to Contain Illegal HTML.
/action
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-190) EmailValidator allows control characters (ASCII 0-31)
[ http://issues.apache.org/jira/browse/VALIDATOR-190?page=all ]
Niall Pemberton resolved VALIDATOR-190.
---
Fix Version/s: 1.3.1
Resolution: Fixed
Assignee: Niall Pemberton
I applied a slightly different change since any valid ASCII character is
allowed if its quoted - so I changed the excluded special characters which
are used to define atom/word to also exclude ascii control characters (ASCII
0-31 and 127).
http://svn.apache.org/viewvc?view=revrevision=478560
You can test out the changes using the next nightly build:
http://people.apache.org/builds/jakarta-commons/nightly/commons-validator/
Thanks for reporting this and your help!
Niall
EmailValidator allows control characters (ASCII 0-31)
-
Key: VALIDATOR-190
URL: http://issues.apache.org/jira/browse/VALIDATOR-190
Project: Commons Validator
Issue Type: Bug
Components: Routines
Affects Versions: 1.3.0 Release
Reporter: Cott
Assigned To: Niall Pemberton
Priority: Minor
Fix For: 1.3.1
Attachments: EmailTest-diff.txt, EmailValidator-diff.txt
EmailValidator allows ASCII 0 - 31 in an email address.
According to RFC 821, these are forbidden.
import org.apache.commons.validator.EmailValidator;
public class Test {
public static void main(String[] args) {
EmailValidator ev = EmailValidator.getInstance();
String email =[EMAIL PROTECTED];
System.err.println(ev.isValid(email));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r478566 - in /jakarta/commons/proper/validator/trunk: src/javascript/org/apache/commons/validator/javascript/validateUtilities.js xdocs/changes.xml
Author: niallp
Date: Thu Nov 23 05:24:38 2006
New Revision: 478566
URL: http://svn.apache.org/viewvc?view=revrev=478566
Log:
VALIDATOR-208 - JavaScript function jcv_isFieldPresent() causes error in IE5
using undefined - thanks to Leo Asanov
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js
jakarta/commons/proper/validator/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js?view=diffrev=478566r1=478565r2=478566
==
---
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js
(original)
+++
jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js
Thu Nov 23 05:24:38 2006
@@ -87,7 +87,7 @@
*/
function jcv_isFieldPresent(field) {
var fieldPresent = true;
- if (field == null || field == undefined) {
+ if (field == null || (typeof field == 'undefined')) {
fieldPresent = false;
} else {
if (field.disabled) {
Modified: jakarta/commons/proper/validator/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/xdocs/changes.xml?view=diffrev=478566r1=478565r2=478566
==
--- jakarta/commons/proper/validator/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/validator/trunk/xdocs/changes.xml Thu Nov 23
05:24:38 2006
@@ -40,6 +40,9 @@
body
release version=1.3.1 date=Pending
+ action dev=niallp type=fix issue=VALIDATOR-208 due-to=Leo
Asanov
+JavaScript function jcv_isFieldPresent() causes error in IE5 using
undefined.
+ /action
action dev=niallp type=fix issue=VALIDATOR-190
EmailValidator allows control characters (ASCII 0-31 and 127).
dueto name=Cott/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-208) jcv_isFieldPresent function causes error in IE5
[ http://issues.apache.org/jira/browse/VALIDATOR-208?page=all ] Niall Pemberton resolved VALIDATOR-208. --- Fix Version/s: 1.3.1 Resolution: Fixed Assignee: Niall Pemberton Fixed, thanks! http://svn.apache.org/viewvc?view=revrevision=478566 I've tested this on IE6 and Firefox 1.5 - but if you could test on IE5 it would be appreciated. You can download the next nightly build to test it out here: http://people.apache.org/builds/jakarta-commons/nightly/commons-validator/ Niall jcv_isFieldPresent function causes error in IE5 --- Key: VALIDATOR-208 URL: http://issues.apache.org/jira/browse/VALIDATOR-208 Project: Commons Validator Issue Type: Bug Components: JavaScript Affects Versions: 1.3.0 Release Environment: Internet Explorer 5.01 Reporter: Leo Asanov Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3.1 Hi, In jcv_isFieldPresent function code if (field == null || field == undefined) causes Javascript error in IE5. Should be if (field == null || typeof field == 'undefined') That way it should work in all browsers. I guess it would make sense to do a search for other references to undefined in javascript code. Regards, Leo P.S. The following link has the instructions on how to run IE5 without need to install it locally. You night find it useful. http://labs.insert-title.com/labs/Multiple-IEs-in-Windows_article795.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r478676 - /jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/
Author: niallp Date: Thu Nov 23 13:35:44 2006 New Revision: 478676 URL: http://svn.apache.org/viewvc?view=revrev=478676 Log: Add missing license headers Modified: jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateDate.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateEmail.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateFloat.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateFloatRange.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateIntRange.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateInteger.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMask.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateRequired.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateShort.js jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateUtilities.js Modified: jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js?view=diffrev=478676r1=478675r2=478676 == --- jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js (original) +++ jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateByte.js Thu Nov 23 13:35:44 2006 @@ -1,4 +1,19 @@ - +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + *http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ /*$RCSfile: validateByte.js,v $ $Rev$ $Date$ */ /** * Check to see if fields are a valid byte. Modified: jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js?view=diffrev=478676r1=478675r2=478676 == --- jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js (original) +++ jakarta/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js Thu Nov 23 13:35:44 2006 @@ -1,4 +1,19 @@ - +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + *http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ /*$RCSfile: validateCreditCard.js,v $ $Rev$ $Date$ */ /** * Check
svn commit: r478677 - in /jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator: ParameterTest-config.xml ValidatorTestSuite.java
Author: niallp Date: Thu Nov 23 13:36:23 2006 New Revision: 478677 URL: http://svn.apache.org/viewvc?view=revrev=478677 Log: Fix minor test issues Modified: jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ParameterTest-config.xml jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ValidatorTestSuite.java Modified: jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ParameterTest-config.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ParameterTest-config.xml?view=diffrev=478677r1=478676r2=478677 == --- jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ParameterTest-config.xml (original) +++ jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ParameterTest-config.xml Thu Nov 23 13:36:23 2006 @@ -14,6 +14,9 @@ See the License for the specific language governing permissions and limitations under the License. -- +!DOCTYPE form-validation PUBLIC + -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.3.0//EN + http://jakarta.apache.org/commons/dtds/validator_1_3_0.dtd; form-validation global validator name=required @@ -25,7 +28,8 @@ org.apache.commons.validator.Validator, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.ValidatorResults, - java.util.Locale/ + java.util.Locale + msg=/ /global formset Modified: jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ValidatorTestSuite.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ValidatorTestSuite.java?view=diffrev=478677r1=478676r2=478677 == --- jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ValidatorTestSuite.java (original) +++ jakarta/commons/proper/validator/trunk/src/test/org/apache/commons/validator/ValidatorTestSuite.java Thu Nov 23 13:36:23 2006 @@ -41,6 +41,7 @@ suite.addTest(ByteTest.suite()); suite.addTestSuite(CreditCardValidatorTest.class); + suite.addTest(CustomValidatorResourcesTest.suite()); suite.addTest(DateTest.suite()); suite.addTest(DoubleTest.suite()); suite.addTest(EmailTest.suite()); @@ -49,22 +50,23 @@ suite.addTestSuite(FlagsTest.class); suite.addTestSuite(FieldTest.class); suite.addTest(FloatTest.suite()); + suite.addTestSuite(GenericValidatorTest.class); suite.addTest(IntegerTest.suite()); suite.addTestSuite(ISBNValidatorTest.class); suite.addTest(LocaleTest.suite()); suite.addTest(LongTest.suite()); suite.addTestSuite(MultipleConfigFilesTest.class); suite.addTest(MultipleTests.suite()); + suite.addTest(ParameterTest.suite()); suite.addTest(RequiredIfTest.suite()); suite.addTest(RequiredNameTest.suite()); suite.addTest(RetrieveFormTest.suite()); suite.addTest(ShortTest.suite()); suite.addTest(TypeTest.suite()); suite.addTest(UrlTest.suite()); + suite.addTest(ValidatorResultsTest.suite()); suite.addTest(ValidatorTest.suite()); suite.addTest(VarTest.suite()); - suite.addTestSuite(GenericValidatorTest.class); - suite.addTest(ValidatorResultsTest.suite()); return suite; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r478679 - in /jakarta/commons/proper/validator/trunk: ./ conf/share/ xdocs/
Author: niallp Date: Thu Nov 23 13:37:42 2006 New Revision: 478679 URL: http://svn.apache.org/viewvc?view=revrev=478679 Log: Build and site improvements Added: jakarta/commons/proper/validator/trunk/RELEASE-NOTES.txt - copied, changed from r478566, jakarta/commons/proper/validator/trunk/RELEASE-NOTES.html Removed: jakarta/commons/proper/validator/trunk/RELEASE-NOTES.html Modified: jakarta/commons/proper/validator/trunk/build.xml jakarta/commons/proper/validator/trunk/conf/share/MANIFEST.MF jakarta/commons/proper/validator/trunk/maven.xml jakarta/commons/proper/validator/trunk/project.properties jakarta/commons/proper/validator/trunk/project.xml jakarta/commons/proper/validator/trunk/xdocs/building.xml jakarta/commons/proper/validator/trunk/xdocs/changes.xml jakarta/commons/proper/validator/trunk/xdocs/downloads.xml jakarta/commons/proper/validator/trunk/xdocs/index.xml jakarta/commons/proper/validator/trunk/xdocs/navigation.xml Copied: jakarta/commons/proper/validator/trunk/RELEASE-NOTES.txt (from r478566, jakarta/commons/proper/validator/trunk/RELEASE-NOTES.html) URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/RELEASE-NOTES.txt?view=diffrev=478679p1=jakarta/commons/proper/validator/trunk/RELEASE-NOTES.htmlr1=478566p2=jakarta/commons/proper/validator/trunk/RELEASE-NOTES.txtr2=478679 == --- jakarta/commons/proper/validator/trunk/RELEASE-NOTES.html (original) +++ jakarta/commons/proper/validator/trunk/RELEASE-NOTES.txt Thu Nov 23 13:37:42 2006 @@ -1,42 +1,31 @@ -!-- - Licensed to the Apache Software Foundation (ASF) under one or more - contributor license agreements. See the NOTICE file distributed with - this work for additional information regarding copyright ownership. - The ASF licenses this file to You under the Apache License, Version 2.0 - (the License); you may not use this file except in compliance with - the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -html -head -titleValidator 1.3.0 Release Notes/title -head -body bgcolor=white - - -div align=center -h2Validator 1.3.0 Release Notes/h2 -/div - -p -The main aspects of this release are: -/p - -ul - liThis is a maintenance release which includes a number of bug fixes - since the last release. See the a href=docs/changes-report.htmlChanges Report/a for full details./li - liIntroduction of new bdate/b, btime/b and bnumber validators/b - see the - a href=docs/apidocs/org/apache/commons/validator/routines/package-summary.html#package_description - Routines Package JavaDocs/a for more details./li -/ul +$Id$ -/body -/html + Commons Validator Package + Version 1.3.1 + Release Notes + +Bug fixes from 1.3.0 + + +* [VALIDATOR-19] - The Form cannot be used for the validator's +method parameter. +* [VALIDATOR-89] - ValidatorAction needs to be thread-safe +* [VALIDATOR-189] - Validating array integers fails +* [VALIDATOR-190] - EmailValidator allows control characters (ASCII 0-31) +* [VALIDATOR-195] - Loading of Digester Rules for classes extending +ValidatorResources does not work +* [VALIDATOR-198] - Example does not compile +* [VALIDATOR-199] - Commons Validator 1.3.0 source distribution's build.xml +neglects to include validator_1_1_3.dtd in JAR +* [VALIDATOR-202] - URL Validator isValid method fails with ArrayIndexOutOfBoundsException +* [VALIDATOR-204] - isValid return false for a valid URL +* [VALIDATOR-208] - jcv_isFieldPresent function causes error in IE5 +* [VALIDATOR-210] - Generated JavaScript Causes HTML Page to Contain Illegal HTML + + +Improvements from 1.3.0 +--- + +* [VALIDATOR-209] - Additional constructor for ValidatorResources that takes +URL[] instead of String[] Modified: jakarta/commons/proper/validator/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/build.xml?view=diffrev=478679r1=478678r2=478679 == --- jakarta/commons/proper/validator/trunk/build.xml (original) +++ jakarta/commons/proper/validator/trunk/build.xml Thu Nov 23 13:37:42 2006 @@ -111,6 +111,12 @@ !-- == Compiler Defaults = -- + !-- source JDK version (should be same as maven.compile.source) -- + property
svn commit: r478680 - in /jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1: ./ build.xml project.xml
Author: niallp Date: Thu Nov 23 13:47:17 2006 New Revision: 478680 URL: http://svn.apache.org/viewvc?view=revrev=478680 Log: Tag Validator 1.3.1 Release Candidate 1 Added: jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/ - copied from r478679, jakarta/commons/proper/validator/trunk/ Modified: jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/build.xml jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/project.xml Modified: jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/build.xml?view=diffrev=478680r1=478679r2=478680 == --- jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/build.xml (original) +++ jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/build.xml Thu Nov 23 13:47:17 2006 @@ -67,7 +67,7 @@ property name=component.title value=Validator/ !-- The current version number of this component -- - property name=component.version value=1.3.1-SNAPSHOT/ + property name=component.version value=1.3.1-RC1/ !-- The base directory for compilation targets -- property name=build.home value=target/ Modified: jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/project.xml?view=diffrev=478680r1=478679r2=478680 == --- jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/project.xml (original) +++ jakarta/commons/proper/validator/tags/VALIDATOR_1_3_1_RC1/project.xml Thu Nov 23 13:47:17 2006 @@ -22,7 +22,7 @@ nameValidator/name groupIdcommons-validator/groupId artifactIdcommons-validator/artifactId - currentVersion1.3.1-SNAPSHOT/currentVersion + currentVersion1.3.1-RC1/currentVersion inceptionYear2002/inceptionYear shortDescriptionCommons Validator/shortDescription description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On Sun, 2006-11-19 at 19:53 +, robert burrell donkin wrote: thanks to everyone who commented on RC1 i've now cut an RC2 based on the feedback and uploaded the artifacts (only) to http://people.apache.org/~rdonkin/commons-betwixt/. please check them. unless issues emerge, i'll finish off the process (javadocs, signatures and so on) and move to a VOTE. no further reports so i'll move towards a vote soon - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] final checks on RC2
On 11/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-11-19 at 19:53 +, robert burrell donkin wrote: thanks to everyone who commented on RC1 i've now cut an RC2 based on the feedback and uploaded the artifacts (only) to http://people.apache.org/~rdonkin/commons-betwixt/. please check them. unless issues emerge, i'll finish off the process (javadocs, signatures and so on) and move to a VOTE. no further reports so i'll move towards a vote soon Sorry Robert, kept meaning to look at the rc, but not finding time - couple of comments: 1) The xdocs are missing from the source distro 2) Adding scope elements to the xerces, xml-apis and junit dependencies in the project.xml will probably help maven 2 downstream users by not pulling in those dependencies 3) Don't know why, but everyone seems to have changed mail archive from eyebrowse 4) Add md5 checksums to the build would make creating the release easier. I'll create a patch to fix all of the above in a minute - leave it up to you whether you think they need actioning before the release (IMO if you do include them I don't think it needs another RC). Overall though looks good to release to me. Niall - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BETWIXT-56) Build improvements
Build improvements -- Key: BETWIXT-56 URL: http://issues.apache.org/jira/browse/BETWIXT-56 Project: Commons Betwixt Issue Type: Improvement Reporter: Niall Pemberton Priority: Minor Attachments: betwixt-0.8-rc2-nits.patch Attaching patch to: 1) Include the xdocs in the source distro 2) Addi scope elements to the xerces, xml-apis and junit dependencies in the project.xml for maven 2 3) Switch mail archive links 4) Chnage the maven build to create md5 checksums -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BETWIXT-56) Build improvements
[ http://issues.apache.org/jira/browse/BETWIXT-56?page=all ] Niall Pemberton updated BETWIXT-56: --- Attachment: betwixt-0.8-rc2-nits.patch Build improvements -- Key: BETWIXT-56 URL: http://issues.apache.org/jira/browse/BETWIXT-56 Project: Commons Betwixt Issue Type: Improvement Reporter: Niall Pemberton Priority: Minor Attachments: betwixt-0.8-rc2-nits.patch Attaching patch to: 1) Include the xdocs in the source distro 2) Addi scope elements to the xerces, xml-apis and junit dependencies in the project.xml for maven 2 3) Switch mail archive links 4) Chnage the maven build to create md5 checksums -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch for compress (was: Re: How patching the homepage?)
The homepage is/will get generated by maven so patches to src/site are welcome ...and then someone just needs to get them online. Thanks. Sorry for that idiot question, i should have a closer look... Well here is a patch for the site. It moves out the old examples and includes a new one. Another thing: The packages org.apache.commons.compress.bzip2 has moved to org.apache.commons.compress.archivers.bzip2 Same for the zip package. The tar package has moved to org.apache.commons.compress.compressors.tar. But the old packages are still there as a copy. Can one delete em? This will be a problem, cause the new files have no history at all. Cheers, Chris Index: /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml === --- /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml (revision 477135) +++ /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml (working copy) @@ -30,6 +30,7 @@ liIf you like the code and want to push it towards a release, join the mailing list!/li /ul /p +It is planned to add delete functionality for archives. /subsection /section @@ -40,11 +41,36 @@ liThe a href=http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/;SVN repository/a can be browsed./li /ul /p +/section + +section name=A brief example p -There are also 2 example for the bzip2 API: +You can easily create a zip file with this piece of code: +source +Archive archiver = ArchiverFactory.getInstance(zip); +archiver.add( new File(C:\\Temp\\1.html)); +archiver.add( new File(C:\\Temp\\1.html.bz2)); +archiver.save( new File(C:\\Temp\\ZIPTEST.zip)); +/source +/p +p +Or simply decompress a file with gunzip: +source +Compressor decompressor; +decompressor = CompressorFactory.getInstance(bz2); +decompressor.decompressTo( new File(C:\\Temp\\asf-logo-huge.tar.bz2), + new File(C:\\Temp\\asf-logo-huge.tar)); +/source +/p +/section + +section name=More example classes +p +There are some example classes in the repository: ul - lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Compress.htmlBzip2Compress/a/li - lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Uncompress.htmlBzip2UnCompress/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/ZipExample.htmlZip/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Example.htmlBzip2/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/TarExample.htmlTar/a/li /ul /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Validator] 1.3.1 Release Candidate 1
I have prepared a RC1 for Validator 1.3.1 which is available for review here: http://people.apache.org/~niallp/validator-1.3.1-rc1/ This is a bug fix maintenance release only. As well as the site, and source/binary distros I have also put the RAT and CLIRR reports. Comments welcome. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
