DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26413. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | Version|1.1 Final |Nightly Build --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 14:51 --- Sorry I didn't get back to you earlier. I have now tried this using the nightly build from 10th Feb 20004 and the problem is still exists. In fact this problem occurs in all the FieldChecks validations that return null if the value is null. From looking at the source validateByte(), validateShort (), validateInteger(), validateLong(), validateFloat(), validateDouble() and validateCreditCard() are all affected by the same issue. I tried it out for the integer validation and it didn't work properly either for indexed fields. I think the best solution is for all these methods to just return a boolean rather than the value they are validating - and return 'true' (i.e. valid) if the value is blank or null. What do you think - if I do a patch on this basis would you be willing to commit it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5739] - Struts fails silently in too many places
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739 Struts fails silently in too many places --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 17:33 --- I'm -1 with the way you have changed XercesParser. The change you are proposing will break Tomcat 5 XML Schema support. It took us time to figure out why Xerces 2.3-2.5 suddently stoped to works, and the digester changes reflects that. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] New: - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping Summary: Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping Product: Struts Version: 1.1 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of Actionmapping When a validation error occurs in a DynaValidatorForm, it is observed that all request scope attributes, except the Form data are lost after the input page is reloaded. The Input page is specified in the input attribute of action mapping. For example in ViewDetailFormAction I set some request attributes by request.setAttribute(list, MyList); Now I hit submit on the ViewDetailForm which validates the data through validation.xml. If there are no errors, it works fine. But if there is an error, and it tries to reload the page, a message that the list is not in scope appears. However if this is put in session, it works fine and all form data appears as before. This means that Form data is preserved but request scope data is not preserved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 23:17 --- Is your input path an Action? Routing to an action causes the request processing chain to be re-fired, which generally causes exactly what you described. If you can change your input path to be a tile or a JSP, you won't have this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 23:39 --- Garima, When you say Now I hit submit on the ViewDetailForm ... it makes me think you are talking about when you are in the browser you are clicking on the submit button - is that the case? If it is then, this is a very simple question for the user list - not a bug. If its not then what do you mean by now I hit submit? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24235] - Secure html:link tag, plus module support.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235 Secure html:link tag, plus module support. --- Additional Comments From [EMAIL PROTECTED] 2004-02-12 04:37 --- Created an attachment (id=10325) This is a comprehensive patch that includes the previous patch for this bug named patch_examples.txt. , and extends the module= attribute to work with both the page= and forward= attributes. Additionally, the ForwardConfig was modified to allow a module= attribute as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24235] - Secure html:link tag, plus module support.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235 Secure html:link tag, plus module support. --- Additional Comments From [EMAIL PROTECTED] 2004-02-12 04:47 --- As per earlier comments from Ted, I have provided a patch (previous) that provides more completeness to the module= attribute in the html:link tag. I changed the examples welcome page to provide an example of all 3 html:link types that seemed applicable (forward, page, and action). Additionally, I added a module= attribute as part of the ForwardConfig. The TestRequestUtils has been updated to provide some additional testing related to the ForwardConfig change. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
